The 4 Keys Of A Usable Product, And The Agile Workflow
By Garrett Moon on April 30, 2013 in Code.
When something is easy to use, we hardly notice. In contrast, when something is difficult to use, it nags us with each and every turn, increasing our frustration with ourselves and the product.
As product creators and developers, we have to protect the things that we build from becoming unusable. When we make something ourselves, and understand the conceptual model, a task that seems easy to us may be impossible for another. For example, take the Coffeepot for Masochists by Jacques Carelman. Ease of use isn’t in the eye of the beholder, but in the product itself. Either it is, or it isn’t.
In his book The Design of Everyday Things author Donald Norman outlines the four keys to usability as follows;
- Visibility. By looking, the user can tell the state of the device and the alternatives for action.
- A good conceptual model. The designer provides a good conceptual model for the user, with consistency in the presentation of operations and results, and a coherent, consistent, system image.
- Good mappings. It is possible to determine the relationships between actions and results, between the controls and their effects, and between the system state and what is visible.
- Feedback. The user receives full and continuous feedback about the results of actions.
It Works, But It Doesn’t
Application development is all about building a workable product. We begin with nothing – line one, and a blank page. The act of creating something that actually works is a feat of great proportions. Progress seems easy to track through lines of code and things that technically work.
Developers know what I mean when I say “working.” Usually, we are describing things in only a technical sense as in “technically it works, but no one can actually use it yet.”
But what if we changed our thinking? What if it didn’t actually “work” until it could be used? What if the four keys to usability were the final checklist we used to ensure that our work was done. After all, what good is a feature that no one can actually use?
What sense is there in moving forward with a product that doesn’t actually work for the end user?
I think the problem is that we often separate features and usability into two different departments. First there is the code, the thing that makes it all work, and then there is the interface. But usability doesn’t work like this. The entire conceptual model on which the feature was built ultimately controls how the interface is handled.
Will it be a drop down select or a series of checkboxes? These things have very different implications for every step of the process.
My proposal would be to make Norman’s four keys of usability the final checklist for product approval. In the world of Agile development, this would mean that a story (or task) cannot be accepted unless it meets the final evaluation of usability.
- Is this feature visibly understandable? Will the user get it?
- Will the user inherently understand the concept of how this features works? Does it exclude guessing?
- It is 100% obvious what the action will result it in? Are there no hidden effects?
- Is there feedback? Will the user be made aware when something happens?
If the answer to any of these questions is no, then the feature is not done. The drawing board is waiting.
One of my favorite tales of an unusable product is the Gillette shaving cream can. Have you ever put one in your shower? I have, and I have the rust stain to prove it.
You see, making shaving cream requires three departments. There is the development department, the one responsible for the creation of the formula. Then, there is the packaging department, the one responsible for the creation and production of the shaving cream can. And finally, there is the marketing department, the one responsible for naming and package design.
So we have three departments (Dev, UX, and UI) with nothing in common. And so it goes…
The development guys, the ones creating the recipe, are successful. They create a formula that allows for a clean shave with minimal abrasiveness and a pleasant odor. It also foams up as it leaves a pressurized can. By all technical accounts, they have succeeded.
This formula is then handed to the packaging department. This team follows standard procedure. The acquire pressurized cans, consider the assembly process, and develop a conceivable workflow. Shaving cream is placed in pressurized cans, labeled, and then boxed. By all technical accounts they have also succeeded.
The last step, of course, is marketing. What will this product look like? What will it be? (The last things considered should often be the first, right?). The marketing department develops a name, designs a label, and writes a quippy tagline.
“The best a man can get,” they decide.
By all technical accounts they have succeeded, yet all three of them have failed.
Shaving Cream Fail
You see, that can of shaving cream really isn’t the best a man can get. When the actual shaving cream meets the paint on the can it begins a subtle erosion process – eating away the paint at the bottom of the cylinder. When this erosion is mixed with the water of the shower it begins to rust.
Rust, as you know, stains pretty much everything that it comes in contact with. The result is a little brown ring on the ledge of millions of showers.
Nothing about the Gillette shaving cream can is successful once it is all put together.
But, suppose the three teams began talking to each other. Suppose they had been using the four keys of usability. Suppose they worked collaboratively to solve the problems at hand. What would they come up with?
A new can?
A new paint?
A new formula?
When teams work independently, they don’t work at all. The usability of the shaving cream can was determined by all three departments. They all made “working” decisions that were acceptable by their own terms, but disastrous when brought together.
The point is actually very simple: usability begins at line one.
You see, usability isn’t in how an application looks or works; it is in the whole product from top to bottom.
Back-end developers, front-end developers, UX designers, and UI designers all need to working to accomplish the same goal: Usability.
It begins on line 1, and we should be watching for it with every story. Maybe Norman’s keys can be our guide.