One of the first books that Charles told me to read was a book written by the inventor of Visual Basic. Visual Basic is one of the most popular programming languages thanks to Microsoft and Alan Cooper. Alan apparently wanted to redo it but Gates pushed him to release it. Thanks to their work ( and thousands of others), we now have things like Visual Studio .NET 2005.
When I worked for BTG (now Titan) in high school, Dr. Temple 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, Perl without any requirements documents and just worried about getting the job done. The job definately 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 of how to do things. For me the book changed the way I perceived business and technology because it doesn’t necessarily contradict traditional methods to design and develop software, but 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 they need?
Inmates has a simple philosophy to Interface Design. Define the Personas. Define their Goals. Work to meet their goals. I have always been a goal and objective oriented person and after reading this book, I have looked 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 said by Alan himself “its a book for technology minded business people and business minded technologists”.
I’ve only focused on a few parts that Charles and I thought were important to getting the point across. (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.
Designing For Pleasure: Personas
Personas are the hypothetical people for which the application or product is being designed for. They represent the 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’s ability to get their work done.
Persona definitions are very important. Too often we try to stretch and adapt define users Elastic Users as their target audience. Doing this causes the software to made for too many people, and it fails to do it’s job properly.
Personas must be specifically designed with great detail. A persona with a name, age, background, and possibly 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 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.” Personas can’t have edge cases, and must be designed as an average person, precisely.
e.g. Average people don’t have 2.5 children, but rather 2 OR 3.
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, or it can be thrown out. All features must pass the test of a 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 the specific personas by taking on the personality of one. Then only 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 less 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.” 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.
Defining precise personas helps make software that gives people pleasure. Defining their goals helps make the software better by making it powerful.
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.” They are both important. That’s why the two key elements of the design process are goals and personas; purpose and people.
“The essence of good interaction design is devising interactions that let users achieve their practical goals without violating their personal goals”
Important Personal Goal: NOT FEEL STUPID
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 as the goal may remain 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, star 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 maybe able to teleport. (NASA, When are you getting this released?)
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 to solve problems.” Analyzing the goals helps find better solutions, because that’s what needs to be done: to satisfy the goals.
Principle of Commensurate Effort: The user is willing to invest extra effort because they know they will get extra rewards for it.
As well as practical and personal goals, there are corporate and false goals.
Personal goals are simple, universal, and personal. Corporate goals are important since the every individual’s personal goals affects the corporate goals, which are pretty important. 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, fulfill task and feature needs.
Personal Goals
- Not Feel Stupid
- Not Make Mistakes
- Get an Adequate amount of work done.
- Have Fun (not get too bored)
Corporate Goals
- Increase profits
- Increase market share
- Beat Competition
- Hire More People
- Offer More Products and Services
- Go Public
Practical Goals
- Avoid Meetings
- Handle the client’s demands
- Record the client’s order
- Create a numerical model of the business.
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, then only can 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 as they act in a certain scene. To create scenarios of a persona, the designer must think like the Persona and try to see how they would meet their goals. Two types of scenarios must be created for a user and their goals, the third can be ignored.
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 be able to be accessed 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 another secondary interface (e.g. an advanced menu).
Perpetual intermediates are the type of people that are neither beginner 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, however 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 its 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 the 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.”
Hardware and Software has been bundled in the past without being given much thought to its interactions together with the user. 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 doing 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 Drivers 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 hands the control to the programmers. Once they have done the application, then the users can test the program. User testing and usability methods can only smoothen the usability of an application that was designed for a particular user persona. It 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 find out 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.” 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 professions believe you can’t know if 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 a good element in good design: keep working on it until its right. Many developers however think this means to push out versions of the 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 yadi yada)
Posted on December 14, 2005 by Rahul Singh
0