programming and human factors
by Jeff Atwood
Task-Centered User Interface Design is a 1993 book delivered in digital shareware form, and also available as a PDF. Although it's almost fifteen years old, it's still highly relevant-- a testament to the timelessness of studying human interface design principles. It was written by Clayton Lewis and John Rieman, who were at the University of Colorado at the time. It looks like Rieman works on usability for Nokia now, but Lewis is still teaching HCI in the UC Boulder computer science department.
The book presages so many things we now accept as standard in the usability community: paper drafts, user personas, effort metrics, prototyping, testing, and iteration. It's solid advice written well. And it opens with this crucial warning:
We've designed this book to be most useful for people who are actually developing user interfaces. That's in contrast to the full-time interface professionals who do research and evaluation in large corporations. We strongly believe that effective interactive systems require a commitment and an understanding throughout the entire development process. It just won't work to build a complete system and then, in the final stages of development, spread the interface over it like peanut butter.
Usability is something everybody on your team-- not just the designers-- should be thinking about throughout the lifecyle of your project. If your development team suffers from the delusional peanut butter theory of user interface design, perhaps they should find time to read through Task-Centered User Interface Design, too.
"It just won't work to build a complete system and then, in the final stages of development, spread the interface over it like peanut butter."
Tell me about it... you only have to do this once to truly appreciate the inclusion of interface design from the beginning of a project! It's even worse if you as sucked into a project, years after adopting a sub-par interface.
Ahh, I see that the goofy Yahoo exec borrowed the peanut butter analogy from a prior source...
anthropocentric on September 6, 2007 4:13 AMdamn...makes me wish I had taken HCI when I was at Boulder. I think this class was only offered once a year.
Karthik on September 6, 2007 4:16 AMNice, I'm going to be studying HCI this year. Ill give that a read.
BenGale on September 6, 2007 4:21 AMThis is sooo right. And it also fit in the category impossible to comprehend by a manager.
It usually takes as much time to create a good user interface than to program your software. It has to be done as you go and released often. It also has to be used early. Some times a special life cycle specifically for the user interface might be a good thing.
As I see too often, UI is part of the initial specifications and is created entirely or at the begining (can event be part of initial specifications!) or at the end like the peanut butter analogy. This is dumb.
Great to have a reference where to guide people.
I personnaly think that the process of creating a GUI is deeply different from the process of creating code, which is also deeply different from the process of creating a physical object.
loki.jf on September 6, 2007 4:33 AMUnusually weak article from you Jeff - I would think that your motivation on this should be something more than an "it just won't work" statement from a 14 year old book written by theoreticians. Some examples please? Something can sink my teeth into?
I agree that UI is a very important factor, but it's just one element of the application (though a very important one). I'd like to hear more about WHY "it just won't work". And don't tell me to read the book - YOU wrote the article :p.
Rob Conery on September 6, 2007 4:42 AMI've written a lot of user software over the years and I think it is essential to understand the domain, how the user works (will work), and to understand what is intuitive and what is not. I had a colleague state once that we needed to "put ourselves in the warfighter's seat" and I think what he meant was that we needed to understand what the end-user's needs were and what her expectations were.
Trouble is - there are a lot of barriers - it is sometimes difficult to get the time/attention of the user and sometimes the end user doesn't know what they want. That's OK - that is just software design and development. I like the idea of having some conceptual layouts to talk about with the user, or at least with your team, about workflow. Sometimes a quick mock up in VisualStudio is helpful so that they can "press some buttons" and get an idea of how the program will work. I like the idea of having an iterative process with a feedback loop from the users - at least from testers, assuming you have an independent test team. In fact, I think the more feedback, the better!
I like the MVC pattern as it allows me to be more flexible with the UI without scrapping the entire program when something needs to change. Bottom line - nothing in sofware should be an afterthought - not the UI, the engine, the documentation, the help file... it is really all related, right?
Matthew Cuba on September 6, 2007 5:15 AMRob, what do I look like, Cliff's Notes? Read the book.
http://hcibib.org/tcuid/index.html
If you don't have time, at least scroll through it and read the sidebars which are conveniently marked in highlighter-ish yellow-- and provide lots of real world examples. Here's one:
--
One of Clayton's favorite examples of a thinking-aloud datum is from a test of an administrative workstation for law offices. This was a carefully designed, entirely menu-driven system intended for use by people without previous computing experience. The word "parameter" was used extensively in the documentation and in system messages to refer to a quantity that could take on various user-assigned values. Test users read this word as "perimeter", a telling sign that the designers had stepped outside the vocabulary that was meaningful to their users.
Finding this kind of problem is a great feature of thinking-aloud. It's hard as a designer to tell whether a word that is perfectly meaningful and familiar to you will be meaningful to someone else. And its hard to detect problems in this area just from watching mistakes people make.
--
Usability is something everybody on your team-- not just the designers-- should be thinking about throughout the lifecyle of your project.
Alan Cooper's The Inmates are running the Asylum didn't seem to advocate having everyone from the implementation team on the design team. He seemed to advocate the exact opposite ... a bright line separation between the two.
What if everyone is thinking about design? ... and then they don't agree? (That seems the higly likely.) Using tools like Personas etc only get you so far ... and appeals to usability testing fail at the point where a decision must be made without time to test and reengineer.
Right now I'm doing some on-site consulting for a big corp. The project is to fix the UI on a user-unfriendly web app. They handed me a stack of very professional wireframes and design specs done by a previous IA contractor.
What I've found is that they've done a ton of up front planning based on user requests. The only problem is that users never ask for something they've never seen before, so none of the stuff they hired me for (readability, AJAX where appropriate, usability in general) appears in the documentation. This is okay as long as the documentation isn't considered inviolate scripture.
A good designer's work should transcend the mere requirements, and a good client knows that the reason you hire a designer is to bring more to the table than slavish adherence to specifications.
Nathan Bowers on September 6, 2007 5:29 AMMaybe not Cliff's Notes, but you sort of do look like the guy on the Dummies books :p.
I think my point is that you always provide a really brilliant level of detail to the things you write. Your posts are your own - not regurgitated stuff from books you read. You take what you read and then pose some thoughts around it.
That's sort of what I'm expecting here - the WHY. You've just passed this bit of info along. I can get than from Amazon.
Rob Conery on September 6, 2007 5:54 AM"One of Clayton's favorite examples of a thinking-aloud datum is from a test of an administrative workstation for law offices. This was a carefully designed, entirely menu-driven system intended for use by people without previous computing experience. The word "parameter" was used extensively in the documentation and in system messages to refer to a quantity that could take on various user-assigned values. Test users read this word as "perimeter", a telling sign that the designers had stepped outside the vocabulary that was meaningful to their users."
Great point. A few days ago I was stuck at an ATM behind a guy who was confused by the message "Available denominations are $20 and $5" on the screen. He kept saying, "But I want a hundred bucks, not twenty or five! What button do I press for that?" It never would have occurred to me (nor, apparently, the UI designers involved) that the term "denomination" would be unfamiliar and confusing to people who aren't bankers or accountants.
Alex Chamberlain on September 6, 2007 6:36 AMYou take what you read and then pose some thoughts around it.
And my thought here is "everyone on your project-- not just the designers-- should be thinking about usability, and from the very beginning of the project." Pretty much exactly what I said in the, y'know, post.. above..
That's sort of what I'm expecting here - the WHY.
I consider usability so fundamental that I'm unclear why you would expect me to explain why it is necessary. It's a clear public good. I'd no sooner explain why knives have handles instead of sharp metal blades on both ends. Do I really have to bring up Lotus Notes to illustrate what usability *isn't*? Inscrutable, difficult to use software is the dirty trucker porn of the internet-- it's everywhere. I don't feel like I need to spell it out for everyone. Do you?
You've just passed this bit of info along. I can get than from Amazon.
Really? You can get this digital shareware book, which *predates* Amazon, from Amazon? But you can't find this "book" on Amazon. I didn't even know it existed until a few days ago, and it's a great resource. That-- again-- is the point. Sharing interesting things I've found.
Sometimes the things I post here are simple, even obvious. I personally don't have a problem with that. Simplicity is hard. Common sense isn't common. What can we do to change that?
Jeff Atwood on September 6, 2007 7:43 AMI've never heard of those guys (or the paper) but the fact that one of them now works for nokia makes me want to read it...
Nokia phones are IMHO the most usable mobile phones out there, MILES ahead of anything else I've used. Ok, the iphone looks good too, but I haven't used one and I would't buy one for other reasons.
It would be silly not to listen to usability advice from someone involved in such brilliant product design.
John Sinclair on September 6, 2007 8:37 AMWhat's with all of the bashing of this post?
Jeff found a book, he shared a link as well as his insights; what's the problem?
I, for one, think that this was a great post, and I'll take a look at that book too.
Interesting...
After many years on the implementation side of the fence I now live on the business side, and I find that the inattention to the user is just as prevalent there as with the programmers. And, I think more dangerous since we're the ones designing the whole process that the software is only a component of.
I'll be sending this link out to everyone in my office.
Not that it'll do any good. Sigh.
John on September 6, 2007 10:14 AMA good application is one on which a user can find a feature intuitively , even when they didn’t know where to find it in the first place .This can be attained only by creating intuitive, consistent patterns of navigations/actions mimicking the product domain as close as possible .It is those easily recognizable patterns which make a product effective. Most users expect to find "properties" as an option when they right click on a clicked item in windows. This might not be accurate 100% of the time, but it has made some pretty complex operations feasible in windows and windows applications.
These patterns do not originate from individual developers who are implementing a single use case . They need to originate from the *system architects* who design the system .
A guide line to the developer , such as , "UI for managing a loan in the bank loan origination system should be identical to the folder structure a banker maintains for a loan" will be far more effective than the UI designed by a dev who is implementing the create/update loan usecase .
The sad truth is , due to the difficulties in recognizing the abstractions of business domain and the hardship in following consistent navigational patterns , most apps are in the mercy of some brilliant Alpha developer to create a good UI.
A deeper understanding of the problem domain and better creativity from Team/Project Leads , when translated to simple design guidelines and adhered by the dev team , tends to produce better usable system than one produced by individual contributors who try to mould usability according to their own mental image .
@Aaron G:
"This is in stark contrast to the core Linux design principle, which is build everything with a command-line and make a GUI later if it's absolutely necessary. I wonder when they'll get the message that it's not a viable method of creating usable software."
That's a little harsh, given that the Unix command line is one of the most usable software systems in the world today. Most of the core commands operate on the simple everyday "verb-noun" principle: "rm foo", "ls", "cp foo bar". Fortunately for Unix,* application writers ended up building their apps to mimic the design of those core commands, thus giving us "cc foo.c". Now if only Windows app developers would learn to mimic the Windows core interface... Hmm. Strike that. If only Windows *had* a core interface...! ;)
* - And if you would claim that the Unix interface wasn't successful, just take a look at MS-DOS or Linux or BSD or the Windows command line or Mac OS X or the syntax of your favorite scripting language.
@Nathan Bowers
Bravo and well said!
Garret on September 7, 2007 5:23 AM"A good application is one on which a user can find a feature intuitively , even when they didn’t know where to find it in the first place. This can be attained only by creating intuitive, consistent patterns of navigations/actions mimicking the product domain as close as possible"
I completely agree with the first statement, but I would caution you against blind allegiance to the second statement. Simply mimicking competing user interfaces or modeling the real-world version of something isn't necessarily the best way to make an application usable.
As an example, we're currently working with a vendor who builds software to handle security cameras. The interface faithfully recreates the bank of TVs you'd see in a mall security office; working on the interface I'm always asking myself if the grid-based videos are laid out that way because it's the best possible way for people to work with them or if they're on our screen that way because they were easiest to wire in one area when they were physically on a wall. Maybe we needed to stay with what their users were used to, but maybe stopping and asking, "What do users need to do? How best could that be achieved?" would have led to a better interface. I think too often developers' egos lead them to think the Average User is too dumb to get anything but what they know.
Tom Clancy on September 7, 2007 5:25 AMShouldn't you develop for the lowest common denominator though? If a know-nothing can use an application - an expert is going to be able to use it also. That's what this article is all about - usability. If everyone can use it simply and effectively, it's a product of good design.
Going from previous articles where Jeff says an application should "Do one thing", this also applies to a very inexperienced user. If it does too many things, users get lost in all the detail.
That's why "Simple" and "Advanced" interfaces are so effective in my opinion.. it caters for both. It gives basic users what they need, and advanced users what they want. Just make sure that the Simple interface provides all the functionality required by the majority of users - which means making your product as lightweight as possible.
`Josh on September 7, 2007 5:46 AMActually, it's the Elvis principle of software consisting of peanut butter, jelly and bananas, where:
Peanut butter = interface design
Jelly = testing (and re-testing)
Bananas = documentation
All are usually slathered on, post facto. Worse, I still run into managers and developers who are surprised when you tell them that interface design, testing and documentation *EACH* take as long as the coding itself, or longer.
Then there's purchasing, marketing, HR, sales, shipping/download site creation and maintenance... but that's all another story.
What flavor is "security" as an add on?
west on September 7, 2007 9:40 AMJeff,
"Sometimes the things I post here are simple, even obvious. I personally don't have a problem with that. Simplicity is hard."
With you 1000%.
As important as user interface design is, it is also one of those skills like basic programming ability that many, even many professionals in the business, will simply not have, ever. In addition to wondering "Why can't programmers program?", I constantly wonder "Why can't user app developers develop user interfaces?" Many of them just don't get it.
I'd like to comment on participatory design and the users' environments.
The book urges participatory design, where the users participate in the design. That's great, but make sure the participants are users,
not just the (pointy haired) managers or supervisors. Managers tend to come up with UI's that are easy to learn, but not necessarily the most easy and productive to use. (That may be good if there is high turnover.)
Also, we are talking participatory design, not abdicating UI design to the users. Take into acount other elements of the task environment besides the UI itself, e.g. task related paper on the desktop.
Bad user specified UI can diminish people productivity, cause fatigue, and cause system performance problems.
Example:
The user (management) specified that the initial page would present a list of eligible work items. The user would select which one to work on by clicking a button next to the item.
Sounds OK, huh?
NO.
There were typically a few hundred items in the list.
The work item the user almost always wanted to work on was the one represented by the paper clipped bundle of sheets at the top of the stack of bundles in the user's in basket on his desk.
The 9 digit work item number was on the top of every sheet in the bundle. The users were all adept at using the numeric keypad.
The UI required that the user scroll scan the onscreen list for the item that matched. That required a lot of scrolling and eye movement between screen and paper. The user could have keyed in the nine digit number in 2-3 seconds.
Worse, the SQL query to retrieve the list, appserver time to format it, and browser time to display it caused poor perceived performance.
Solution: Provide an input field for typical use and an option to bring up the list for atypical usage.
DAKra
DAKra on September 7, 2007 11:48 AMJeff,
Have you read the Humane Interface?
http://www.amazon.com/Humane-Interface-Directions-Designing-Interactive/dp/0201379376/
It's a book that summarizes many years of study of designing interfaces. It deconstructs interaction with the computer and has some very insightful ideas. The author builds all of the logic up to the ultimate computer interface - a zooming interface. Highly recommended!
mt256 on September 10, 2007 8:33 AMGreat discussion - in particular, I'd like to add to the post that mentioned participatory design. Any usability professional worth their salt will be able to identify cases where a usability test with actual users will be useful, conduct it in a professional manner while hitting the necessary depth of inquiry, produce an easy-to-consume report, and work with the developers to make sure the changes are implemented in a way that will benefit all the stakeholders involved. Iterative development works in UI design as well as it does in coding.
I also agree with a previous post that mentioned that users will not necessarily tell you how to improve things. It is up to the product team to synthesize solutions out of the feedback that they get from the users.
Stan Drozdetski on October 2, 2007 11:29 AM
"The word 'parameter' was used extensively [and] test users read this word as 'perimeter', a telling sign that the designers had stepped outside the vocabulary that was meaningful to their users."
[OT] I believe that this misreading also tells how users have become accustomed to the appalling spelling mistakes, ambiguities, and usage errors that clog the net. Sort of like peanut butter, you might say.
Pete Wilson on June 11, 2009 1:38 PMThe problem with tabbed browser windows is just the implementation.
In the pre-tabbed browser days, I used to have a lot of browser windows open and they would all appear in the taskbar in a group. Tabs are just MDI windows instead of full window instanaces that are subordinated to a controlling dock. sigh if we truly had an objet oriented window system instead building things on a deprecated MDI API this could be fixed and even improved upon to handle this situation.
Mike Johnson on February 6, 2010 10:14 PMInteresting - this is in stark contrast to the core Linux design principle, which is build everything with a command-line and make a GUI later if it's absolutely necessary. I wonder when they'll get the message that it's not a viable method of creating usable software.
Windows developers do it too, of course, but it's more often out of ignorance than principle.
Aaron G on February 6, 2010 10:14 PMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |