[Epic] Email is the Product! 💌

[nelsonic]

Context 💭

Let's talk about (sending|receiving) email. 💬 In the past we have taken a very "MVP" approach to sending email in both our Node & Elixir Apps. (I use that term "MVP" euphemistically to mean "bare minimum" not really long-term "viable" beyond sending "transactional" email... we must rethink our approach! 🙄)

We have included the email functionality in apps (e.g: "Welcome to the App!", "confirm your address", "reset your password", etc.) as a box ticking exercise not as a core UX/UI of the App. I feel that we have been letting ourselves and the people using our App(s) down by not focussing on the UX of the email we send. Sending out unremarkable email that have a low open/click-through rate (which we don't actively monitor!) or having an inbox full of unanswered email (because we lack a proper system for prioritising/handling inbound email) means all our other efforts building great features for our App(s) is wasted! If people aren't engaging with the email they are by definition not engaging with the App. 😞

I don't want to throw shade/stones at anyone for the past lack of effort in email in previous projects, I take responsibility for not lobbying past Product Managers/Owners for making it a priority. Rather I want to make the business case that if we don't make email amazing, we are pretty much wasting our time with building the rest of the features in the App. Both the Product Owner/Manager and the whole Dev Team need to make email a priority or we risk failure.

Restaurant Analogy: 🥣

Imagine you're a Chef who has practiced for years to make great food. You have spent most of your life savings to build a restaurant where you have paid great attention to detail with the menu/food, service and interior decor. But on the outside of the restaurant, there's no sign/marking and the front door is through a dimly lit alleyway so it looks abandoned.

In this analogy the interface to your delicious food is the dimly lit alleyway which means you aren't going to get very many customers. Should you continue to focus on improving the inside of the restaurant (e.g: the food and service quality) hoping that people will ignore the alley? Or attempt to "fix" the "UX" of the alleyway by investing in some lights, signs and decorations?

After you have made an effort to improve the "UX" of the alleyway, you can get back to running your business. But you still need to maintain the alleyway as the interface to your product.

If we apply this analogy to building a Software App/Product, the inside of the restaurant (menu, food, service, etc.) are the features of the Product. The outside of the restaurant, the alleyway and front door are the barrier to adoption. If the Chef (budding restaurateur) does not treat the interface to their restaurant as a feature of their product, then it does not matter how good the food is.

This past week, I've been painfully reminded of how horrible the UX of a noreply email is. You basically feel like nobody at the company cares about you as a person. You are just a "unit" in their accounting system. https://github.com/nelsonic/nelsonic.github.io/issues/781 💔 We don't want anyone using the @dwyl App to ever feel unloved because of a crappy email UX.

Story 💡

email is an integral part of the feedback loop of the App. ♻️ Without it we have no way of connecting with people using the App to welcome them to our community of people focussed on maximising personal effectiveness. If people don't open the email we send (because it's unremarkable), we end up with no way of informing them to return and use the App!

But its a lot more than glorified notification mechanism to remind people that a task they delegated has been completed (or has a follow up question from assignee), email is the interface people experience when they aren't using the App which encourages them use it. email is a make-or-break UI/UX!

There are a several stories that feature email and they all need to have amazing UX if our product is going to be successful. Having a "meh" email experience will mean people will not want to (a) open the emails we send them and (b) interact with them.

I am listing the "stories" in the order of impact to both the people receiving the emails and us the developers/owners of the product sending those emails i.e. the "bottom line". (highest impact first)

Each one of these stories will need to be split out into a separate issue with a checklist.

"User" (the person using the App) 👤

The UX of the person receiving emails from our App is the focus of this Epic.

Registration > Welcome! 💌

As a person registering to use the @dwyl App, I want to receive a welcome email outlining what I can do in the App So that I feel connected with the App.

Our welcome email should have the highest open rate in the industry. We need to track it from day 1. (see analytics story below) Ideally we should give the person some useful information in the welcome email with a single call-to-action (CTA) that a high percentage of people interact with. https://en.wikipedia.org/wiki/Call_to_action_(marketing)

Forgotten Password 😬

As a person who has forgotten their password and is "locked out" of the App, I want a seamless way to reset my password So that I can get back to using the App as fast as possible.

The sense of being "locked out" is a relatively stressful experience. We need to get people back on track as quickly as possible. The focus of this email needs to be the link they need to click to reset their password. We also need to reassure people that's it's perfectly normal to forget a password.

The App should track how many times a person forgets their password. So that if it detects that a person is consistently forgetful, the password reset email should suggest a password manager for their most used device.

Relevant/Useful Notifications 🔔

As a person using the @dwyl App to focus on my most important work, I want to receive occasional email notifications with SMART insights So that I can stay on track toward achieving my goal(s).

As soon as we have the essential functionality for the App working, we should determine what the most relevant information is to keep people engaged with working on their goals.

We should never send people irrelevant/useless notifications the way most social networks do. For the first 1k people using the App, email notifications will be the primary feedback loop. Later on we may end up using native notifications in our Native Flutter Apps and Browser Push Notifications based on demand/feedback from people using the app.

Log in 🚪

As a person authenticating with a Web/Mobile App using my email address and a password, I want to be informed by email when I log-in on a new device/platform So that I am reassured that the App is protecting my highly personal data.

This email should not be sent every time a person logs in otherwise the open rate will be very low. We need a function that checks which device(s) have been used by the person in the past and if a new device is used, we should email them to confirm that it is a legitimate login event.

Newsletter 🗞

As a person wanting to get useful/relevant actionable insights on personal effectiveness, I want to receive a monthly/fortnightly/weekly newletter a bitesize digest So that I can be inspired to take action on achieving my goal(s).

The Newsletter use-case is not a focus while we are building the features of the App. But just as I expect our "Blog" to be a significant source of SEO and inbound marketing. I expect that the people who already using the App to want to get personal effectiveness insights/tips delivered to their inbox. This is not just a question of "repackaging" the Blog content. We need to summarise it for busy people!

Replies > Conversation! 💬

As a person using the @dwyl App and encountering challenges with (or ideas for) the UX/UI, I want to be able to reply to any email sent by the @dwyl App so that with the @dwyl team via email

"noreply" / "no-reply" email addresses are a horrible UX antipattern! But not replying to people's emails can be even worse than a "noreply" email address! So we need to have a system for handling replies from people! A system that everyone in the company/team can access.

For this to happen, we need to work on receiving email: https://github.com/dwyl/email/issues/25

Developer (the person deploying the email system) 👩‍💻

As a person building/deploying a Phoenix Web App, I want the email sent by the App to be remarkable So that people consistently engage/re-engage with the app.

Our App aims to help people be more effective with their efforts. We want to ensure that our primary communication channel (email) is the best it can be.

Analytics 📈 📊

As a data-driven developer who makes informed decisions based on usage analytics I want to collect data on bounce, open, click through and rejection rates So that I know how effective our email system is.

Without collecting data we are attempting to drive to our destination at night, without a map or head lights!

Product Owner/Manager 👩‍🍳

As a Product Owner/Manager for promising Software Product, I want to ensure that the UX of every email sent by the system is remarkable So that the quality of the App is not let down by a poor feedback mechanism.

The Product Owner/Manager of the @dwyl App needs to be clear that they are responsible for email quality. It's not enough to send "transactional" or "generic" email, we need each email interaction to be remarkable.

Question: When Should We Focus on email ❓

I agree that we should focus on the "core" functionality/features of the app described in #262. I want to propose that we add email the list either in MVP or "very soon" after.

We all have a decent amount of experience of working at companies that got email right and horribly wrong and I want to frame the discussion from a "Product" perspective rather than simply a piece of "Business as Usual" functionality of the App. In other words we want the quality of the email System we use @dwyl to be excellent. 😍 We want the feeling people experience when they see/open an email from us to be "spark joy"! ✨ We want people to be so delighted to receive email from @dwyl that they forward it to friends/family!

[iteles]

I completely agree that getting email right is extremely important, thanks for opening this issue @nelsonic 🎉

It's our way of supporting people outside of the app as well and nudging them back in as we add new and helpful parts/learnings etc.

As I mentioned verbally in our standup yesterday: 'The industry' has given welcome emails a bad rap. Most of them are junk or up-sells or displeasing in some way and it creates a habit of deleting these without reading them. Because of this, people won't instinctively know the value of our emails until they have opened one.

I would suggest we therefore also include a bullet point in the acceptance criteria of the first email story to add some encouragement in the app to open the first email, where people verify their email address if they haven't already (it's important we have valid emails). This could take the form of blocking certain functionality (which I don't like because it reduces the value of the experience for people) or having a banner across the top of the app to remind people to go to that email and verify their address 👍

---

To answer your question in the OP @nelsonic, I would propose that we create the absolute barebones functionality in #266 first (create a task, categorise it, reorder tasks, mark them as complete, start a timer and sign in) so that we can start using the app ourselves as essentially an alpha release ASAP.

Once sign-in is implemented, we have the email addresses and can work on email functionality immediately, before we consider the MVP to be complete. At this stage, we can already be using our app and catching any small bugs before we release the MVP for user testing.

[nelsonic]

@iteles thanks for reading the essay above and sharing your thoughts. I don't think our email will be "junk" or "up-sells"; I think they will be rare and relevant. Once the "verification" email is sent, we should inform/instruct people to check their email (using a banner in the App) and thus establish the feedback loop from the outset. I'm definitely not in favour of blocking any functionality in the App until people verify. (agreed!)

I should have made it clearer that my reasoning for focussing on email (and thus opening this issue) is that email is a requirement for auth. See: https://github.com/dwyl/auth/issues/39

I obviously don't want to be spending my time on email because it's not a "feature" of our App that anyone would consider "value add" and would pay to use. But I do want auth to be a separate service that is independently tested & maintained so that our App does not have to include any auth related code and can instead focus 100% on the features we are trying to build #266.

If you run mix coveralls for MVP App https://github.com/dwyl/app-mvp-phoenix now on your localhost you will see that most of the code that is not covered by tests is auth related ... 🤔 And if you extrapolate from that point, I'm sure you will agree that it's unsustainable. The exact same thing goes for email related code in the auth app. It's untested. 😕 I don't want to build anything without tests because it creates a really bad habit/example. I want to make it easier for us to add features in the App by splitting out the auth into it's own (very well tested and maintained) independent project and the same goes for email.

The more we delay doing this, the more headache we will have and more re-work we will have to do. Nobody wants that. GOTO: https://github.com/dwyl/auth/issues/39

[nelsonic]

The Email System is ready to be used: https://github.com/dwyl/email Made a quick video of the demo of sending a Test email: https://youtu.be/yflPSotYd9Y

The next step is to integrate email sending via /api/send into the Auth app see: https://github.com/dwyl/auth/issues/41 That is Step 3 in the diagram: The API already works on from the side of the email app. i.e. Steps 4, 5 & 6 all work flawlessly. We just need to actually invoke the /api/send endpoint from the Auth app now.

[nelsonic]

The email functionality will be integrated into auth-mvp with https://github.com/dwyl/auth-mvp/pull/17 💌

[nelsonic]

Sending Emails is integrated into Auth: https://github.com/dwyl/auth/pull/43 So we never need to think about sending emails again (just to update templates/copy...).

[nelsonic]

The next action for this Epic is to create individual issues for the various types of Email described above. Then edit the description above to link to those sub-issues.