One of the first books that my mentor Charles told me to read was The Inmates Are Running the Asylum, written by Alan Cooper (the inventor of Visual Basic). Visual Basic is one of the most popular programming languages, thanks to Microsoft and Cooper. Thanks to their work (and that of thousands of others), we now have things like Visual Studio .NET 2005.
When I worked for BTG (now Titan) in high school, my boss told me to read the SEI-CMM to get an understanding of all their “official” software development methodology. Until then I had coded for my business using PHP, Bash and Perl without any requirements documents and just worried about getting the job done. That job definitely opened up my eyes as to what could be done with a planned action of software development.
Inmates is one of those books that causes a paradigm shift in one’s mind. The book changed the way I perceive business and technology because it doesn’t necessarily contradict traditional methods of designing and developing software – it forces one to go through a strong interface-design phase before delving into construction. Why would you build a house without knowing who is going to live there and what he/she needs?
Inmates has a simple interface-design philosophy: define the personas; define their goals; work to meet those goals. I have always been a goal- and objective- oriented person, and reading this book has enabled me to look at the world of software (and especially interfaces) from a completely different vista.
Since Inmates are Running the Asylum, Cooper Design released two other books: About Face 1.0 and About Face 2.0. Both are very technical in their content. Inmates itself is a light read, and as expressed by Cooper, “it’s a book for technology-minded businesspeople and business-minded technologists”.
Here, I focus on two parts of Inmates that Charles and I thought were important. (BTW, The Real Executive Summaries [summary.com] has awesome books in this format.)
Part 4: Interaction Design is Good Business
The current design methods used in technology just don’t work. They yield products that dehumanize people. The “Goal-Directed Method” is a set of guiding rules and tools that solve problems they way they should be solved.
Designing For Pleasure: Personas
Personas are the hypothetical people for whom the application or product is being designed for. They represent actual users. Design of software should be geared towards one persona, not many. Products designed for one persona are better because every extra feature added to accommodate another user will hamper the first user’s ability to get his/her work done.
Persona definitions are very important. Too often we try to stretch and define Elastic Users as our target audience. Doing this causes software to made for too many people, and it fails to do its job properly.
Personas must be specifically designed with great detail. A persona with a name, age, background and skill set provides a great reference point for all those involved. Personas must be hypothetical. They cannot be too representative of a real person. A real person’s needs aren’t always representative of what others might want. Personas must be designed with precision, not accuracy. “It is more important to define the persona in great and specific detail than to have it be the precisely correct one,” Cooper writes.
User skills must be realistically assessed. Most users don’t fit the profile of a “Power User,” “Computer Literate” or “Newbie.”
Personas are an extremely valuable communications tool; they can help quell any arguments over features. All design decisions must be what the persona needs. All features must align with the persona’s goals. Does Persona Johnny have to export to PDF? If Johnny doesn’t, that means adding PDF export is unnecessary. Personas are important for both Designers and Programmers. Both must understand the goals and needs of specific personas by taking on the personality of one. Only then can they both see what is needed in a product and what’s not. Products must be designed for the user, not the buyer. The person buying the product may not necessarily be the person using it. IT managers buy for end-users in a corporation. If the software is designed for the end-users, the manager and the end-user can both be satisfied. Good software designed for the end-user means fewer help-desk calls for the manager.
It is helpful to create multiple personas for a product. The product isn’t going to be designed for all of them. “Some are defined to make it clear that we are not designing for them,” Cooper says. The definition of the primary persona is important. The product must be designed for this persona. If two primary personas will be using the product, then the interface should satisfy both their needs. Too many primaries might mean that the problem hasn’t been narrowed down enough. The best thing to do is to create different interfaces for different personas.
Designing for Power: Goals
Personas and goals are inseparable. They are like yin and yang. “A persona exists to achieve its goals, while the goals exist to give meaning to the persona.” Goals are why people carry out tasks. Products must have a purpose. People use products for some purpose. “You cannot have purposes without people,” Cooper notes. Both are important. That’s why the two key elements of the design process are goals and personas – one takes account of purpose, while the other considers people.
“The essence of good interaction design is devising interactions that let users achieve their practical goals without violating their personal goals,” Cooper says.
Goals are not tasks, and tasks are not goals. A goal is what a person wants as the end result. Tasks are the steps that help them achieve that goal. Tasks can change as technology changes, even when the goal remains the same. A person wanting to eat a well-done steak in the 1800s might have to kill a buffalo, skin it, cut it, trim it, start a fire and cook it. Now a person can drive to Giant, pick up a pack of meat, pay for it, come back home, put it on the stove and cook it.
Another practical goal for people is to go from D.C. to N.Y.C. Two hundred years ago, people would have had to either go by horse, carriage or ship. Today, the same goal can be accomplished by car, train or plane. Maybe in the future, we’ll be able to teleport. (NASA – make this happen, please.)
Programmers design software to fulfill tasks, not goals. Since programs are made up of step-by-step procedures, it’s easier for programmers to design features that meet specific task requirements. “Interaction designers analyze goals,” Cooper writes, “to solve problems.” Analyzing goals helps find better solutions, because that’s what needs to be done: satisfy users’ goals.
Principle of Commensurate Effort: The user is willing to invest extra effort because they know they will get extra rewards for it.
In addition to practical and personal goals, there are corporate and false goals.
Personal goals are simple, universal and personal. Corporate goals are important, since every individual’s personal goals affect them. Practical goals bridge the gap between objectives of the company and the objectives of the individual. False goals are set usually to ease software creation and fulfill task and feature needs.
Examples of Personal Goals
- Not feel stupid
- Not make mistakes
- Get an adequate amount of work done
- Have fun (not get too bored)
Examples of Corporate Goals
- Increase profits
- Increase market share
- Beat competition
- Hire more people
- Offer more products and services
- Go public
Examples of Practical Goals
- Avoid meetings
- Handle client demands
- Record clients’ orders
- Create a numerical model of the business
Examples of False Goals
- Save memory
- Save keystrokes
- Run in a browser
- Be easy to learn
- Safeguard data integrity
- Use cool technology
- Make it look pretty
Designing for Politeness
In order for people to like software, it must be polite.
Polite software:
- is interested in me
- is deferential to me
- is forthcoming
- has common sense
- anticipates my needs
- is responsive
- is taciturn about its personal problems
- is well informed
- is perspective
- is self-confident
- stays focused
- is fudgable
- gives instant gratification
- is trustworthy
Designing for People: Scenarios
Once user personas and their goals have been defined carefully, only then may the tasks be put in place. Tasks can be incorporated as scenarios. A scenario is a concise description of a persona using a software-based product to achieve a goal. Creating scenarios is similar to acting. An actor assumes the role of a character and then tries to become him/her in every respect. To create scenarios of a persona, the designer must think like the persona and try to see how he/she would meet his/her goals.
Daily Use Scenarios are the most useful and important. These are the primary actions that the user will perform, and probably most frequently. Most users only have one or two daily use scenarios. Daily use interaction must be robust and assisted by on-screen help. Additionally, these actions should be customizable and accessible by shortcuts.
Necessary Use Scenarios include actions that must be performed, but are not performed frequently. Actions like truncating tables and purging databases are examples of necessary use that don’t need the kind of customization that a daily use interaction might. Edge Case Scenarios can be ignored during product design. While the code may succeed or fail on its ability to handle edge cases, the product will succeed or fail on its ability to handle daily use and necessary cases. The ability of a product to meet the Daily and Necessary use interactions are what will determine its success.
Personas, Goals and Scenarios are the most important concepts in product design. Others include inflecting the interface, perpetual intermediates, vocabulary brainstorming and lateral thinking.
Products that are powerful might end up with complicated interfaces. To keep the balance of power and simple interfaces, the “inflecting the interface” technique is used. An interface can be simplified by placing the controls and data needed for the daily use scenarios in the main interface, while pushing others to a secondary interface (e.g., an advanced menu).
Perpetual intermediates are users who are neither beginners nor experts. The experience of people using interactive systems tends to follow the bell curve of statistical distribution. There are very few beginners and experts, while the majority of people are intermediates. Beginners usually don’t stay beginners, because they don’t want to feel incompetent. People usually start off as beginners of a certain skill, learn what they need and become intermediates. One they are comfortable with their level of knowledge, they stay where they are. If they can’t learn the skill, they just drop off.
Programmers Design for Experts. Marketers Design for Beginners.
The end result is software that is hard to use, but with wizards for beginners. The intermediates just have to use whatever works, but never really be able to do their jobs the way they should.
Pretending it’s magic is a good way to focus on the goals rather than the tasks. Tasks will change as technology changes, but goals remain constant. If we think that a user’s goals can be achieved magically with a magical computer, it will spawn better ideas of reaching those goals. (Horse … Car .. Plane … Teleportation)
A set of detailed and precise vocabulary can be very helpful in the design process. Parts of the project, UI controls, etc. can be confused between different members of the team or between departments. A good common vocabulary alleviates communication problems.
A way to make great products is to use lateral thinking. Lateral thinking is a process in which reality bats last. Engineers make new products by doings things that are practical, possible and doable. However, to get to great solutions, one must think of the impossible. Following a path in which no apparent solution comes through will either lead to new and amazing ways to do things, or the solution itself. If it’s truly impossible, then that’s reality. “Reality never needs an advocate, because it can never be denied. It is always true that reality bats last,” Cooper says.
In the past, hardware and software were bundled together without much thought to how they’d interact. Users can get frustrated if the two don’t work together. In most hybrid scenarios, hardware designers are in the majority and don’t interact much with the software designers. The goal-directed design process can be used to solve these problems.
In design, less is more. Less interface, less fluff, less everything lets the user do his daily business and achieve his goals without thinking twice about it. As programmers throw code away from their programs when they find new algorithms, they make their program better and more efficient. Similarly, when designers decrease the number of clicks, buttons and icons that a user needs to worry about, they make the product more efficient for them. Doing more with less is always better.
***
Part 5: Getting Back Into the Driver’s Seat
Desperately Seeking Usability
The development process can be improved to allow products to come out which are usable. Before programmers would program, test for bugs and then tweak. This doesn’t work, because the user doesn’t see the product until it’s done. In some places users are brought to test the program while bug testing is going on. This still doesn’t work. Writing code is to interaction design as pouring concrete is to architecture. Proper design must be in the process before any programming begins.
Usability methodologies hand control to the programmers. Once they have finished an application, the users can test the program. User testing and usability methods can only smooth the usability of an application that was designed for a particular user persona – they won’t do much for applications that weren’t designed before they were built. User testing before programming can be done in research settings to glean certain insights that wouldn’t be apparent otherwise. Usability testing should be integrated into the design process and can produce better products.
“To paraphrase the toothpaste people, user testing has been shown to be an effective, decay-preventative technique when used in a conscientiously applied program of Goal-Directed design and regular professional care,” Cooper enthuses.
Multidisciplinary teams with users, programmers, managers, marketers and usability professionals usually don’t work. This “seat-at-the-table” solution fails to put design in front of programming. Programmers have been given the ability to design the applications they code. Since their designs aren’t challenged, they keep programming the applications as they wish. Once they have done this, they don’t want to let others design. Most programmers are good designers, but they just focus their design efforts to meet the goals of other programmers.
Usability professionals believe that you can’t know whether an interaction is good unless it’s tested. Interaction designers rely on their experience, training and judgment to make an accurate evaluation. Style guides are collections of examples and use suggestions for visual or non-textual cues that may be helpful in areas where users might get confused. A certain color button may be used to group buttons that do related tasks, or a gray outline might signify advanced features. These don’t help by themselves and must be used in a case-by-case basis in the goal-directed method. Visual design must be used to compliment the interaction and functionality of a product or application. Cool new technology won’t always help interaction and can make it possible to frustrate users with faster and more powerful systems. Technology requires design to be the complete solution for real users, regardless of what combination of technologies we use.
It is a commonly accepted truth about software development that the way to get good interaction is to iterate. Iteration is an element in good design, to be sure. Many developers, however, think this means pushing out versions of their software in the dark. This process is too expensive and only companies with strong brands, piles of money and lots of time can do this (e.g., Microsoft, Oracle, Google).
