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.
"Advocating User-Centred Design to Your Company?"
User what?
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
If you feel that the software in question is hard to use due to the lack of user-centred design then bring a suitable user in and the two of you demonstrate some of the problems to an audience of the bean counters. If you can show that bad UI could lead to lost sales due to user frustration then you're talking their language.
If you want to impress the MBA crowd with ideas, the ideas need to either earn more money (by increasing productivity for example) or save money (by preventing repetitive motion injuries.). The reason user experiences have gotten so bad is that purchasing decisions are often based on cost - which is why offices are full of uncomfortable chairs, cheap CRT monitors, bland cubicles, and bad software. Whatever you do, find a way to frame it around money. That's all MBA's really worry about.
Give them a few UIs. Show them good and bad examples, and ask them which one they would buy. Execs care about money, and they care about selling. They don't care about user experience or whether their product can be used at all, as long as it is being bought.
The UI is the only really "visible" thing of your software. It is what the execs of your customers, i.e. the ones that make decisions whether or not to buy, will see. It is also the only thing they will maybe at least remotely understand. Yes, even if your customer is a "computer" company. So the UI sells the product.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Some users just don't know what they want unless they are told this is what they want.
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
Though I'm not a UI person, I appreciate the importance of user-centered design. I found myself advocating the very same thing in a project recently, but my comments were all brushed off as just not worth the effort, until the testing phase started. Then the list of confused calls for help on how to get the bloody thing to do what they wanted started, followed by endless lists of suggested improvements...
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?"Looking for another job.
You should just update your resume.
I am an MBA: it's not just the money. No matter what the Slashdot-gestalt says. However, you have already indicated in your post that the projects have been sold without regard for user experience. That could mean a lot of things, but for you (unless your ready to do research on the market position of your products, what the target market wants in a project, etc) that means your management does not feel that user experience contributes to the value of the product. That, by the way, means that you do not contribute to the value of the product. You could do the research and demonstrate to the Powers That Be that you could reposition your product and enjoy some kind of sustainable competitive advantage by making your products actually usable, or you could update the resume and enjoy a new life in the Offworld Colonies (A Chance to Begin Again).
There are a _LOT_ of places that want good UE people (Yahoo just put out, like, a zillion jobops this weekend), you should go to them. You will be happier and your current employer will not be impacted.
-jbs
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.
And start looking. Because when the UI skipping is not making enough profit, your lack of a raise will.
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
To the assertion that an undocumented API is better than a fully documented, unimplemented API?
A community that's perfectly happy with EMACS and VI? Who don't see anything wrong when they open the KDE configuration window? Who run an OS that can't even copy and paste anything other than text successfully most of the time?
Hah!
Comment of the year
I don't really see the point in slapping the best UI in the world on your application if it isn't stable and secure. UI is definitely important, but unless your application actually does what it is supposed to I'd certainly give it the back seat!
..to answer this "how would you use the time?"..I'd say looking for another job. Your owners are 'tards. Now it is not clear in the article if you mean software or hardware user interface, but either way, when you are selling a product, it is EXTREMELY important to have a good quality "user interface", and as such, if they think it is not, you are staring at a company that isn't going to make it in the long haul. I mean, I guess as a last ditch example, haul in an iPod and several other players, then ask them which one sells the most, they will say "the iPod obviously", then ask them why they think that is so. Then SHUTUP. I mean it, exactly at that point STFU. (I used to be in sales and was good at it, timing is crucial and you are trying to sell your idea so pay attention) Let them do the talking then. Don't say a word, they will then "sell" themselves on why UI is important if they aren't completely retarded. If they still don't get it, see advice number 1 up above, and just go away, do job, start looking around.
It's not all UI that makes a sale, but it is a big part of it, and all the parts of a product need to be addressed, you can't pick and choose to ignore any of them if you want success.
I think you need to argue that, in software, the UI is the product. Without a UI, or a bad UI, the product is useless.
It is, pardon the stupid analogy, like a car with a broken steering wheel. If the buttons, menus, toolbars, and UI renders 90% of the functionality of your software inaccessible, unusable, or difficult to use, you might as well save time and money and not develop those features.
But we'll know in 10 years what that really means, because software development gets easier (and thus development costs are cheaper) but the UI stays an intractable design problem.
GPL Deconstructed
but I'd use them revising my resume. A software company that doesn't understand that the users come first is missing something fundimentally important in their paradigm.
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.
do you think this is a UI related issue, or maybe that your company doesn't do a good job of balancing short term feature needs with long term product development goals?
how likely is it that someone in sales rammed these things through at the last minute in order to keep the customer beleiving that your company is paying attention to them and make his quota?
its likely that everyone in management thinks that the user interface is important, which is why they are paying your salary. but they just dont have it together enough to make sure that you have time to do your job, and that product developments are planned and executed correctly.
just guessing.
Let's just say that it is a pet peeve of mine, where apps have all the pieces in the right places, but respond so slowly that it's amazing that users remain for a second click. Yeah, my employer knows, and clients reinforce the point, but the path to improvement is... indirect at best. *sigh*
Buy them each a copy of The Design of Everyday Things.
If you want to achieve anything with execs you need numbers to prove your case. I don't know in which business you are in but if you are in SW you might look at the links in this message (http://ask.slashdot.org/comments.pl?sid=196175&ci d=16079080). If you read more of my comment at Slashdot or at wyoGuide (http://wyoguide.sf.net/index.php?page=Cross-platf orm.html) you'll find more numbers and hints.
O. Wyss
See http://wyoguide.sf.net/papers/Cross-platform.html
If you tell businesspeople that good UI is worth doing on its own inherent merits, you'll lose your audience. The reason they are businesspeople is that they like making money. So tell them how to make money with it.
The answer is, brands make money, and good UI makes brands work.
Why is the iPod successful despite other MP3 players being cheaper and having more features? Branding and UI.
Why is (or perhaps: was) the Tivo successful despite other PVRs being cheaper and having more features? Branding and UI.
Why was the Blackberry successful despite other wireless PDAs being cheaper and having more features? Branding and UI.
Do you see a pattern? Good user interface design doesn't make the initial sale, because it is too hard to evaluate in advance of purchase. But it does create loyalty, which is the fuel that drives an effective brand. And the brand drives sales through referrals and cross-selling.
On the other hand, screw up the UI and you screw up the brand, and therefore the sales numbers. What happens to your brand if your front-line customer service people are hostile to your users? Answer: The users learn to dislike your brand, and start avoiding it. But your "front-line" CSRs are the *second* line of defense. The vast majority of customer interaction happens with the product itself. So to a reasonable degree of approximation, your UI *is* your customer service.
Can a branding/advertising/selling effort succeed in the face of consistently poor customer service? Not without huge, unnecessary expense. So can a branding effort succeed for a product that has a poor UI? Same answer. If you have the chance to invest in good UI design during product development, that investment will be offset by the money you *don't* later need to spend on vast, marginally effective ad campaigns.
Or at least, I'd argue it over a beer.
-Graham
Others have already remarked on the competitive advantage in sales of a well-designed UI. You could also look at the other side of the ledger.
If your company is involved with product support, take the support call logs and identify specific examples of how the design of previous products could have been done in a way to reduce or eliminate the problems people call about.
If you have access to the codebase (or to friendly developers), take a look at how much wheel-reinventing happens on successive projects, as opposed to user-interface code/concept reuse based on consistent UI design principles.
Both of those will frame the argument in terms of cost savings, one long-term and one short-term.
If none of these arguments are relevant to your company -- no end-user market (resellers or in-house apps are your company's revenue stream), no end-user support, no stable development codebase, no interest in long-term development process enhancement -- then I agree with the earlier poster who advocated spending the effort on dusting off your resume.
You don't really provide enough info to form a comprehensive strategy.
What kind of competition do is there? Are the products custom applications or commercial products?
One thing to touch on is "People will use that which works well and is easiest to use". That is where you must direct the discussion. Show how poor UI will result in low sales.
It all comes down to the bottom line
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
Lets say for an extra $2000 (either software or development time) you can improve the UI to the extent that it would save users an average of 5 minutes per day. If you have 20 users, that's over an hour an a half of labor saved each day. That 416 hours and 40 minutes in labor savings per year. If your median employee cost is $30/hour it would be a savings of $12,500 per year. So ask your boss if they still don't think it's worth it.
And the same holds true for larger solutions too. A $40,000 discount is worthless when you need to have a 3 man dev team spend 2 years on customizing the solution.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
What you will ultimately have to produce is a CBA (cost/benefit analysis) to support your position. Just having the management try to use the software will not do it.
To get cost, you will first need to define your strategy for implementing a User Centered Design model. Does this mean bringing in actual users to work with the designers or using a usability lab? In the former you may need to pay a user for being part of the team, in the latter you might get volunteers to test but you'll have to pay for the lab. Additionally you'll need to determine cost in increased developer labor and testing.
Then you have to produce the benefit portion. Consider things like:
Once you have assembled your CBA, and can articulate your approach, you'll be in a much better position to present. Don't even worry about whether it affects your job specifically, that is not what will sell it.
A company's upper management, when faced with a decision will tend to lean toward the cheaper appearing solution. Unless you can substantiate a CBA, then cost alone will generally drive the decisions.
This is just one of those non-functional "-ility" type problems.
If you know that deals are getting done that don't meet your domain standards, whether it is security, usability, scalability, disaster recovery, etc.---you need to educate decision makers as to why your issue matters to them. If you feel they have heard your message and continue to make bad decisions, and defend the decisions to you on grounds that 'we need the business' or some such, then you have two choices:
- try to work with what you are given, understanding that it will never even rise to the level of "adequate" in your eyes. Meanwhile continue to educate those dealmakers until they stop listening to you.
- quit
I chose option 1 in my last position (related to IT security) and tried to convince myself it was working---when I finally opened my eyes I moved on to option 2.
What you have to very careful about is feeling that within your domain you are 100% right, and the world would beat a path to your door if only they knew. Sometimes that's true, but sometimes they know and they JUST DON'T CARE at which point you have to recognize that you are working under a completely different value system, and ask what you are doing for your paycheck aside from filling in a bubble on an org chart. "yes, we have a ___ expert on staff!"
Funny thing is that for whatever reason many of the worker bees love to have domain authorities around, and constantly talk them up. However that is very different from actually influencing the worker bees' bosses.
Premature optimization is the root of all evil
...and give examples with charts.
...tell them it because the iPod has a good user-focused design. Then say: "simplicity, complexity, common use cases, easy to use, reliable, etc" It should be easy if *YOU* can remember to be customer/user focused when you present your argument.
The example you should give is iPod. Say this:
iPod Sales: MMM MMM MMM MMM MMM MMM MMM MMM MMM
All Other MP3 Players: MMM MMM MMM
But don't get your hopes up. Unless you are golfing with the CEO/CTO, you are already an outsider, and your words mean no more than the buzzing of flies in the wind to the people who already have the power make those $$$-and-time decisions. If they are not already making them, they will require more than 1-2 hours of discussion to bring them around.
--Robert
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....
to your company. The clear evidence is that they are selling projects without a heavy UI design component to them. The customer is always right, at the end of the day, even if they are ignorant.
/., but the fact is that cost tradeoffs are part of getting a system out the door, and the vast majority of systems that are developed do not have enough economic benefit associated with them that the customer can afford to invest indefinititely. UI design can be expensive, and on a given project may not offer the marginal benefit that, say, database performance tuning does. If this describes the area of the marketplace your company is in, you will be fighting a battle you can't win in getting more emphasis on user centered design. It will depend on the nature of the users being targeted, and their relationship to the owner of the software. If the users are typically employees of the customer of your company, if the pool of users is small, if the users will be intensive, rather than occasional users of the system, if the UI is a small component of the overall functionality, you are unlikely to get agreement to the principle of increasing the focus on user design, IMO.
I ran a web development shop for a few years, where one of our differentiators (we hoped) was our clear superiority in UI design. Sadly, most customers didn't want to pay for the time for high end UI design. It was just a fact of the market. Some did, and we worked hard to educate all customers as to the benefits when we could. But it doesn't always happen.
It sounds like your company sells projects rather than products. In such an environment, what will matter is what gets sold, and your route to getting UI design sold is through the sales team. If I were you, I'd try to work with the sales folks (and whoever does the estimating/pricing) so that they understand how UI design can create a competitive advantage to enable the deal to be sold, and hopefully sold for more money than otherwise. If you can be a competitive differentiator, than you have a chance of realizing their goals.
From my position as manager of the operation, I could see that some projects needed and benefited from high touch expereince engineering, and some couldn't. I cannot sign up to the statement that "all projects need to have the user experience to be perfect". In systems where the user is an employee of the purchasor of the system, for example, the user can be forced to use it regardless of the user experience. Sure, a bad UI has impacts, in terms of learning curve and error rates, but you will not advance your case by asserting that investing in the UI is ALWAYS the right thing to do, because it just isn't. The world is full of systems that meet their owner's needs, despite a bad UI.
It's fashionable to bash managers here on
I was taught to respect my elders. The trouble is, it's getting harder and harder to find some.