Advocating User-Centred Design to Your Company?

Bertie asks: "I'm a UI designer at a small company who has recently found himself sidelined on certain projects. It seems that they've been sold without enough consideration given to providing a good user experience, because the deals were done on the cheap. From my point of view, providing a satisfying user experience is not an optional luxury, it should underpin every other aspect of the project. If you were me, and you had a couple of hours to promote the importance of what you do to various people — execs, sales, developers, project managers, and the like — how would you use the time?"

Comments

Show Them the Money

[Dunx]

In this situation, saying your company should spend money to do something because it is the Right Thing is not going to work.

Instead, show them how a poorly considered UI is going to cost the company money, eg through more support calls, or through lost sales because the tool is unusable.

If you can't think of ways in which spending money on UI design is going to get money back, then you will not be able to justify the work to your employers.

And if push comes to shove, you can always take your ideas to a competitor.

Re:Show Them the Money

[dubl-u]

In this situation, saying your company should spend money to do something because it is the Right Thing is not going to work. Instead, show them how a poorly considered UI is going to cost the company money, eg through more support calls, or through lost sales because the tool is unusable.

Absolutely. And if this guy has been advocating things because it's the Right Thing, the best thing he can do to restore is credibility is to say not just where good UI effort will make the company more money, but also where that isn't effective. He can be religious on his own time, but credibility at work comes from being reasonable.

Users? Who are they?

[Cassini2]

Speaking as an engineering professional, user's are what ultimately make or break a project. They determine if it will succeed or fail.

Often you can ship a project without user approval. The people that will use the program/design/machine will not see the results of your labour until it is installed and operational at the customers site. As such, users do not have much impact on many of the initial stages of the project.

People forget that users are the ones that actually use your project. If they raise hell, or if they refuse to use your new technology, then the project is often left unfinished. The company will eventually see the project as a failure. Often the vendor is blamed. It can then be really hard to ever sell another program to that company again.

Users make or break an engineering project. Users determine if you will ever sell a second piece of software to a company again.

If no one uses it, does it matter?

[Jason Pollock]

As with many things, this question is very much situational.

I've worked for organisations where the UI was very important. It was what the customers used day in day out. If the UI was hard to use, customer's noticed it, got it wrong and support calls went up. They would agonize over individual features attempting to decide if the customer would actually understand how to use it. They would even reject customer requested features that, while sounding like something good at the time, would have been hard to understand.

I've also worked for companies where the UI doesn't matter at all. It's there purely to input test data into the system. It's poorly organised, hard to use, buggy and generally abusive. Amazingly, the customers don't care. The UI is only there to provide the purchasing manager a tick on their checklist - "Does it have a GUI? Yes. Is it written in Java? Yes." However, after purchase, every single customer then integrates it into their own call center systems and never uses the GUI provided with the system.

So, in one, a UI designer is very important. In the other, GUI work never gets funded, and rightly so.

Where does this company sit?

Jason Pollock

Re:How do you respond...

[miyako]

I think that an undocumented but fully implemented API is better than a fully documented but completely unimplimented API, if those are really my only options. However, if I am looking do so something and I find a well documented, complete (or nearly so) API that does what I want to do, I am very inclined to use it. On the other hand, if I am presented with an undocumented API, I am much more likely to look at other options, roll my own, etc. There might even be cases where a fully documented and unimplemented API might be better, giving me the chance to implement the code with all of the design and documentation needed already there.

Make them happy

[AndroidCat]

Give them a command line interface. If they complain, say "Ooooo! Look who wants to be Mister Fancy and Expensive!"