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.
“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.
This 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.
Unusually 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.
I’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?
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.
Maybe 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.
“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.
You 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?
I’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.
What’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.
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.
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 .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.
