Table of Contents
One of our recent product updates is a streamlined “Launching” tab (formerly known as “Targeting”). It’s where users define which audiences get an onboarding or activation guide and what triggers the guide to launch.
But It wasn’t just the name that changed; various settings were moved to new homes, new information was added, and the entire information architecture of the page changed!
You might be thinking: “So what? Redesigns happen all the time!” And they do. But what’s interesting is that this redesign started as simply trying to add a new feature around AI-based rule creation. So how did we get from “designing for AI” to a page redesign?
Where we started
During our November hackathon, we experimented with allowing users to describe – in plain English – who they wanted to get the guide and then we would translate it into structured rules.
Today, Bento has multiple ways of constructing rules and logic for how a guide is launched, including:
- Classic ways defining rules per guide, like “createdAt is before Jan 11, 2024”’
- Using saved audiences, a collection of rules that were created before
- Manually finding a customer, and then launching a guide to them
- Allowing end-users to trigger a guide to launch by a button press in another, linked guide
Given this existing context, it actually wasn’t obvious where we’d stick the new AI path.
Not only that, but we had heard a bunch of feedback that our customers didn’t know how all the launching methods described above interacted, and this confusion could easily result in errors when creating rules.
That’s when we first felt the tug of a redesign.
Now, we all know the tale of a designer who cried for a redesign. But like with the boy who cried wolf, sometimes the cries can be unsubstantiated and erode trust. So if the cry for a redesign was going to be taken seriously, we had to make sure it had real teeth.
Balance intuition with evidence
Our early intuition was pointing towards a redesign. So, what did we do? Well, we didn’t just ignore our intuition and early feelings entirely, but we also didn’t blindly charge towards a redesign.
We started by cataloging all the feedback we had heard. We also made sure the feedback wasn’t just “from the past”, but an active and ongoing source of friction.
Then, we defined the consequences of this friction. It’s really easy for designers to point to users who are confused. But users have a myriad of asks, and it’s hard to collaborate and get buy-in from simply saying: “but customers don’t like X”.
Intuition can point you towards a path, but real concrete evidence will tell you whether that path is worth going down.
In this instance, the consequence was our customers and users launching guides incorrectly – leading to their end-users getting guides at undesired moments. From this, we determined that a redesign was merited.
Don’t blindly copy or throw away
After deciding that we needed to solve the underlying sources of confusion before adding new functionality, we took a step back and researched how other, similar products, solved similar problems. Stepping back like this can help us understand existing mental models and patterns. When there are existing patterns, re-using them can reduce cognitive friction for users.
We found some interesting approaches other products took, and explored them critically along with our own solutions.
We were also careful to not just throw out our current designs. While they have problems, they also solve key cases, and evaluating them fairly was important. In redesigns, it’s easy to want to throw everything away – but that can include “throwing the baby out with the bathwater”.
Inspiration from others and your existing designs can be invaluable, but shouldn’t be blindly copied or thrown away.
For all the potential options, we evaluated each dispassionately and objectively; we took inspiration when it made sense, not just blindly copying others or throwing away existing designs.
Leave a stronger foundation
Finally, as we started narrowed in on the final new designs, we pressure tested them against the roadmap of future features.
Redesigns are expensive. Not only does it take up design and engineering resources, there’s the opportunity cost of not building something new to solve more customer problems. It was important that we landed on a solution with a longer shelf life.
Great redesigns should not only fix issues, but also set up for future features.
Ultimately the success of our redesign is measured as:
- Solving the friction and confusion that customers currently have
- Setting ourselves up for near term features to be unblocked
- Not having to do another redesign for at least a year
Recap
A redesign isn’t a crazy radical new idea. Apps go through redesigns all the time (maybe all too frequently). As designers, the way we approach a redesign is critical in solving user problems and building trust in our team.
I hope the next time you encounter a potential redesign, the three lessons I learned during our redesign process prove to be helpful:
- Balance intuition with evidence
- Don't blindly copy or throw away
- Leave a stronger foundation
