Onboarding feature build for mobile app
Company overview
The business is a health and wellbeing company running multiple health care programmes supporting patients during medical rehabilitation. This app works in conjunction with a year-long course which aims to cure patients of type 2 diabetes. The business requires patients to complete certain tasks on the mobile application within set timeframes. This needs to happen for the business to earn revenue. The app has many features to support users’ journeys. These include community support, online learning material, session details, health tracking support and live chat.
The problem
The first launch of the health app had an undesirably low completion rate of onboarding tasks. We were tasked with reducing the number of failed first coach phone calls due to onboarding tasks not being completed. The business outcome was to reduce operational costs by reducing these repeat calls.
Users profile
Our users are people with type 2 diabetes who live in London and are referred by their GP to join a year-long programme to manage their diabetes. The programme is developed to support the reversal of their diabetic condition, improvement in their overall health and reduce dependency on medication.
Roles and responsibilities
I was the Lead UX designer on the app project. I worked with the business, product owner and PM to ensure the business’ contractual obligations in the product were met and validated through user testing new app features before external development.
With the external agency, I worked with a UI designer to complete the design work. Then worked with the external development team to sign off the final solution.
I was directly responsible for:
-
Persona development
-
User testing
-
User flows
-
Ideation workshops
-
Initial wireframes
-
Design sign off.
Project scope
The scope for the project was seven months to build an application which worked alongside the programme. It had to record the required user interaction and engagements for the business to generate income. We had the MVP launch in July and the second phase launch in September.
The onboarding feature was initially moved out of scope for the second phase launch. However the business needed users to complete certain steps prior to a specific date, so the feature was moved into scope. We had a timeline of two weeks to complete the design process and only three weeks for development.
Due to contractual obligations, we had no contingency for delays, scope creep or budget increase.
The process
I followed the design thinking process:
-
Understanding our user;
I wanted to ensure this feature didn’t become a roadblock as we needed the user to interact regularly with the application to receive payment.
-
Defining the feature;
with limited time and budget, I needed to know the business’ specific needs and how to meet these without compromising the user experience and resulting engagement drop off.
-
Ideating the solution;
I worked with the business to ensure we started on visual language to immediately align stakeholders and explore how we can address a user pain point without extending scope.
-
Prototyping the product;
I needed to map out the entire user flow for each week in order to align it to the business engagement timeframes.
-
Testing to validate the experience;
I tested the product remotely with actual users to ensure we were meeting their needs and the functionality did not hold up their flow.
-
Implementation;
In sprint planning, we refined the user stories to accurately convey the designs and presented the development team with the full user flow.
1. Understanding our user’s desperation to be successful in the programme to reverse their diabetes and reduce their dependence on medication.
I reviewed the previous user testing recordings to gather a strong foundation of the issues. Our users’ main feedback was not knowing what they were supposed to do and when. This resulted in some users completing all the online lessons for three months in one sitting, others rushing to complete it before scheduled calls, some missing group sessions because they already had the information on the topic and other users kept their own personal journal to mark off where they were in the programme.
I spoke with a coach who confirmed the users’ top questions were always about what week they were up to. She would also have to remind users of the progress they had made and what they had achieved.
2. Define the feature to meet business needs and how they can be met while improving the user’s experience and comprehension of the programme
We defined the desired outcome would be to reduce this friction point experienced by our users while addressing the business need of reducing programme cost through repetition of calls.
The product owner and I set a meeting with the business to understand the needs of the onboarding feature. We hosted a group ideation session, this was conducted virtually on Balsamiq due to Covid19. In the session we discussed the 8 items requested for the user to complete, we learnt the business only required users to commit to a ‘commitment declaration’ for the programme and complete 6 items prior to their first coach call, and the product owner only needed the user to select a username for the community to complete the app set up. Therefore if we could tie the development of the onboarding feature into a design that could be repurposed for a weekly “to-do” list it could serve dual purposes.
A consideration in the design also needed to be made for the fact that the user would not be able to see their sessions in the app so there would need to be space for additional configurable copy to welcome and inform the user on deadlines for the checklist.
I also wanted to consider the business payment structure for the programme and how it depended on users completing set tasks within an allocated time period at different intervals during the programme. This meant if we could address the user's desire to understand what they needed to do when, with the requirements for the business payment milestones, we could reduce the risk of users not completing the set tasks within the time window.
3. Ideating a solution that would have a due purpose with single functionality, that could be tailored to provide added benefit to enabling the business the ability to align requirements for payments with user activity and engagement
After the ideation with the business, I created a user flow based on a user onboarding experience until the second week of the programme. The product owner requested we include selecting a username into the onboarding workflow was removed as this increased the development costs by 8 hours, we instead used a solution of the user’s login is dual purpose for their community username and with the code auto removing anything post “@” if the user using their email address. The function to change your community profile name was left in place in the app profile settings.
With the final wireframes interface aligning for the development of the feature to be dual purpose, we refined the user stories to ensure we prioritised and focused on value. The change request was taken to the business to sign off cost.
4. Prototyping the user flow for the programme to detail the messaging to users
The product owner and I took this to the business and I worked with Marketing for the copy to make the weekly checklist fun and motivational.
5. Testing the functionality works for the dual purpose
Due to the tight time frames, I took the user flow wireframes and ran virtual user testing to validate our solution. I discussed with a coach who has regular access to a large pool of users on a more regular basis to see if the solution (now fleshed out with content) would answer the questions she regularly sees from users.
The coach explained how this would reduce the amount of reminding, as the user she has worked with often forget the tasks they needed to do each week.
From testing the users advised how helpful they would find it to plan for the programme around their daily lives. They told me how this could help them stay motivated on the programme as currently, they use paper workbooks and calendars to make their own “weekly checklist”.
Due to the enthusiasm for the feature and to align with our user expectations
We moved the new feature location to the dashboard
We added text to the feature to tell users programme stage
We updated the “see next week” to “preview next weeks list” so users could plan but understood they didn’t need to complete the tasks until the following week
6. Handing over the solution for implementation to the development team to build and implement within the 3-week deadline.
I then handed over the finalised user flow and wireframe to the external UI designer to create the final screens and oversaw the development and alignment to designs providing feedback and advice where technical challenges were faced.
Outcome
The app feature is in the September release to the app stores, the coaches are looking forward to the feature helping their users track progress on the app.
The cost of the feature required by the business was not increased, but we managed to also address a user need. We expect that the business will not just see a time saving but a monetary benefit of increased users completing tasks within time windows to receive payment
I learnt if we look at the where the crossover between two problems occur we are able to compromise and have a scope sandbox that enables us to build a solution for both, rather than creating two perfectly ideal solutions which though equally valid will not be signed off due to cost and therefore not have any true impact to the end-user.