What we learned from redesigning the navigation of a headless CMS
When changing the navigation of your whole app, gut feeling is not enough to go on. As our product started to shift from a small startup into a robust, enterprise-ready tool, we needed to make sure our app structure was up to the challenge. This was an almost perfect project where no one was pushing for a delivery and we could really focus on getting it right.
Let me walk you through how we redesigned the new app navigation — a critical piece of our user experience.
A starting line
I’m a Lead UX Designer on Kentico Cloud. It’s a cloud CMS (Content Management System) web app, you can think of it as a smart content hub to distribute your digital stories to any device.
I’ve joined the team when an original project (an incubated startup focused on content creation) was transforming into a bigger operation — we were gaining some traction in the market.
As we started adding functionality to support jobs of different business roles (copywriters, marketers, developers, …) you can imagine how the app became stitched together after a year.
So what were the main issues that made us pull the trigger on the whole redesign?
Our structure was a mess
In the beginning, our app was solely focused on content creation. There were just a few screens, each with a clear purpose in the user’s workflow.
In early 2017, our product development went into an overdrive and we started expanding the app like crazy (check out the navigation map below).
The app was growing fast, but we didn’t take the time to think about how would all the different roles mesh together in one app experience. We knew we had a problem and did everything we could to mitigate it, but our product priority was to deliver new features first to pick up more traction in the market.
Confusing AND slow?
For our new users, the trial experience wasn’t that great. A big reason for that was the navigation and information structure. During usability testing sessions, users were often having trouble finding the right sections or what’s even worse, finding the navigation at all!
For our regular users, on the other hand, it was frustrating to click just to reopen the menu. They wanted to quickly switch between the parts of the system, open in tabs and see what other sections they can go to.
Our time to shine — Lean UX design
The goal was pretty clear. Decrease trial churn, increase ease of use and boost clarity with which the users can find things. Besides the unwelcoming interaction and visual design, we first had to tackle the underlying issue — information architecture.
First, we used the Lean UX methodology to validate the information architecture. Then we prototyped interaction design that’s based on the new structure.
1. Initial research
The first step was to take every single piece of user feedback we have received about our current structure and all the knowledge we had about our user’s journey:
- We received a lot of feedback from our users through the customer chat
- We had our notes from the regular usability testing sessions
- We had a lot of data from our analytics on what features are used and how often.
We used all of the data to trace a flow of different roles through our app and to map all their touchpoints.
2. Designing and testing the new Information Architecture
Next, we came up with the best-guess new information architecture mindmap, with a strong focus on getting stuff done and user roles. To test the assumptions on an information architecture, we used Treejack. (Disclaimer: no affiliation, but this tool helped us a lot in testing the new navigation structure)
For our Treejack study, we have selected eight scenarios, based on usual tasks our users would do. The scenarios ranged from straightforward tasks like “Change your password” to more complex like “Get an API key to include it in your front-end implementation”. The quantitative data we gathered this way contained task times, success rates and directness measures.
Tree testing allows you to get more data on hierarchy and labels, without the worrying about how it’s going to be laid out in the app’s interface. Turns out starting with testing the architecture first was a good move. We have identified one major issue.
The way we understood our structure was very different from our users. We thought that it made sense to put everything connected to one project under that project in a hierarchy, while our users only wanted to see project settings under the project name. After this last change to the structure, everyone got it and we were getting much better results.
Quantitative data showed us different paths that participants used to get to their target destination, the task times and more importantly first clicks, that helped us understand where they would intuitively look for a specific area.
3. Validating the new visual design
After gathering this data through Treejack, we had enough to start prototyping the new visual design and interactions. We conducted several rounds of qualitative interviews and usability tests and looked closely at how and why participants are choosing their paths. Then we asked a lot of questions and let them speak.
Qualitative data revealed concerns and confusions and let us peek into our customers’ thought processes.
We validated new icons as well — we showed five participants a set of icons and asked them what do they see and what they think would happen if they clicked them. This lets us know how readable our new icons were.
What’s next for us?
The results were good, measured SUM was high and we got a lot of great feedback on new visuals and overall app clarity. After I presented the results to our product managers, we all agreed it’s ready to be developed. And the rest is history.
We are now on the lookout on how will the new navigation impact our trial conversions, any feedback we receive on it and how will it contribute to our overall goals. That’s for another time though.
To quickly summarize our process we…
- Gathered a lot of relevant data first
- Created a mindmap of the new architecture based on user jobs-to-be-done and roles
- Used Treejack to validate if it works
- Conducted usability testing to validate visual design, 2 rounds with 10 participants in total
- Validated icons and labels with 5 participants.
Redesigning navigation? What you should know:
Changing the information architecture and navigation in your project is hard work. If you are looking to redesign your own app, this could help you get started:
- Plan your redesign. What are your goals? How are you going to accomplish it? How will you measure it? Get your data from reliable sources, plan to gather data, start scheduling regular sessions with your users to validate ideas.
- Gather intel on your what your users care about. What jobs are they focusing on most often? What do they do once in a while? How are different roles moving around the product? What are the hardest things to accomplish for them?
- Design (and test) the architecture first, then design visuals. This is similar to wireframes that you build on with higher fidelity. You will waste a lot of resources the other way around.
- Never redesign your navigation on a whim. Just because you started in a new position or something is trendy doesn’t mean it will make your product’s navigation better. Gather data and validate your assumptions first.
- Be resilient. You may need to go through a few dead ends, but if your process is solid, you’ll get there and your users will you for it.
I’d like to thank our amazing team–and co-authors Branislav Sandala and Adela Tofflova. Big thanks to all our developers who made this happen.
If you’re looking for a new easy-to-use CMS you want to use with tech such as React, Angular or .NET, check out our project — https://kenticocloud.com/
