Slashdot Mirror
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?"
Be sure to word your presentation in a way that they feel they will benefit. Show them what increased weight in your job can offer them, rather than explaining what you want.
Better yet, apply this to other aspects in your life. Everything will be much more successful.
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.
Dunx
Converting caffeine into code since 1982
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.
Here is the way I've always looked at UI, and why I've always viewed it as important. The first thing of note is that the User Interface is the way that the consumers access the functionality of the product. If the user is unable to access the functionality, then for all intents and purposes it's not there. Trying to sell (or give away) an application with a poor UI is akin to trying to promote an undocumented library or API. There will be a few hard core people who will invest the time, but the majority of people, if they are unable to see the funcationality they want up front, will simply move on to something else.
Looking at a UI from this perspective, it's obviously important because if a client can't access the functionality they need from your product, then they will simply think that your product is lacking this functionality (I would argue that it IS lacking it, since being able to access some function is part of that function working). Of course, this only goes so far. Following the above argument one could simply put a button for every possible function and let the user sort it out. This is where you get into the second big thing that a UI is good for. Marketing.
I've heard it said that, for any company, half of the advertising budget is wasted- the problem is nobody knows which half. For software, having a good UI is great for marketing. If anyone doubts this, promply smack them upside the face with a print out of all the people switching to OS X, or the feature list for Vista. This is where the eye-candy comes in.
Finally, for an application to really be successful, you want it to become industry standard. To make it to the point where your application is considered industry standard (or just a really good alternative) - or if you are in the business of designing software to order, then for your company to become a common name for C*Os as a development company, then you need to consider efficency of the UI.
What it comes down to is first you have to have a UI that isn't completely braindead, so that people can access the functionality of your application. Next you need to make it pretty so that people will try it, and finally you need to make it an efficent application so that people will continue to use it and buy updates.
A lot of applications are really good at one or two of these, but the ones who master all three really become big players in the software industry. It really applies to all areas of software, and product design in general. You wouldn't ship an MP3 player that required you to open up the machine and analyze the circuts to figgure out if it can play Ogg Vorbis. You don't see any new cars that are shipped from the factory with the weld seams not filed down and the body unpainted, and you don't see many cell phones where you have to go through 12 menues to be able to dial a phone number. Why would you ship software that had analagous flaws?
In the end, I think a lot of people underestimate exactly how much a UI matters, and I think that a sane argument can bring it to the attention of a lot of people. However, if you find that your arguments are going nowhere, then it might be time to start looking for a company where your talents will be valued and put to use.
Famous Last Words: "hmm...wikipedia says it's edible"
Here's one of my favorite posts on the subject. And darn good advice.
Random Musings
Poor UI costs.
There are support calls and e-mails. You'll get a lot for those for simple "features" that are as simple as calling "yourapp.exe -fksd ntfs C:/Windows/YourApp/ dD33145".
It will cost the recieving company money in training, lost productivity, and generally making acquiring and retaining good employees that much more difficult.
It will cost you in maintenence, as a poorly thought out UI is difficult to maintain in the future, and a poorly laid-out feature set is difficult to reverse engineer.
Explain to your company that good UI is not necessarily adding flashy graphics or sound effects, but structuring the application logically in such a way that people with less training (and therefore, cheaper employees) can use it easily. Good UI is the difference between a well thought-out business report and a link to an excel spreadsheet with thousands of pieces of useless, unstructured data. Good UI is really expensive to tack on at the end, but can take as little as two days of planning ahead of time.
Good UI is not flash. Good UI makes employees more productive and easier to support, and isn't as expensive as people might fear it to be.
The ______ Agenda
That's the best justification: a small amount of effort, ONCE, on the interface can minimize the ongoing effort of supporting the product over its entire life cycle.
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
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.
Famous Last Words: "hmm...wikipedia says it's edible"
Give them a command line interface. If they complain, say "Ooooo! Look who wants to be Mister Fancy and Expensive!"
One line blog. I hear that they're called Twitters now.
Generally speaking, if you are working for a company where your philosophical outlook doesn't match theirs, it is unlikely that you will be able to change their minds. The best thing to do would be to jump ship, and find a company that is more aligned with your ideas. For example, in my company, a huge emphasis is put on everyone coding in the same style, at least for the code that is actually delivered in the product. Utility tools that are written to support the product (compilers/debuggers,test systems, etc) can be written pretty much any way you want, in any language that you want). But for the code in the product itself, everyone has to write in exactly the same way. You want to implement the Singleton pattern in C? Ahhh, there is only One True Way to do so in my company. Want to write an assert macro that also sticks out an informative message to trace at the same time? Sorry, that's not in accordance with the One True Way to do an assert, so no soup for you! I drove myself, (and everyone around me) insane, trying to convince management that if you want to keep the best programmers, you can't expect them to accept having to code to someone else's idea of good code. It's just going to annoy them, and they'll look elsewhere for a job. It took me a while to realise that they were never come around to the philosophy of hiring good programmers that don't care about what style code has been written in, provided that it is clear (I mean, a competent programmer should not be phased when faced with any style that is relatively clear). Finally, looking around, I noticed that none of the really good programmers at my company spent much time working on the actual product code. They were either writing tools, or moved into management as fast as possible, depending on whether they wanted to keep coding or not. I followed suit. I am now working on a project where I am writing a virtual machine for the product, in C, and in accordance with the pathetic coding rules, but at the same time I'm writing a high level assembler and a debugger for generating code for the VM. These two tools are written in Ruby, and I'm really enjoying the work. Enough that the code rules that I have to obey when writing the VM have become only a minor annoyance, rather than a major pain in the neck every time I sit down at my desk. Anyway, my point is that it's highly unlikely that you will succeed in changing your company's outlook on the importance of UI design. There's too many egos, and too much inertia involved. Either you have to redefine your job so that the standard rules don't apply, or you have to change your job....