Bart aber fair: As long as you test it.
The Backstreet Boys might be fucking up your design process.
Let’s talk about two topics that kinda belong together. And also don’t. These two are anecdotal evidence in design decisions and how testing can prevent that.
I will address designers and decision makers here. Designers are all those fine folks who create something new. While I speak from a UX or UI designers perspective here, the same holds true for content creators, developers, strategists and the likes. Decision makers are the ones who enable designers to follow their passion. This might be a client, a company owner or a product manager (or Product Owner for all you scrummies). These gals and guys bring on the project game which sets the constraints that the designers work in.
Dear designers. We’ve all been there. As in all things design there is always some sort of bias when it comes to decision making. After all, we always aim to design as pleasingly as we can. Whether it is an interface design, brand design or a user flow. There is no “objective design”. Our job as designers is to think “user centered” or “human centered” or — if we’re honest — probably a lot of time “stakeholder centered”. So we take the perspective of someone else (sometimes a fictitious person) and design for them. So let’s take this as a given. We design something that we think is great in a project setup for someone else.
Another problem arises when we have strong opinion leaders in our project. This might be a Creative Director, your boss, your client or even you. And sometimes those opinion leaders have not learned to objectively judge a design approach. (Yes, even you. And yes also some CDs.) What I call anecdotal evidence is something we all know. It derives from sentiments like “I have a friend, who really has an exquisite taste and he likes this. So we have to do it that way.” Or maybe the more blunt one “I want it done like this.”
This is some of the worst feedback you can ever get. Maybe it should sound constructive, but it isn’t. It just means pressing a personal, filter-bubbled taste onto a project designed for a broad audience. Honestly — it’s just cherry picking.
Remember the “make the logo bigger” jokes? This is them again. Just a tad more subtle. Or not.
Why this happens time and time again, is not a mystery though. No one would ever tell the guy who is laying the tiles in your house or fixing your clogged drain how to do his job. But when it comes to designing things, it’s a whole different story. Because everyone has a design bias. And an opinion. We know what we like. And because of that we tend to think that we should have a say in this particular matter — especially when our position somehow implies that we need to add our opinion.
Now let me articulate it particularly blunt:
Dear decision makers. We need to talk. I get it, you have very strong feelings on how things need to look, sound or feel. But please ask yourself — is this just your gut feeling? Or do you have factual evidence on why a certain thing doesn’t work (for you)?
If you give design advice to your highly experienced designers — who have worked on countless projects, drilled down into the subject, maybe studied this field and gathered some feedback other than yours — and tell them to “fix” their approach so that you or someone you know likes it better… you might be fucking up your project.
But Leonidas might just save it!
This is a lot about respect. Your employees or the agency that works for you will respect you. And they might bend a lot to make you happy. They might be willing to bend so much though, that it hurts you — not them. If your designer has arguments to back up his decisions and you are just overriding them, please don’t. On the other hand though: If you are not happy and your designer has no arguments — well then of course it’s back to the drawing board. (Also: Danger!)
Even some senior designers will not stop you. Maybe they are frustrated or they just hate conflict. Or they are afraid to lose you as a client, or be denounced as a shit stirrer.
Back to you, my dear designers! I hold the most of you and of the business decision makers to a very high standard. And you should never be immune to feedback. Even people who are uneducated in design might give you very valuable advice.
But the same problem I have with best practices arises again in this context. No single person should brute force their personal taste into a project. And to prevent this, you need a certain skill. You need to be able to say no. And as opinion leaders rarely just take a “No”, you need to have your homework very well prepared. Get your arguments down and be ready to defend your work. Stand your ground.
Anecdotal evidence and personal taste are a problem in design and always will be. But as much as you strive to develop your own style, you should aim to be able to defend the educated decisions you make. Winning an argument based on opposing views is impossible if one of those views pays you. You need to rise above this. Make it not about taste. Make it about facts. Because everyone has a taste — but not everyone knows the facts.
So you wanna talk numbers? Good. Now where do we get numbers from? Hopefully your PM has got you covered.
Test your might
Still reading, dear decision makers? Good. Because this is important. Every designer and every PM worth her or his money will charge you for evaluation. You might not like it, but again you’re actively harming the quality of your design if you scrap the testing. It really is part of the concept phase.
You want to know the quality of the designs you are being served? Ask how decisions were made.
If you get an answer: Good.
If you get results: Better.
If you have cancelled the budget for user feedback or UX testing: Don’t ask.
If your designers didn’t plan any testing: Danger again! Ask them why.
I hear you crying my dear designers. And I feel you. Really, I do. But let’s see it, how it is: If you fail to sell testing, get better at it.
If your PM or boss didn’t sell it: Educate them why it is mandatory. In a polite way. They need ammunition for their sales talks as well. Help them get their reasons together to sell this specific part of the offer.
If your client still scrapped it: Ask your PM to talk to them about the risks of that approach or do it yourself (if you are in the position). They should know and you owe them that transparency. It also helps you prevent backlash by the way.
I’m not talking about the functionality testing or bug fixing part during development. I am talking about user acceptance tests. About user interviews. About click dummies or prototypes being tested, before you build the whole thing. About everything they call user research.
You can do this in a studio. This is highly professional and you will get great results. Most studios offer session recordings, an overarching analysis and invite test persons from their database suiting exactly your project’s needs. Fun to attend for both you and the decision maker — but it’s costly and we are in the middle of a pandemic, so what are the alternatives?
There are some tools out there. As long as they don’t pay me, I won’t link them, but check out Hotjar and Userzoom Go. If you know other tools that work well — let me and others know in the comments. And if all of that fails just set up some surveys. Show your approach to more people. Offer uninvolved people alternatives when it comes to modules or animations for example and ask them what they like better. Every single bit of information helps. But please don’t forget the NDAs.
I talked a lot about pre-launch stuff now. How to let your MVP shine. But have you ever been in a situation where you have sold your MVP and it just stayed that way for a couple of years? Well, at least I have.
Again: Numbers are your friends. The main point of a MVP is not a short time to market. It is to gather relevant data fast. And then to improve it. Add more features that the product needs. To iterate. This is not Jackass or the WWE. Please — do try this at home.
But how can just 300 Spartans defeat the Backstreet Boys?
Tough one. Those guys have sold 130 million albums. The Spartans have not even recorded one. But maybe I can help you out. Here is my take.
As a designer:
- Stop designing a certain way just because you think it looks pretty. Be ready to explain why you made your design decisions.
- Get feedback in. Not just from other designers, but from a lot of people.
- Be able to take feedback. If it hurts your feelings, grow up. Learn to differentiate between personal insults and feedback to your work. This will help you improve as a designer. And probably as a person.
- Be a teamplayer. Help others (if asked) and don’t be afraid to ask for help.
- Look at best practices with a grain of salt. Not every site should look like Amazon or Apple.
- Be prepared.
As a decision maker:
- Never ever bring up anecdotal evidence. Never. Seriously. No. NEIN!
- Don’t cancel the goddamn testing budget.
- Accept things that do not suit your personal taste if the numbers speak against you.
- Ask your designers why they made certain decisions. If they do not have answers, let them figure it out. They might get why you are asking.
- And then trust them.
It’s a cultural thing. And it should be the goal of designers and decision makers to create a design culture where feedback matters. Because it will improve every outcome.
Have fun in your projects, everyone. Run them professionally. And if you don’t have the budget for testing — think about scrapping features before getting rid of feedback. This will save you some serious cash in the long run. Pinkie-promise.
Bart aber fair. An irregular column by Tim Grubbert. Tim is an Associate Partner for the Experience craft at BEJOND. Because we have quite a few Tims at the company, we call him Bart (beard). For obvious reasons. This is where he sporadically shares his musings about all things digital. And the occasional rant.
