Another product meeting, Wednesday afternoon, June 2019. I and Pavel, my UX co-pilot, were staring at each other, waiting to see who’d be the first to say that once again, we plan to load an A-bomb on a biplane. The plan to add Facebook campaigns, an image editor, and other functions made us excited. What worried us, though, was the app’s interface—it was already hard to navigate and users were finding it more and more difficult to look up the functions they needed.
We wanted to push through at least a couple of improvements which would make the app easier to use. What we didn’t expect was for these few improvements to turn into a complete redesign due to the enthusiasm and support displayed by our development team, or how much they would enhance the app. Read bellow on how the entire process went.
Navigation is key
For a while, we’d been toying with different ideas to help users get their bearings in the app and quickly move between campaigns and data feeds. Imagine that you’re editing keywords in your current autumn campaign, and then you want to edit keywords in a winter campaign you’re getting ready for launch. At this point, you might welcome the option to quickly switch over to the winter campaign, without having to go back to the list of all your campaigns. That’s the simplified version of the hypothesis we needed to put to test.
One proposed solution was to add a breadcrumb navigation. A typical navigation of this type displays the name of the open campaign that’s currently open, and when you click the name you’re returned to the main page. In our concept, a single click opens a dropdown menu with links to other campaigns. Nice and easy.
The hardest part was to set the levels which would be shown in the breadcrumb navigation. After a few designs and iterations, we ended up with two levels: Switch organization and Switch campaigns and data feeds.
When it came to testing, creating an interactive prototype was a breeze. We’re yet to find an advanced prototype tool that’s better than Axure. Thanks to Axure, all it took was a couple hours of work and we could sit down to video chat with our clients, testing to see how they worked with the new breadcrumb navigation or whether they found the proposed solution helpful.
The testing revealed a few shortcomings. Luckily, eliminating them was a piece of cake. Turns out, the whole concept was helpful and improved the app’s usability. The main drawback lied in a lacking breadcrumb level which made the app harder to navigate. Looking back, we have no idea why we ever omitted it:) The update solved all issues we discovered. And it’s this updated version you’ll find incorporated into the app. We’re already thinking up new plans to improve it even more.
If you think that we implemented the new fantastic breadcrumb navigation as soon as we fine-tuned it, you’re about to be disappointed—it had to be shelved for a while. Ever since we started to work on the design, we realized that a few problems were blocking its introduction, mainly the app’s inconsistent structure. That was a tough nut to crack.
We’ve been aware of the issues with the structure for quite a while. But their resolution would have required such a radical rehaul that we had no choice but to wait until there was enough space to do it. The right time came when we and the development team jointly concluded that the page layout needed some work.
Luckily, we didn’t sit around with our hands in our laps, and got a rough version of the new structure ready. The process went something like this:
The first step was to map the app’s current structure. Whenever we’re doing this with an app, we’re surprised to see how many pages or modals are there without anyone noticing.
The next step was to mark problematic spots on the mind map, as well as inconsistencies and possible simplifications. We’ve long used an extremely simply tool to create mind maps—Xmind zen. Over the course of this project we switched over to Whimsical which has the huge benefit of allowing cooperation and draft sharing.
A new draft structure began to be put together, based on the old version but supplemented with data from Google Analytics, accumulated client requests, and requests from the product team. After a few sessions where the structure was fine-tuned by card sorting, we were finally satisfied and the new version of the app started to take shape.
We decided not to test the new structure separately, but only as a part of the app’s interactive prototype where it was easier to visualize.
There are certain things you start to hate if you worry about them for too long and look at them too often. And then there are some things you hate right from the beginning. Like the app’s menu. The left-side menu wasn’t bad in and of itself but contained items no one really used. And most importantly it didn’t exactly promote easy navigation since it showed nothing but icons. What was much worse, though, was the tab-based secondary menu—poorly arranged, horizontal, split in two, and to top it off, with too many items that couldn’t fit a line. There was a lot of room for improvement.
Ondra, the head of development, introduced one of the chief proposals—that we would no longer use tabs for navigation. We agreed, and this strict requirement eventually forced us to design a single app and menu structure.
Another presumption was to go against the trend of minimalist menus in apps and supplement the left-side menu with section titles to make the app easier to navigate and the menu more usable.
The third main decision was to be using 7 items on a single level at most. At this point, we gave ourselves a little lift and divided the menu by headlines into multiple logical units. The result turned out to be quite well-arranged.
The draft menu depended a lot on the draft app structure, and so we had to keep in mind how to visualize this in the menu and breadcrumb navigation while arranging the pages. The first step was to establish the app’s hierarchy. Like this:
1. User and their organization;
2. Organization and its settings;
3. Campaigns and data feeds;
4. Elements of campaign and data feed settings.
The hierarchy revealed that only two levels required a menu. The organization level shows the main menu. Once the campaign’s opened, the main menu items are replaced with campaign settings. The same goes for data feeds or organization settings. The menu was supplemented with a button so that users can return to a higher level.
Our efforts to simplify the menu without overburdening users with a multitude of functions they will rarely use materialized in one specific result—secondary campaign setting items were hidden. Before selecting these items, we analyzed Google Analytics data and consulted our clients, as well as app users.
We took the setting items from across the organization, removed them from the menu, and put them into a single bundle. Now, there were two placement options—the header on the right, or the breadcrumb navigation next to organization selection which made more sense to us in terms of logical placement. We tested both options with users. Turns out, everyone expected organization settings to be placed in the upper right corner even though organization selection was on the other side of the screen and both campaign selection and user settings were visually closer to the right corner.
This showed us that there are times when a less logical solution can be preferable to users as they’re used to it.
When tested, the proposed structure and visualization turned out to be much more usable than the old version. We’re happy with the new menu, mostly because it’s much more scalable and ready for new types of campaigns and functions.
Layouts, graphic design, and testing
But the hardest part still lay ahead. Everything we’d worked on up until then needed to be visualized. We had to design new layouts, change the app’s graphic palette, and find out which emotions the new design evoked in users. Then, everything had to be put together and finally tested to show whether our efforts were successful or not.