How we design to deliver value with every step
At Userlane, the designers’ call to arms is “Minimum Lovable Product”. We design small and focus on progressive improvement of existing features as much as on developing new ones. It allows us to maximize the value we deliver to our customers with every single release, and to gradually work our way through design debt towards a stellar user experience. It also makes it easier to get stakeholder buy-in for our ideas.
This is where you might go “Sounds great, but what does this mean in practice?”.
Designing for progressive improvement, the method
The one prerequisite is having all your research insights lined up (whether from user tests, customer feedback, heuristic evaluation…). This is the basis for the grand vision of what our new shiny user experience will be. Then the fun part starts. You will need whatever type of documentation gets the gist of your idea across (I like a low-fi prototype, because it’s tangible, understandable, and you’ll need it for usability tests anyway), and a bit of time.
- Test the prototype with users to get a basic sanity check on your redesign idea.
- Talk to your developers. They can tell you how feasible the design is, how much effort it will entail, and point out any hidden complexity. This will also make the next step much easier.
- This part is crucial. Align with Product Managers. Look into the roadmap. What’s coming? How does your idea support solving these problems? How can it make new features more valuable? At which point would it fit perfectly into a developer cooldown?
- Cut the design into small, manageable chunks, and plan them on that timeline. You don’t need an entire pixel-perfect design at this point, only when you’re getting ready for the implementation of the next chunk.
You should end up with a redesign distributed along a couple sprints, or even quarters. The trick is to ensure every single piece brings in a positive change to your users even on its own.
…and in practice
In January 2022, we released a header update which made it easier for users to identify global settings and their personal profile. It was the last step in a side-project spanning two quarters to go from this:
to this:
Already last year, we identified the following issues with our header:
- Application dropdown was higher than the link to My Account — which made it harder for users to understand applications belong to accounts, rather than the other way round.
- The purple Editor button was simultaneously very prominent visually and a bit unclear as a CTA.
- Inside My Account, a plethora of pages was mixing application, global, and personal settings. Adding any new feature in there would add to the confusion.
- And finally, we had some further application settings living in the Customize section of the Portal.
As addressing all this at once would mean a bigger redesign, we had to plan carefully while keeping the end goal in mind. We wove progressive header and settings improvements around upcoming projects, where they would also contribute to the new features’ discoverability, while keeping them small enough to fit into developer cooldowns.
And so:
1. The absolute “minimum viable” change was to swap application dropdown with My Account, so that’s where we started. When we rolled out Integrations, this change ensured it was clear they live on account level.
2. While introducing Help we cleaned up the Customize section, where the feature would live, to make it easier to find, and we moved some of the more general options to the new application settings. This also allowed us to slim down My Account to purely account settings.
3. The last step, introducing the account dropdown, meant that when we roll out new user roles and security features, it will be much easier for admins and contributing users to find the settings they’re searching for.
Planning progressive improvements this way had further advantages:
- It was easier for the squad to commit to a small additional implementation effort every couple weeks than to a single major change.
- Our training managers did not have to update all affected documentation at once (which would’ve monopolized their time for at least a week).
- We could test usability and monitor customer feedback at every step of the way, in a true agile fashion.
- Rapid UI changes tend to dismay users, so instead of springing it all at them at once, we gradually boiled the frog (note: no actual frogs were harmed in the making of this product).
This approach could be right for you if your (objectively fantastic) redesign idea was ever:
- Shelved indefinitely due to lack of resources, or
- Rolled out in a painfully MVP-ed fashion, never to be improved upon due to a change of priorities.
It ensures that the worst that can happen is solving some user pains over time, which is not as great as solving all of them at once, but still a lot better than none.
