Dealing with tradeoffs in design iteration
A designer friend of mine recently asked an interesting question on twitter —
The hardest part about this question, especially for someone who thinks of data as having a higher degree of truth, is unseating THIS worldview and giving space for other disciplines (design is after all a growing mess of many disciplines anyway!) to dictate what gets “traded off” in each design alternative. You have to put in the effort to expand your understanding and vocabulary to have more reasons to describe why one design alternative is better than the other.
Often times that means drawing from usability heuristics, brand consistency, behavioural psychology, engineering feasibility and other related concerns to make a compelling case. Reading about these disciplines and talking to your teammates will help build this ability to identify potential tradeoffs. Usually many loose directions to the solution are discussed in early meetings so it would be a good idea to take note and explore them when you work on iterations/prototypes.
In my experience so far, user research conducted in very limited conditions (2–3 users, a basic prototype) may not tell THAT much about what works and what doesn’t. The researcher might be biased into reading too much into individual actions. On the other hand, analytics data often only tells the quantum of something, leaving the reasons to speculation.
When you work on products with very high variability in process and persona (enterprise, for example), UX studies take a long time (months, even) and you get very high level insights for super personas based on a limited set of tasks or questions that can be asked of users who have limited time to offer. If you constantly rely on data to inform your design, it gets exponentially harder to procure useful inputs for complex products.
Regardless, getting good at articulating tradeoffs WHEN NECESSARY is a great skill to have as a designer. I want to discuss three distinct points in the timeline where you can keep tradeoffs in mind.
Before the review
Get really good at iterating on design
I think iteration is a really underrated skill and often doesn’t get enough attention during the design process. Explore many ways of approaching the solution and always document pros and cons along each iteration. Most times it isn’t about not knowing how to articulate trade-offs but them being implicit in the iterations and being hard to recall during a review. Document them.
Here’s a tip, anticipate concerns your stakeholders might have and iterate based on that too! For example, if you know that your PM tends to always comment about the CTA and primary actions while your Content Designer might bring up the location of reviews and ratings, make iterations that address best case scenarios of each of these, giving different weightage.
Another thing that helps when you are trying to identify tradeoffs in your design is doing a decent job at secondary research — looking up previous studies, competitor products, customer reviews, other communication that hinted at how the experience may or may not have been optimal for some reason. If this isn’t part of your role (you might have a dedicated UX Researcher for your team) then get hold of the person who might have this knowledge and give them a peak into your early iterations. Getting their support in the review meeting later will be an important thing. Experience designing for similar products or solving similar problems come to your aid over time so it’s okay to not be particularly good at this when you are starting off.
During the review
This might sound counter productive but DON’T come to a review meeting with a lot of different design alternatives. It adds to the complexity of the discussion and cognitive load of the review for all the stakeholders and saps their energy. What should you do instead? Get really good at articulating why the one design you are going ahead does all the the baseline stuff well enough — solves the problem, makes it easy for users and is likely get support of across stakeholders to take to the next step (hat tip to @tomgreever for these simple heuristics for good design).
One aspect that gets overlooked is that the presentation of your work requires as much care, editing and practice as your design production work. The higher the stakes, the more time you should be spending on getting the details right. But it is still possible that someone remembers a suggestion they had given or mentions a very close alternative that you ditched in favour of yours — this is the appropriate time to bring up your design file and explain why you didn’t go ahead with it or why it was a close second. Prototypes may sometimes communicate the cons better than a static mockup. So choose your presentation mode accordingly.
If you would have done your homework and documented things well, most often you will be able to clearly articulate and justify your design but here’s another tip, don’t get disappointed if something comes up that you hadn’t accounted for. After all meetings like these are exactly for that purpose, to expose blindspots. Think of it as a valuable input from the team rather than a personal failure.
After the review
Assuming you have notes, further iterate and explore alternatives if required. Sometimes, tradeoffs become more clear when you prototype things and bring them to life rather than thinking it up in your head. If you didn’t get enough time to discuss a suggestion, pull in that person and work on the alternative together or get more details so you understand the feedback properly.
In all possibility, the suggestion might turn out to be a design that gets more approval and the green signal. And that’s absolutely fine. You did your job of following your process rigorously and putting your case forward sincerely. Sometimes, until the rubber hits the road no one can really be sure what all the tradeoffs are. :)
