Why I can’t convince executives to invest in UX (and neither can you)(uie.com)
uie.com
Why I can’t convince executives to invest in UX (and neither can you)
http://www.uie.com/brainsparks/2011/06/08/why-i-cant-convince-executives-to-invest-in-ux-and-neither-can-you/
16 comments
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.
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.
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.
"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.
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.
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.
"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...), 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.
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...), 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.
>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.
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.
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/webapps-inst...
http://www.devside.net/images/screenshots/large/websites-add...
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/webapps-inst...
http://www.devside.net/images/screenshots/large/websites-add...
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.
Nobody quit smoking because of a single ad. But governments still pay for anti-smoking ads, because they gradually shift people's opinions.
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.
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.
That's a very naive view of advertising. Many ad campaigns are successful despite hard data, not because of it.
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.
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.
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.
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.
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.
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.
If an executive doesn't think that's interesting he's incompetent.
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.
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.
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.
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.
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.