Ask HN: Best way to prevent UX arguments with non-UX designers?
Sometimes it seems like I spend a lot of time arguing UX design with non-UX designers. I definitely don't mind the act of explaining this stuff to clients, but it often seems like unnecessary time and energy spent.
I like to keep my clients involved in the process, so is there a good way to avoid these kinds of discussions without just going all the way and coding up the interface before showing it to them (which has worked well in the past but seems a little disrespectful)?
I imagine graphic designers have a similar problem too.
33 comments
[ 4.5 ms ] story [ 63.2 ms ] threadAlso, know your limits. Many times I make a recommendation and suggest that we split test it properly quickly. The "to test" list will grow and it will serve two purposes:
1. A reminder of important tests you really should do
2. A place where bad/low priority tests go to die. You do this by regularly pruning the list with the help of the client.
If they are simple user interaction concepts, then presumably there are examples you can show them. Often that gives them an anchor point where you can discuss things you'd like to change about that specific example.
You definitely need a strong personality/portfolio, and probably a prior agreement with the client.
http://theoatmeal.com/comics/design_hell
I try to be open to suggestion and critic but usually it's quite hard to make even a small change without having to redesign everything else.
Another thing is that non-designers tend to want a justification for things that there is not one. Like it's impossible to justify how some things look or the choice of a some particular color except the "I think it works".
You can explain a few things at first, but at some point they just have to trust you.
In contrast, the cliche is true: everyone thinks he is qualified to critique front end design.
I don't think this is always a bad thing -- certainly the client is the ultimate keeper of his brand, but I can appreciate that the constant second-guessing might get tiresome.
To the OP, all I can recommend is to choose your clients carefully, know them well enough to anticipate the issues, fire the ones that are incompatible, and become expert enough that their default instinct is to trust your judgement. Good luck.
It sounds to me like you want this to be a 'one way street' because you trump others in your superior knowledge of design. But the reality is that everybody - also non designers - will have to feel good and be on board about the stuff they build. So you'll have to do a better job at getting them on board with less effort. And if that can't be done wanting people to 'shut up and just do the job' isn't going to go very far.
You can understand lots of things without being to explain them. It's called instinct, sometimes, taste, other times, experience by yet others.
Do you think the experienced cook can necessarily explain exactly why some things work and others don't?
I very much agree you don't really understand something you can't explain.
Similarly if the UX designer says "this label should go here" he should be able to explain why: "the form is easier to understand that way". And if the client doesn't see why it is easier to understand he should be able to make two versions, and the client should be able to see why one of them is better. If the client cannot see that and the UX designer cannot convince him then it probably isn't better.
I've had cases where the person I'm working with can clearly explain why he feels one UI is better. And I was just as adamant about a different UI. I coded both up ways up, we played with both -- and we were still on opposite sides of the fence.
In this particular case, we ended up throwing both our solutions out the window and found something better, that we both agreed on. Unfortunately, it doesn't work out that easily.
Do you think the experienced cook can necessarily explain exactly why some things work and others don't?
They should be able to!
It's not magic - there are well accepted rules for what works and what doesn't. If they can't explain them then they are probably just following a recipe very well. That's fine, and may make great food, but creativity takes understanding, and understanding means they can explain what is occurring (at least to themselves).
None of those are 'understanding'.
> Do you think the experienced cook can necessarily explain exactly why some things work and others don't?
No, which means he doesn't understand what he's doing, merely that he's built up empirical knowledge about what works and what doesn't.
He can teach that knowledge to someone else but that's just transferring the 'ritual', not the underlying knowledge.
Don't underestimate all of the cooks though, some of them are quite knowledgeable when it comes to the underlying chemistry and the theories of taste and smell.
"But is this really MY problem?" In presenting design ie. communicating its value, the roles/responsibilities are not unlike that of a teacher and students: successful delivery of information is the responsibility of the sender. To say eg. "I taught it to them but they didn't learn it" is a contradiction in terms tantamount to "i sold it to him but he didn't buy it." You as the designer are responsible for 1. understanding the problem landscape well enough to deliver a working solution 2. building a decent relationship with the client (internal or external) that you have a good communication channel.
What are the best ways to sell design to non-designers? Clear objectives you've agreed upon and stuck to. Compelling storytelling. Competitive benchmarks. Pure visual WOW factor. $10 usability tests. Man-on-the-street impressions. Rote logic. Brute force. These are the techniques that I've used successfully. They can of course be combined, and there must be many others. ymmv
If "selling" design is problematic and you're not able to push work through to some kind of test environment where real customers can connect with it to PROVE the design works (via sales / leads / engagement, whatever the objective may be), then you might consider joining forces with a fellow writer or designer, or agency, to watch how designers and creative directors successfully bring clients on-board to sell innovative designs.
CAVEAT: There are always critics and naysayers of any sufficiently innovative solution or design. To those people, I say http://purplejesus.files.wordpress.com/2009/03/haters.gif Let them do better, and prove it.
I admit they often make prettier things (and I'm talking UX designers), but they often do not deign to come down to the level of us mortals who have to implement their wireframes with cost considerations or the like. It feels like they're unwilling to put constraints on their process, so it can make it largely painful rather than helpful.
It feels like the architecture astronauts you get some times in corporate walla walla land in software. Some people have grandiose (and costly visions) and do not feel they can be questioned on those; refusing to accept questions makes everyone else think they're full of crap, because it's usually the guy who doesn't know what he's talking about who starts going off when challenged.
Perhaps you're doing the same sorts of things? You're regurgitating popular layouts, etc, and not really making decisions which can be explained well nor taking into account an economy of development resources.
It's great working with designers under you. But as equals, it's very taxing to work with people who won't articulate reasoning. Questions which may figure that out:
Can you explain how much time different things take to do?
How do you know this?
Do your developers agree?
How much of your dev's portfolios have you gone over (and therefore know what they can do easily/cheaply)?
One easy thing you can do is to write down people's feedback and then read it back to them, letting them know that you are writing their name down next to it. You look accommodating and they feel like their opinion counts. And also, they feel accountable, which makes them less sure of themselves. But only mention who contributed an idea on a new revision if you intend to praise it. If you generated a revision to demonstrate a bad idea, be vague about who came up with them. Say something like "Last time we came up with some ideas to explore..." This makes it easy for them to back out without losing face.
Side note: I notice that a lot of programmers bitching about clueless managers and clients interfering with them doing their job, but it's suddenly different when designers do the same thing, that's when designers are told to be "team-players". Seems like a bit of a double standard.
Its not putting them in the driver's seat without knowledge as you are structuring the design choices to help them in that learning process..
Think of this way, remember the current FedEx logo? You know the one with that nice typography with the arrow embedded in the typography..
If you show someone the other design choices leading up to that choice ..most get by visual inspection..they get that the choice in Font design allowed the visual design to indicate a branding message without stating anything..
As the customer is educated in the process by giving them some structured choices you are in fact training them to trust your expertise and judgement which is a big win for both of you in that eventually the customer is no longer micro-managing the project..
You'll find that people, particularly internal audiences and longer-term clients, get behind ideas better when they understand them. Over time you're more effective and have to do less selling when they either a.) understand why you're doing it or b.) know that you're being methodical and acting with purpose.
It's just the reality of working with people. Good luck.