

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

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.<p>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)?<p>I imagine graphic designers have a similar problem too.
======
jacquesm
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.

~~~
petervandijck
"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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

------
sz
Add a duck.

~~~
sjs382
Referencing: [http://stackoverflow.com/questions/2349378/new-
programming-j...](http://stackoverflow.com/questions/2349378/new-programming-
jargon-you-coined/2444361#2444361)

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

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

