How can we design an onboarding experience to build trust?
OVERVIEW
Role: In-house Product Designer
Key Responsibilities: Lead the end-to-end design process, oversee implementation of the designs, conducted user testing to iterate on the designs, UX writing
Team: Founder & CEO, Business Lead, Developer
Timeline: April - October 2021
Summary: Used insights from 2 rounds of user testing to iterate on the onboarding flow and design it to improve user understanding and trust.
Selected screens from the Upswells App
Background
Upswells is an online platform for employees to provide feedback within their organisation while being completely anonymous.
Employees find it hard to speak up at work because of the lack of anonymity, fear of backlash from management, and the lack of a dedicated platform to voice their opinion in a safe way. Upswells aims to change that, knowing that employee satisfaction has multiple spillover benefits on the business as a whole.
Note: I am going to focus on the onboarding experience for this case study.
The problem
Users needed to trust that they would be anonymous on the app
During the onboarding process, users’ work emails were used to verify their identity to gain access to their private company workspace, and were subsequently deleted from the backend to guarantee anonymity. However, providing their work email IDs made users feel uncomfortable, worrying that their feedback may be linked back to them. As a result, they were skeptical of onboarding flow and the app in general. A big challenge was building trust so that the users understood that they were indeed 100% anonymous.
-
We asked anonymous participants what the main roadblack is in giving honest feedback to their company. Here are some of the responses, that can be categorised broadly into 3 categories: lack of anonymity, lack of dedicated platform, inaction:
“Unvalued junior opinion, honesty isn’t appreciated/taken correctly”
“Consistency of asking feedback. Feels like it’s only suggested to give feedback once or twice a year and is more people-specific.”
“Worried that it can be linked back to me, can create an uncomfortable work environment if it is”
“Criticising senior managers”
“Backlash from management”
“That they will know it’s me!”
“I give feedback it just doesn’t result in anything”
Onboarding flow: version 1
We started off with a basic onboarding flow, trying to emphasise their anonymity through the microcopy.
Original onboarding flow
User Testing: round 1
We found that users struggled to create an account and remained wary of providing their work email ID
We conducted a round of quick user testing in order to gather feedback on the initial onboarding experience.
User interviews revealed a couple of issues with the onboarding flow:
Users didn’t trust that their work email IDs were actually being deleted
Users didn’t understand the purpose of the app
Users struggled to create and remember their login details
Each of these elements were contributing to users feeling suspicious, which was reducing their trust in the app.
DESIGN IMPROVEMENTS
I iterated on the onboarding flow to improve communication
I made a number of changes to the onboarding flow screens to improve overall communication and clarity, so that users better understood what was going on at each stage. We assumed better communication would facilitate increased trust.
A/b Test
We conducted an A/B test to assess options for improving the login process
One of the core issues was that we needed to find a way for users to link their personal email IDs to their account without making them feel like they were losing their anonymity. This way, they could use their email ID to log in instead of their username that they had a hard time remembering.
I explored a few options such as using social log ins, generating one-time magic links to log in, linking phone numbers, and so on, but most were rejected due to feasibility issues and technical constraints. We ended up with 2 main contenders.
Option A was based on the assumption that users might prefer to use a social log in for convenience - which would get rid of the hassle of remembering their unique login details
Option B was based on the assumption that users might be more open to adding their personal email ID in the form of a recovery email, as a backup option to log in
USER testing: round 2
Feedback suggested that users were open to adding a recovery email to their account
We then A/B tested both options through the app Maze. Users indicated that they did not feel comfortable with Option A (social log in), as they were equally wary of using privacy and data concerns through Google / Facebook.
Feedback to Option B (recovery email) was overwhelmingly positive. Users suggested that adding a recovery email did not feel intrusive.
“THAT WAS SO GOOD. I was fully following what was happening.”
“Much better and more clear.
That’s much smoother”
However, users suggested that they would rather have it be an optional feature, if they simply did not want to add their personal email IDs.
So, in our last iteration of the onboarding flow, we made this screen skippable and added a warning that users could get permanently locked out of their accounts if they chose not to add a recovery email.
OUTCOME & LEARNINGS
Users felt 20% more comfortable to give feedback with the recovery email flow
The quantitative and qualitative data gathered from the A/B test indicated that users had a clear preference towards Option B (recovery email), so we ended up implementing option B.
Note: Since the app had not launched yet, and since we didn’t have an integration with a data analytics tool, it was impossible to gather user data beyond what we did. The focus of this design task was to get a basic onboarding flow in place so that we could launch. In the future, I would be interesting in collecting and analysing onboarding completion rates as a proxy for measuring how much users trust the platform. The assumption would be that if users feel comfortable inputting their personal data and completing the onboarding flow, that they trust the platform.
Here’s a peak into what the final onboarding flow looks like.
PERSONAL TAKEAWAYS
Never sacrifice clarity at the expense of making a flow shorter. We added one more screen to the final onboarding flow - although it made the flow longer, it helped users’ understanding, which is more important.
Try to do user testing before the design is actually implemented. Although user testing through clickable prototypes is not perfect, it may bubble up issues and save development time/ costs
Conduct user testing sessions fast and often. We design with assumptions in our minds that are truly tested when the product is put in the hands of real, unbiased people.
