Ask HN: Best way to prevent UX arguments with non-UX designers? | Hacker News Reader

Ask HN: Best way to prevent UX arguments with non-UX designers?

23 pointsjarin32 comments

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.

View on HN

If you can't explain it you haven't understood it. It's not time wasted to get people on board and it's remarkable how much you learn about the thing you are explaining while explaining it.

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're right, and I do enjoy the discussion process for those reasons. I think maybe what I'm struggling with is how to deal with having your years of experience dismissed with an "I disagree." Full stop.

Selling starts at 'no'.

"If you can't explain it you haven't understood it." That's not true.

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?

Being able to do something and actually understanding it aren't the same thing; I'm sure there are many things which you do which don't don't very much understand.

I very much agree you don't really understand something you can't explain.

To some level, yes, experienced cooks can. "I'm adding ingredient A because it adds flavor X/it gives texture Y/has color Z". Perhaps you cannot understand why the effect the cook says the ingredient has improves the result. But then the cook could make a dish with ingredient A and without ingredient A and then you can probably taste or see the difference. If you cannot then the ingredient probably wasn't important.

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.

For the most part, I agree with what you're saying. The only problem is, "better" is subjective.

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.

"You do not really understand something unless you can explain it to your grandmother" -- Albert Einstein

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).

> It's called instinct, sometimes, taste, other times, experience by yet others.

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.

Design is communication, and "selling" design, internally and externally, is the difference between executing great work that users connect with, and just being a good pixel-pusher. I think jacquesm has the right idea but muddles it a bit: all great design is sold, not delivered like a pizza. And great design is very much worth selling, for the effect it can have on the world. While selling can seem distasteful (it certainly doesn't come naturally to me), it's a critical skill for designers, entrepreneurs, and founders. Selling is design.

"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 don't think I've met anyone who can sell a design philosophy as well as you can. It's definitely a talent that requires skill and practice.

I find citing research helps a lot. Keep on top of the latest reports and case studies and use them to draw analogies as to why your suggestion is the best given the situation.

Also, 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.

I like that idea, but A/B testing on the iPhone might be a little tricky with its slow release cycles :)

I find designers often assume things which are trendy/etc do not actually have a factual basis in what works better, nor any sort of references to back it up.

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)?

Treat the customers with respect. Assumptions are there to be challenged. If you had experienced where a particular feature failed, use it to back you up. Otherwise, acknowledge their request, list it down as a point where the two of you disagree. Then suggest that it would be interesting to challenge your own assumptions and experience in some areas, to see if some of these have changed. But to run good tests, it's best to limit the number of changes, or to limit the risks to the customer.

Matthew Inman (who co-founded SEOmoz) did a web comic that neatly captures the design process when non-designers insist on micro-managing design decisions.

http://theoatmeal.com/comics/design_hell

Paul Rand is an inspiration for me. He listens to ALL the requirements and provides the "one" solution, and never shows the alternative options.

You definitely need a strong personality/portfolio, and probably a prior agreement with the client.

I also wonder how to deal this with problem with coworkers which are not designers.

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".

Yeah I've run into that quite a bit. "Tell me WHY you can't have 3 layers of tabs and a search bar across the top."

Answer: You hired me to design this, either trust me and get out of the way, or hire someone else.

You can explain a few things at first, but at some point they just have to trust you.

Being expected to explain and justify your decisions is pretty reasonable, IMO.

Depends, if you have to justify every little thing there's a problem, it can go beyond the reasonable. Either they don't like your work, or they don't trust you, or both.

Sure, but we who spend most of our time working on the "invisible" bits on the backend generally don't have the minutiae of our decisions subjected to a whole lot of scrutiny by the average client.

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.

Echoing, in a way, the comments of others, the most important thing you can do organizationally is explain the why. It's not enough to know and sure, it sucks to have to explain your reasoning when you feel you shouldn't (you're the expert, dammit.)

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.

Mutual respect and patience. I'm afraid that you're going to have to keep explaining things to your clients; if you don't they will feel that you didn't act in their best interests and will feel bitter about the whole issue.

I think that might be part of the problem, I respect my clients enough to try to explain things to them in terms they'll understand, but some of them just look at me like I'm crazy or I don't know what I'm talking about when I'm explaining simple user interaction concepts. It gets frustrating.

Then it must be a trust issue; some of them don't trust you for some reason. There must be a reason, try to figure out what it is so that you can resolve it.

Don't explain it, show them.

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.

Add a duck.

Referencing: http://stackoverflow.com/questions/2349378/new-programming-j...

A bit of arrogance helps. If they're a little intimidated, it gives you the chance to be magnanimous when asking for feedback. This offends people who think they're smarter than you about design, but you can head this off by prompting them by name: "John, you haven't said anything yet, what's your reaction?" This is simultaneously flattering and puts them on the spot, and makes them unlikely to undermine the legitimacy of your voice as authoritative because it boosts their reputation.

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.

It might be better to look at as a way to form a better connection with the client as its always easier if the client understands what you are doing..

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..

Reply on news.ycombinator.com