I usually get a bit freaked out when I join a company for a product management position and there’s some sort of “redesign” project in progress. I have nothing against redesigns, provided that they are conducted on top of a consistent rationale and based on solid research about the customer and the design problems that they are aiming to solve before jumping into colours and buttons.
However, the situation that I most commonly encounter is a bunch of teams doing full redesigns of particular screens of an application. We’re in the middle of a revamp of the cart page or The search page results has such an outdated feel are, despite common, probably not the attitude you want to have whenever you’re handling a customer-facing application.
Page redesigns are a sure way to create a Frankenstein-like experience on your product. One team is redesigning one page, with a particular intent, and the designer in charge might have a certain “taste” for colours and elements. Components are not reused or updated, visual flows break, and certain pages feel like they don’t belong to the product anymore. Add to the equation a bunch of opinions such as can you bring this field a bit more to the left and I don’t like this colour or can you show me some more versions so that I can choose from and the recipe for disaster starts to cook. Redesigns very quickly slip into being a complete waste of time of everyone involved — and, most of all, of company resources.
The redesign process as commonly taken is what I call a microcosmos of design hell. There are three layers or circles in this hell that I would like to explore.
No offence, I hope.
UI design is supposed to
- Reduce cognitive overload as much as possible by being clean and smart;
- Allow users to achieve their objectives successfully;
- Be effective on managing expectations.
In summary, it’s supposed to be a vehicle for the product to do the job that the consumer hired it to do — it’s means to an end. UIs should be delightful and charming, and should feel slick, modern and clean — but, above all, they should cater to the functional and usable aspects of the product in question.
This means that whatever redesign that you want to conduct should, at first, consider usability, flows and information hierarchy. The styling of the visual elements should be the last step of this decision making process — don’t jump into redesigning for style without considering the impact of the changes on the product as a whole. The visuals are there to serve a purpose, and not only to be beautiful.
The important questions: which feelings do we want to evoke in our customers? Which metrics do we want to impact? Which processes do we need to facilitate or which funnels do we need to improve? Redesigns should start from a clear perspective on the results expected and from defined measurements of success.
Don’t design for screens or pages — design for components.
The problem with designing for screens or pages: consistency tends to be sacrificed in the process. When you design “screens”, you are tempted to propose another colour for the button, another shape for the image, another behaviour for a field, because we all want to innovate and, if we’re redesigning for “visuals”, this means that “visuals need to look different” in comparison with the current state.
As the new design goes into development, the problems start to appear: the new button colour or style doesn’t fit the look of the pages that aren’t part of the redesign “project”; the new shape for the image is round on one page, but remains square on the other; fields on the new page are displayed with errors below them, but fields on other pages already had errors grouped on top of the form; some buttons have shadows or rounded edges on some pages, others are different. Enter customers who become lost and confused by the lack of standards, and developers who start to create devil code to support design hell.
The reason why complete redesigns of single pages create confusion is that users who are accustomed to the product’s current design and organisation will not recognise anymore the elements that are required to perform the tasks they need. No one wants to spend time re-learning platforms or remembering how to use a product — hence good platforms being heavy adopters of design patterns and iteration-based design in order not to break recognition. Recognition isn’t just useful: it also make people feel “good”, since we all like it when accomplishing our goals is easy — this is also known as the “principle of least effort”.
The basis of all this is the “MAYA” principle (“Most advanced, yet acceptable”):
The adult public’s taste is not necessarily ready to accept the logical solutions to their requirements if the solution implies too vast a departure from what they have been conditioned into accepting as the norm. (LOEWY, Raymond)
Successful redesigns are evolutionary and component-based: the new components are changed throughout the product and cross-device, and not on a single screen for mobile or desktop. Serious products change one thing at a time so that users are not scared away and are given the chance to form new habits around the product. Design for components is not only more consistent for the end user: it’s also way more maintainable and works in favour of the speed of the development team.
“Can you show me three versions to choose from?” — Errrr… no.
It’s not uncommon that this type of request comes from the well-known highest paid person’s opinion, or HiPPO — especially when this person is keen on controlling decisions and having a say on whatever is being done. It’s also usual of the people who ask for such a thing to be completely unaware of what a design process means. When we, designers and product managers, hear this, we should understand the underlying concept behind it.
When a designer is working on an interface, s/he is in charge of many choices and decisions throughout the process. S/he is thinking about readability, contrast, hierarchy, visual solutions, style. There is (or should be) a heavy logic behind each and every one of those choices. These choices respond to the brief received about the brand and the problems that the product is trying to solve. So, putting it very simply: as a designer goes through a responsible design process, what s/he does is answer questions with arguments. Each argument results in a design choice, which has, in the end, a visual outcome, and the design proposal is the child of this process. Asking for three versions to choose from is the same as asking for someone’s name and expecting three different answers to the question.
If the designer could have come to a different conclusion based on the information received, s/he would have done it when going through the first iteration. The conclusions change when the information that supports them change. So there’s absolutely no way in which “creating three versions of a design for the CEO to choose from” makes any sense. The final choice will be guesswork from the HiPPO anyways, so what is the value?
The designer should come up with one version, bring up all the rationale behind it and, from that point on, iterate over it as the requirements change. When did “design by committee” ever work? Uh, never.
The problem gets big when the designer in charge cannot properly voice or articulate the reasoning behind the choices, and, thus, makes the process seem arbitrary or simply a matter of taste — and then, in a game of opinion versus opinion, hierarchy tends to win. HiPPOs love to optimise based on their “insights”, or their friends’ opinion, or the newest feature launched by Snapchat.
This is a sure way to backfire the redesign process — also because HiPPOs don’t usually know much about patterns and recognition, and will tend to ask for changes that create a mismatched experience all over (sometimes with very poor substance, such as “but that’s how Facebook does it”, or “it’s a best practice”). The way to conquer this circle of hell is to steer your HiPPO by being smart and by having strong fundaments to your decision-making process.