OneSignal Email

I was the lead product designer for the Email product. I conducted interviews with internal teams and analyzed competitors in the market to identify the problem. Through an iterative process, I proposed design solutions for boosting metrics, and the feature was launched.
Role
Lead Product Designer
Timeframe
9 weeks launch
Collaborated with
PM, Eng team

Product Background

OneSignal is a messaging platform mainly known for the Push notification platform. After launching an MVP of the Email product, our team saw significant usage, even with limited features. The company realized that the email platform was a critical channel for customers. Therefore, the company decided to aggressively focus on the Email product to increase market value and revenue.

Timeline

The timeline shows the parallel process of research, planning, design, and development. As part of the process of identifying the problem, I conducted interviews with internal teams and analyzed competitors in the market. Through an iterative process, I proposed design solutions for boosting metrics, iterated based on feedbacks, and the feature was launched.

Problem

For OneSignal Email product signup and engagements were increasing at rapid pace, however over 50% of direct customers who come to the Email dropped off during the Email setup process.
To identify the root cause of the problem, I interviewed customers and internal teams to identified the pain points that may cause the churn.
Manual process
The current process to set up our direct customers is very manual, and requires many hours of our support team.
Process delay
Most customer churns happens during the process of back and forth with support team on emails.
Additional ESP required
Customers need to bring their own IP Domain and ESP(Email Service Provider) when using OneSignal.

Project Objective

Increase conversion for Email product by reducing manual process
and automating process of setting up the email.

Challenges

Scoping and phasing of MVP that we can see the traction fast
Email is a complex system. It requires domain verification methods, and other complexity. Our goal was to define and launch the MVP with the system with constraints that were not in place yet to support the full automation.
The financial risk of Email is greater than Push notification
For sending Push notifications, our cost is close to zero - With email, we are on the hook to pay the third party for sending so our financial risk is much more significant.
Scoping and phasing of MVP that we can see the traction fast
Not every user is fully experienced in the email domain. This would mean that we need to make sure that our platform commiunicates the technicalities of it clearly to what users are supposed to do on each stage of the setup.

Competitive analysis

OneSignal does not have sender email verification or domain authentication. To set up customers, the support team needs to ask customers to update their DNS records. I looked into how email platforms addressed the problem.

User flow

User flowWhile OneSignal does not provide a system to verify Sender Email and DNS authentication, we decided to create OneSignal as a service provider on the surface, using a third party for Domain authentication and providing a OneSignal subdomain for customers who do not have their own domain. 

I created a diagram above of the high-level user flow of the steps users need to take to complete the task of setting up OneSignal Email.

Flow chart diagram

I collaborated and provided feedbacks on the flow diagram below with the PM. Throughout iterations, as a designer, my focus was around: What’s the minimum amount of questions we need to ask to get the customers started.

Previous design & Initial design mockup

Below shows the previous UI to the initial mock up throughout the iterations. Along with the improvement from the current UI, we also needed to make sure the experience is consistent to the other ESPs that were already in place.

Iterations

Below are the feedbacks I received and the answers/iterations I provided.
Feedbacks
Solutions I proposed
Leadership: How can we ensure to highlight OneSignal over other ESPs? 
1. “Recommended” badge.
2. Create a hierarchy through a different size of the box - rejected due to consistency.
Design team: How can we make the form fields to take shortest possible time?
Create a required questions and optional questions. Make sure the types of answer fields to be intuitive to filled.
Eng team: When user comes back to the same view after submitting? Will they be able to edit their answers or submit more than once?
‍For V1, we decided to not let users edit the questions
PM: What will customers see when they want to switch from/to a different ESP from OneSignal? (as this works differently from other ESP setup)
‍To ensure all scenarios are addressed, I created the list and the prototype below.

Iteration & Prototype

Launch & Metrics

We launched OneSignal Email on September 2022. Initial plan for this project was to have it available only for the direct customers, but leadership decided to open this feature up to free users to see more tractions.  
Read OneSignal Email Launch Article

Within 48 hours of
launching the feature available to public,
submissions increased by over 500%

making it impossible for the support team to manage.
In addition to the increase in traffic, we saw a large number of malicious users creating domains using our domain. This feature was reversed to a paid-only feature.

Problem

Opening the feature to public raised a huge risk of
fraud and spam since we provide our own subdomains to
everyone who does not have their own domain.

Challenges

One can affect deliverability of the rest in the IP pool
If one IP is flagged as spam by email clients, then it affects deliverability for other customers in that IP pool.
The risk of jeopardizing OneSignal's email reputation.
OneSignal's reputation will be significantly damaged if customers sign up for free email and the email is delivered to spam. We were not qualifying that these businesses are real businesses.
Domain Reputation risk for not validating email addresses
Customers who do not validate or get permission for sending are likely to have a high bounce rate and will hurt our domain reputation. Even if they are not malicious senders.

How might we

Evaluate free users during onboarding and identify bad actors?
Ensure our domain reputation does not get impacted by high bounce rates?
Additional required fields when onboarding
Recipients authorization confirm methods

Competitive analysis

I looked into the competitors to understand what type of information they require when onboarding, as well as how they confirm the recipients authorization.

Where we landed

Throughout many iterations on the type of questions we ask, I proposed the designs below. The team decided to move forward with the final design 10 to implement. This most recent up to date version of design was launched the first week of October.

What I learned

Identify different use-cases and user-flow before designing the UI flow

I learned the importance of having clear layout of different use-case scenarios, before jumping into designing a mockup.

Involve Eng team earlier on, get as much feedbacks earlier on

The project started with ambiguity with scopes and timeline. The picture became more clear as we involved Eng team and others in the product conversion, and making decisions. 

Check out another case study

Elec

Elec

Find the pitch that will give you funding

Product design, strategy

Elec is startup I founded in 2021. I saw shortcomings in founder’s workflow in fundraising process. I iterated prototypes based on UX research interviews, feedbacks and ran experimentations to validate the idea.

Made with ❤️ and coffee in Seattle, WA