Case Study — How to redesign the mobile app navigation with 5 mln daily users within 2 HADI cycles
This case study aims to show how the HADI methodology can be applied in the design process.
What is HADI and Why I Would stand for it?
Let’s start with a bit of theory. What does HADI stand for and how would it be applicable to the product design process?
HADI is the acronym of Hypothesis — Action — Data — Insight formula that has been synthesized based on the PDCA by W. Edwards Deming quality control methodology that depicts the shortest algorithm of product development starting from the initial hypotheses to the ideas verification and production. HADI cycles begin to spark everywhere the idea verification in the shortest possible time has value.
In the perspective of the design process it might help to structure the working process better and give your team the understanding on where the project is. For me the most important impact would be not to miss any steps in each cycle because at the very end each step contributes to the clear vision of what is to be designed and why.
In this case I will show how the HADI approach can be applied to the design process.
Challenge
Livelib is the largest digital service for the book lovers in Russia with 5 million daily users.
Livelib was launched in 2007, since then, it has been raised up to the app with a huge number of diverse activities and an ocean of content (mostly User generated content but not only). This fact led to a highly controversial user experience for brand-new iOS/ Android app users. As an outcome, the retention rate leaves much to be desired.
The ultimate goal was to find out the problems that prevent new users from the quick engagement to the mobile app in the perspective of possible navigation flows simplification.
Kickoff
My team started with the initial meeting with the Livelib Product Manager who shared with us the design brief and the recent research report that showed 43% of new mobile users had difficulties navigating through the app and finding the features they expected. Moreover, 53% of new users mistakenly believed that they could buy or download books from the app.
Instead of the Road Map
In short, this is how the design process has been planed to be done
Now let’s look at each step in a bit of detail
Cycle 1: Hypotheses — Generating initial ideas for the users interview
The initial step of the research was to review the Livelib application and brainstorm the list of hypotheses in the perspective of defining what might cause the usability issues for brand -new users when they install the app.
Outcome: We’d come up with 28 hypotheses that had been carefully kept in a google doc and enhanced each of them with the questions we would like to ask users about. That became the basis of the interview script.
Here is the list of the our initial hypotheses.
Cycle 1: Action — Running Qualitative User Interviews
Once the interview script had been done, we started the interview process. We conducted 13 interviews with users form the target audience, with less than a month experience of using Livelib mobile app.
Outcome: the spreadsheet with raw interview minutes with the users answers and users quotes to keep in mind what users literally were saying. To make the navigation through the findings easier, the positive user feedback was highlighted with green and the negative ones with red color.
Full version of the raw user interview minutes template is available here
Cycle 1: Data — Working on the interview findings
The list of user feedback was way too long and included a lot of feedback not related to the main challenge — to improve the app navigation. Apparently, some sort of constraints were needed. The Customer Question board framework helped to do it just in 2 steps.
Step 1 -Structuring stuff
All user feedback was transformed to stickers. All findings were split into 3 groups of stickers
After that, we held a team brainstorm session where we tried to split all findings to the categories which we created and named through the brainstorming. Subsequently, there were 14 categories, which depicted either user scenarios which appear to be problematic for users or certain functions or solutions that apparently didn’t work for users. This approach allowed us to see clearly the issues that can be solved within navigation redesign and split the issues that were not relevant right now but might be helpful for our client for further discovery.
Step 2 -One- minute ideas session
The second part of brainstorming was dedicated to one-minute ideas sessions when all team members spent a few minutes to put their ideas on how the prioritized issues can be approached.
Cycle 1: Insights — What the research ended up with
The list of interview findings drove us to precious insights. The research cycle ended up with a 1 hour meeting with the client where the research report had been presented.
Insight #1 — Most of surveyed users have the impression that the app is something very difficult to interact with and overwhelmed with contents
Insight #2 — Most of surveyed users need a way to customize the contents in the app so that they could see only those parts they are interested in
Insight #3 — Most of surveyed users failed navigating in the app between left-side slider, right- sight slider, and the tab bar
Insight #4 — Most of surveyed users are lost between the Home screen and the Feed screen, there is no clarity for them what is the difference
Insight #5 — Most of surveyed users can’t go through the Add book / Custom bookshelf scenario
Insight #6 — Most of surveyed users are lost between different search options, they don’t understand why search works in different ways on different screens
Insight #7 — Most of surveyed users mentioned Book search and Book shelves features as most important for them in using the app
Insight #8 — Most surveyed users expect to have the look and feel a sort of the familiar usability patterns that they get used to in other content -related apps such as Apple music, Spotify, Storytel, Netflix etc.
Cycle 2: Hypotheses — User stories and jobs stories
Having the research cycle done and approved by the client, the next step of the design process was dedicated to the prototyping and usability tests.
Prototype building started with the user stories and jobs stories frameworks.
Cycle 2: Action — Building the prototype
Before start building the prototype, we set up several important constraints:
- To follow strictly the brandbook guidance to keep carefully the product values
- To prefer cross platform patterns to keep the developers life easier
- To follow the progressive content disclosure approach to lower the chances that users will feel overwhelmed by what they encounter
- To keep it as simple as possible
Since the app has a lots of content, our major goal was on keep all types of content safe and sound inside the new navigation structure. It led us to a major focus on building the new flows.
When the solution for the new navigation structure had been found, we started building the clickable prototype.
Figma links:
Cycle 2: Data — Testing the prototype
To test the prototype, we prepared the usability test with 16 short tasks to the users that allowed us to validate the suggested solutions.
Usability tests script that we used
Cycle 2: Insights — Where the usability tests ended up
The usability tests insights were captured in the spreadsheet and, due to tight deadlines, we decided to split all insights to critical / not critical.
Critical —the solutions clearly didn’t work and needed further research
Not critical — the solutions worked but got users feedback for further improvements or gave more food for thoughts out of the current project’s scope.
It worth to mention that the critical findings suppose to initiate a new HADI cycle, where, again, the hypotheses are converted to the prototype, prototype is being tested and so on, and so on. Up to the moment when the golden mean between perfect design, business priorities, resources and deadlined is found.
In our case we were quite lucky not to have much critical improvements, it took us about 4 months to go through the research/ design process, after that the project was successfully delivered to the client. But it mostly depends on how much time and resources the company is ready to spend.
So, at the end, here are several solutions that didn’t work on a first try (and that’s completely ok):
#1 — Search mechanics, as one of the most important, got 3 cycles of improvements before we found it good enough to be presented to the client.
#2 — First version of filters in Home and Feed interfaces didn’t work that much, there were still some users who couldn’t find them easily, so in the second version of the prototype filters were moved to bottom of the screen and freezed with the content scroll
#3 — Personalized recommendation customization has been included to the onboarding and got positive user feedback except for the illustrations visual style, so we had to work on the onboarding visuals a bit more.
Thanks for reading!
Don’t be shy to add your likes and comments ;)
This case study is a final project of UX/UI Design 1-year vocational program by GeekBrains online university. Core team: Tatyana Bespalova, Svetlana Usova, Elena Kvasova.
Keep in touch elenakvasova.com
