
Why I can’t convince executives to invest in UX (and neither can you) - joshuacc
http://www.uie.com/brainsparks/2011/06/08/why-i-cant-convince-executives-to-invest-in-ux-and-neither-can-you/
======
ThomPete
The reason why Jared Spool and the other UX peeps can't convince people to
invest in UX is because clients don't invest in abstractions. And UX is an
abstract term.

It's a descriptor not a skill.

Clients invest in IA, Wireframes, visual design, animation, illustration,
photography, front-end development, back-end development, php, java, RoR,
Flash, Servers, copywriting, SEO, project management (and the supporting
process, whatever you might call that)

All those things make up the UX field and those are what clients buy. If you
know how to do any of them then you are in the business of UX.

Only UX people invest in UX.

~~~
aridiculous
Brilliant. However, I'd argue that SEO, project management, and development
are fairly abstract to many.

Thinking about it more, I think UX has a lot in common with project
management. They're both positions that are about overseeing components. I
mean, it's easy to theoretically overlook why you even need managers period.
It seems like you wouldn't NEED them because all of the component pieces could
do the job, until you realize you do. I just think we've learned over time
that project management is needed. We haven't yet decided if UX (as in,
someone overseeing and synthesizing IA, graphic design, dev) is needed in the
chain of command.

~~~
awj
Except that those have definable effects, or at the least can be based in
definable problems.

"By using $SEO_technique, we were able to move up to $position in searches for
'blah blah blah'"

"Our projects currently run over budget by $ugly_number and blow past their
deadlines by $uglier_number. We need better project management to fix this."

What's a similar "here's how UX/lack thereof is making your life
easier/harder" story? It doesn't _have_ to be abstract, it's just commonly
being presented this way. Breaking it down into something like "an A/B test
showed that people hit the download/purchase button $magic_unicorn_percentage
more times after this kind of design change" can easily put the importance in
terms that anyone at any level of management can understand.

------
jlind
This is one of the toughest things I've learned in the last year or so while
interning (in IT) for a fairly large insurance company. It's especially hard
to affect UX when developers are typically given requirments from someone who
has a specific (bad) design in mind.

Anecdote: Just the other day we had a request come through to have a flash
video (with music) automatically play on the splash page for one of our bigger
applications. We ended up taking it down the very next morning after the
original requestor was getting bombarded with emails and phone calls about it.
I hoped they might have learned from it, but their initial response was to
just move the video to another page and continue to let it play automatically.
We didn't let them make the same mistake twice, though.

~~~
geebee
"It's especially hard to affect UX when developers are typically given
requirments from someone who has a specific (bad) design in mind."

I agree, but that's because I think it's hard to write good software when
developers are typically _given_ requirements but aren't a part of creating
those requirements. The best scenario is when developers are engaged with the
users and actively participating in design. While this approach has gained a
lot of credibility over the last few years, especially with the advent of the
"developer-driven culture", there are still plenty of projects and groups that
want to treat development as the "construction" phase of a project, something
that happens after design and, perhaps these days, "UX".

As a developer, this has been my big worry about "UX" so far. It seems like it
could turn out to be another version of "coders know how to code - but _UX
designers_ know what software really ought to be, so we'll design it, and when
we're done we'll let you know what to code up in your cubicle. Oh, and could
we have some work estimates? Thanks!"

I want to be sure I recognize that developers have their own version of this.
"I'll write up the software, but it'll have a crappy UI. Here, designer,
pretty this up for me would ya? Should take you about a day, right?"

I liked the 37signals notion of the "three musketeers"
([http://gettingreal.37signals.com/ch03_The_Three_Musketeers.p...](http://gettingreal.37signals.com/ch03_The_Three_Musketeers.php)),
a developer, designer, and "sweeper" who can play both roles. All three work
very closely together in a project.

I think UX is a great idea and could be an important park of a development
project, but I'd recommend UX advocates start thinking about how it would fit
into a small team (no more than three people). You really don't have room on
these teams for people who don't contribute directly to the working software
application. As ThomPete pointed out, this means you can't afford staff who
work in abstractions.

I'd see this as a skill set that people in design or development roles should
strive to obtain. If you mainly do design, wireframes, or front end work, see
what you can learn from UX. Same for back end development - sometimes projects
do start with very simple UI and focus on application functionality, so it
could be hugely helpful to consider the context of UX.

As others have pointed out, this is also something you can invest in, because
you get a tangible product.

~~~
jlind
>sometimes projects do start with very simple UI and focus on application
functionality, so it could be hugely helpful to consider the context of UX.

I've found this is one of the more powerful and easy ways to prevent feature
creep, at least for the smaller/shorter projects I have worked on. When I
start with a UI, I find it's easier to ask what the bare minimum of a) inputs
and b) feedback/guidance for the user that needs to exist. In the projects
where I've started with a backend first, I often end up having to create more
noise on the UI side to complete it.

I think this just goes back to your first point, how developers are more
effective when we're involved in creating the requirements. Practicing good
design is going to be more effective when you choose to focus on it up front,
instead of relegating it to something to check off a list when the application
has been developed.

------
powertower
There was a post here a while back that showed one of the anti-virus s/w
companies investing in UX and re-designing their UI, support load dropped
30-90%.

In my own application I've had problems with users not understanding the
meaning of things and what steps to perform.

I design to solve my own problems mostly but do keep the novice in mind, but
even so its difficult with reaching some type of a balance between the levels.

Screenshots...

[http://www.devside.net/images/screenshots/large/local-dns-
re...](http://www.devside.net/images/screenshots/large/local-dns-resolve.png)

[http://www.devside.net/images/screenshots/large/webapps-
inst...](http://www.devside.net/images/screenshots/large/webapps-install-
list.png)

[http://www.devside.net/images/screenshots/large/websites-
add...](http://www.devside.net/images/screenshots/large/websites-add.png)

------
wisty
Convincing isn't every a matter of giving a silver-bullet presentation. It's
always a long process. What you need is resilience, and an idea of what the
ultimate goal is.

Nobody quit smoking because of a single ad. But governments still pay for
anti-smoking ads, because they gradually shift people's opinions.

~~~
ThomPete
But the reason why smoking ads work is because they are supported by data.

There are plenty of examples of campaigns that the government is running that
will never work because there is no data to support the ads.

~~~
adambyrtek
That's a very naive view of advertising. Many ad campaigns are successful
_despite_ hard data, not because of it.

~~~
ThomPete
I have worked in advertising so I wouldn't think I am naive about it.

The difference is what kind of claims you are making and what you are trying
to make people do.

Public campaigns is often about discouraging people from no buying certain
things. Advertising in general is about getting people to buy things.

It's easier to get people to go to mcDonalds than it is to make them drop
mcDonalds.

------
edw519
Nice piece. The title is an instance of the more general case, "Why _nobody_
can convince _anybody_ to invest in _anything_."

Good executives are primarily concerned about the performance of their
organization (whatever that means).

Bad executives are primarily concerned about protecting their jobs (whatever
that means).

Neither one gives a shit about what you're selling.

Find a way to incorporate whatever you're selling into the solution to their
problem. In order to do that, you need 2 things:

1\. Get them to define their problem.

2\. Have something of value to offer as part of the demonstratable solution.

Many of us hackers are pretty good at #2, but in the B2B world, still need to
get better at #1.

------
dylanrw
So many places hire an office manager before they hire a permanent designer.
It's a twisted perpective for businesses that should be focused on customers.

------
mixmax
I think it's quite easy to convince executives in an UX investment, you simply
need to show previous results. _"We did this UX thing for company X and it
improved their bottomline with 20%"_

If an executive doesn't think that's interesting he's incompetent.

~~~
wcgortel
It does sound a bit "pitchy" though, especially if the comparison isn't
direct. If you're telling Coke about what you did for Pepsi that's one thing.
If you're telling Unilever about your work for Proctor and Gamble that's
another.

Also, most people with financial experience will realize that a bottom line
(net income) is an easily manipulated number. I don't think your
generalization is appropriate.

~~~
mediaman
I agree. If you're an executive, you get pitched every day with stuff that
will "improve your bottom line by 20%". Most of those numbers are smoke and
mirrors. It's hard to decipher fiction from reality, which requires often a
detailed understanding of how the number was calculated, what other effects
may have been present, whether there was an impact with other customers as
well (to prevent cherrypicking randomly favorable results), etc.

Execs are busy and it's a lot of work to understand whether that number is
legit or not. In response, they will be jaded to your claims of bottom line
improvement.

