The following checklist identifies core principles and best practices to assist software designers and developers to produce software that stands out in the marketplace.

1. Concepts from the product’s subject domain (for example, systems management) should be central and apparent in the software design – The relationships among user interface objects in products should be accurate, so that users can rely on their previous experience in the domain when learning and using the software.
2. Keep it simple – Give easy access to the features that most users will need most of the time; features used less often or by only a subset of users are placed less prominently.
3. Optimise the design for the most frequent or important tasks – Understanding how users will use the software you are designing is critically important. Designers should use that understanding to anticipate the information, task flows, and features that users require at key points within the user experience.
4. Make the interface accessible and visible to users – Design your Web site or application so that users can view and easily access objects or information within the interface. Choices should be visible to users rather than hidden with cryptic key sequences. When objects and choices are immediately visible, users learn and complete work tasks efficiently.
5. Use proper default values when supporting complex tasks – Use good defaults so that users can complete tasks relatively easily and quickly rather overwhelming them with choices.
6. Be flexible – Let users customise the application to meet their unique needs. For example, specialised users could be given a way to make secondary choices more prominent in the product. Also, don’t limit users by artificially restricting their choices to a “correct” sequence. Flexibility is also enhanced by letting users select options in various sequences and in letting them modify default values.
7. Keep your users informed and in control by providing informative and timely feedback tailored to the current situation – For example, progress indicators let users know that their system is healthy and is carrying out their request. At a minimum, alert users when they take actions that will result in the loss of data. (Ideally, such choices would be disabled or even eliminated when they are inappropriate in a particular situation.) All the information included in the feedback should be meaningful to the average user.
8. Things that look the same should behave in the same way, and an action should always produce the same result – Avoid modes that change the effects of actions. Where modes are unavoidable, make them clear to the user and easy to change.
9. Provide the ability to undo and redo actions – Applications must provide users with the ability to freely explore applications (which includes the ability to make mistakes) without fearing permanent damage.
10. Make your application predictable by using industry standard user interface conventions wherever possible – For example, users should be able to use standard selection models and keyboard equivalents like Ctrl+C and Shift+→ (to copy the currently selected object and extend the current selection one unit to the right, respectively) everywhere they work with data. Use a common set of design patterns and guidelines so that users don’t have to relearn how to perform common tasks.
11. Always keep your target users in mind as the product is designed – Developing personas and identifying and defining the roles your users fulfil can help you understand how various roles will use your product. Designs based on typical workflows and the other software that users might use in conjunction with yours will delight users.
12. Avoid adding features just so they can be ticked off a list – Remember that every additional feature equals a set of choices added to what is likely already a wide array of choices. Too many choices can overwhelm users.
13. Design your user interface so that it can be localised for other geographies without redesigning the interface – For example, don’t crowd form controls too tightly so they can accommodate longer German translations.
14. Consider persons with disabilities when designing your applications – Many users of your product may have impaired vision or physical limitations that affect their ability to use a mouse or a joystick.
15. Design the application so that contextual help is available to users when they need it – Users should not have to refer to Help constantly to complete their tasks.
16. Bring objects to life through good visual design – The goal of visual design in the user interface is to surface to the user in a cohesive manner all aspects of the design principles. Visual design should support the user model and communicate the function of that model without ambiguities. Visual design should not be the “icing on the cake” but rather an integral part of the design process. The final result should be an intuitive and familiar representation that is second nature to users.
17. Create user interfaces that promote clarity and visual simplicity – The following visual design principles help create that effect:
    • Subtractive design – Reduce clutter by eliminating any visual element that doesn’t contribute directly to visual communication.
    • Visual hierarchy – Understand the importance of users’ tasks and establish a visual hierarchy of these tasks. An important object can be given visual prominence. Relative position and contrast in colour and size can be used to convey task importance.
    • Affordance – When users can easily determine the action that should be taken with an object, that object displays good affordance. Objects with good affordance usually mimic actual objects.
    • Visual scheme – Design a visual scheme that maps to the user model and lets the user customise the interface. Do not eliminate extra space in your image just to save space. Use white space to provide visual “breathing room.”

Just as a composer follows a set of harmonic principles when he writes music, the system designer must follow some set of principles when he designs the sequence of give and take between man and machine. Hansen’s (1972) principles — called user engineering principles — where employed while designing the Emily text editing system.

1. First principle: Know the user – The system designer should try to build a profile of the intended user: their education, experience, interests, how much time they have, their manual dexterity, the special requirements of their problem, their reaction to the behaviour of the system, their patience.
2. Minimise memorisation — Because a user forgets, the system must augment their memory.
   • Selection not entry
   • Names not numbers
   • Predictable behaviour
   • Access to system information
3. Optimise operations — This stresses the physical appearance of the system — the modes and speeds of interaction and the sequence of user actions needed to invoke specific facilities. The guiding principle is that the system should be as unobtrusive as possible, a tool that is wielded almost without conscious effort. The user should be encouraged to think not in terms of the fight pen and keyboard, but in terms of how he wants to change the displayed information.
   • Rapid execution of common operations
   • Display inertia
   • Muscle memory
   • Reorganise command parameters
4. Engineer for errors — Modern computers can perform billions of operations without errors. Knowing this, system designers tend to forget that neither users nor system implementers achieve perfection. The system design must protect the user from both the system and themselves.
   • Good error messages
   • Engineer out the common errors
   • Reversible actions
   • Redundancy
   • Data structure integrity

Further reading:

• Hansen, W. J. (1971). User Engineering Principles for Interactive Systems. Proceeding AFIPS ’71 (Fall). Proceedings of the November 16-18, 1971, Joint Computer Conference, 523-532. New York, NY, USA: ACM Press. doi: 10.1145/1479064.1479159.

1. Strive for consistency — Consistent sequences of actions should be required in similar situations; identical terminology should be used in prompts, menus, and help screens; and consistent commands should be employed throughout.
2. Enable frequent users to use shortcuts — As the frequency of use increases, so do the user’s desires to reduce the number of interactions and to increase the pace of interaction. Abbreviations, function keys, hidden commands, and macro facilities are very helpful to an expert user.
3. Offer informative feedback — For every operator action, there should be some system feedback. For frequent and minor actions, the response can be modest, while for infrequent and major actions, the response should be more substantial.
4. Design dialog to yield closure — Sequences of actions should be organized into groups with a beginning, middle, and end. The informative feedback at the completion of a group of actions gives the operators the satisfaction of accomplishment, a sense of relief, the signal to drop contingency plans and options from their minds, and an indication that the way is clear to prepare for the next group of actions.
5. Offer simple error handling — As much as possible, design the system so the user cannot make a serious error. If an error is made, the system should be able to detect the error and offer simple, comprehensible mechanisms for handling the error.
6. Permit easy reversal of actions — This feature relieves anxiety, since the user knows that errors can be undone; it thus encourages exploration of unfamiliar options. The units of reversibility may be a single action, a data entry, or a complete group of actions.
7. Support internal locus of control — Experienced operators strongly desire the sense that they are in charge of the system and that the system responds to their actions. Design the system to make users the initiators of actions rather than the responders.
8. Reduce short-term memory load — The limitation of human information processing in short-term memory requires that displays be kept simple, multiple page displays be consolidated, window-motion frequency be reduced, and sufficient training time be allotted for codes, mnemonics, and sequences of actions.

Further reading:

• Designing the User Interface: Strategies for Effective Human-Computer Interaction

Details of the current seminar series can be found on Stanford HCI website, whilst the 2009 seminar series can be found on iTunes U. The topics of which are listed below:

Winter 2009

1. Pario: The Next Step Beyond Audio and Video
2. Sculpting Behaviour: Developing a Tangible Lnguage for Hands-on Play and Learning
3. Tap is the New Click
4. Social Annotation, Contextual Collaboration and Online Transparency
5. Enlightened Trial and Error – Gaining design Insight Through Prototyping Tools
6. Computer Graphics as a Telecommunication Medium
7. Not Invented Here: Online Mapping Revealed

Spring 2009

1. Firefox, Mozilla & Open Source: Software Design at Scale
2. Social Enterprise Software Design
3. The Interaction Design of APIs
4. Far Away Up Close
5. What Still Matters About Distance?
6. How We Use Data to Win the Presidential Election
7. Social Immersive Media
8. Launching Creative Communities: Lessons From the Spore Community
9. Designing Online Communities from Theory

Autumn/Fall 2009

1. Crowdsourcing Work
2. Backtracking Events as Indicators of Software Usability Problems
3. Programming by Sketching
4. Aesthetic Science of Colour: WAVEs of Colour, Culture, Music and Emotion

Previous talks are also available on iTunes U — with the notable speakers Bill Moggridge, Bill Buxton and Donald Norman featuring — or on YouTube: 2006-07, 2007-08, 2008-09

The list is still as relevant today as it was back in 1997.

1. Know thy user, and YOU are not thy user.
2. Things that look the same should act the same.
3. Everyone makes mistakes, so every mistake should be fixable.
4. The information for the decision needs to be there when the decision is needed.
5. Error messages should actually mean something to the user, and tell the user how to fix the problem.
6. Every action should have a reaction.
7. Don’t overload the user’s buffers.
8. Consistency, consistency, consistency.
9. Minimize the need for a mighty memory.
10. Keep it simple.
11. The more you do something, the easier it should be to do.
12. The user should always know what is happening.
13. The user should control the system. The system shouldn’t control the user. The user is the boss, and the system should show it.
14. The idea is to empower the user, not speed up the system.
15. Eliminate unnecessary decisions, and illuminate the rest.
16. If I made an error, let me know about it before I get into REAL trouble.
17. The best journey is the one with the fewest steps. Shorten the distance between the user and their goal.
18. The user should be able to do what the user wants to do.
19. Things that look different should act different.
20. You should always know how to find out what to do next.
21. Don’t let people accidentally shoot themselves.
22. Even experts are novices at some point. Provide help.
23. Design for regular people and the real world.
24. Keep it neat. Keep it organized.
25. Provide a way to bail out and start over.
26. The fault is not in thyself, but in thy system.
27. If it is not needed, it’s not needed.
28. Color is information.
29. Everything in its place, and a place for everything.
30. The user should be in a good mood when done.
31. If I made an error, at least let me finish my thought before I have to fix it.
32. Cute is not a good adjective for systems.
33. Let people shape the system to themselves, and paint it with their own personality.
34. To know the system is to love it.

References

1. Lund, A. M. (1997). Expert ratings of usability maxims. Ergonomics in Design, 5(3), 15-20. A study of the heuristics design experts consider important for good design.

A user persona is a representation of the goals and behaviour of a real group of users. In most cases, personas are synthesised from data collected from interviews with users. They are captured in 1–2 page descriptions that include behaviour patterns, goals, skills, attitudes, and environment, with a few fictional personal details to make the persona a realistic character. For each product, more than one persona is usually created, but one persona should always be the primary focus for the design.

The use of personas as a technique was popularised by Alan Cooper in his 1999 book The Inmates are Running the Asylum. The book outlines the general characteristics, uses, and best practices for creating personas.

So, how do you actually go about creating a persona or a set of personas for your project? The following is based upon work carried out by Dr. Lene Nielsen in her 2004 thesis and published in HCI Vistas.

Finding the Users

The initial step is to get hold of as much knowledge of the users as possible.

Questions asked:

• Who are the users?
• How many are they?
• What do they do within the system?

Methods used:

• Contextual interviews
• Online surveys
• Observations
• Second-hand information
• Reports (e.g. from marketing)
• Cultural probes

Documents produced:

• Reports

Building an Hypothesis

Working with personas really means focusing on users in a certain context, which originates from the project that is being researched. Often companies have a certain way of talking about their users, or should we say customers, which does not take into account the different context in which the users use a website or a system.

Questions asked:

• What are the differences between the users?

Methods used:

• Looking at the material
• Labelling groups of people

Documents produced:

• A draft description of the target groups

Verifications

The focus here is on finding data that supports the initial patterns and at the same time supports the personas descriptions and the scenario writing.

Questions asked:

• Data for personas — What are the likes/dislikes, needs and values?
• Data for situations — What are the areas of work and work conditions?
• Data for scenarios — What are the work strategies and goals. What are the information strategies and goals?

Methods used:

• Quantitative data collection

Documents produced:

• Reports

Finding Patterns

Questions asked:

• Does the initial labelling hold true?
• Are there other groups to consider?
• Are all equally important?

Methods used:

• Categorisation
• Task analysis

Documents produced:

• Descriptions of categories

Constructing Personas

A crucial step is what to include in a persona’s description and how to avoid creating stereotypes if at all possible. The purpose of a persona is not to describe users as such, but to create solutions that use the needs of the persona as a starting point.

Questions asked:

• What are their basic attributes — name, age, gender?
• What is their psyche — introvert/extrovert?
• What is their background — occupation and interests?
• What are their emotions and attitude towards technology, the company or the information needed?
• What are their personal traits?

Methods used:

• Categorisation

Documents produced:

• Descriptions of categories

Defining Situations

The real purpose of the personas is to create scenarios from the descriptions. Each need or situation is the beginning for a scenario.

Questions asked:

• What is the need of this persona?
• What is the situation?

Methods used:

• Looking for situations and needs in the data

Documents produced:

• Catalogue of needs and situations

Validation and Buy-in

Personas are often viewed as a means for communicating users (read: customers) to developers and stakeholders, but it is as much about a process that ensures a user-centered development.

Questions asked:

• Do you know someone like this?

Methods used:

• People who know (of) the persona read and comment on the persona descriptions

Dissemination of Knowledge

Not only do personas need to be distributed to everybody on the project, but also the data behind the personas and how and for what you are to use the personas. Many projects forget to inform and teach developers and designers on how to use the personas, how to think in scenarios or how to use them in the use-cases.

Questions asked:

• How can we share the personas with the organisation?

Methods used:

• Posters
• Meetings
• Emails
• Events

Creating Scenarios

A scenario is like a story, it has a main character (the persona) a setting (somewhere the action takes place), it has a goal (what the persona wants to achieve), it has actions that lead to the goal (interactions with the system/website/device), and last but not least, it has obstacles that block the way to the goal. Scenarios should be both positive and negative.

Questions asked:

• In a given situation, with a given goal, what happens when the persona uses the technology?

Methods used:

• The narrative scenario, using personas, descriptions and situations to form scenarios

Documents produced:

• Sceanrios
• Use Cases
• Requirement Specifications

On-going Development

Finally, always update information on the personas, afterall you may find some interesting scenarios that weren’t originally considered, or new situations in which the system/website/device is used. Indeed you may discover new personas!

Questions asked:

• Does new information alter the personas?

Methods used:

• Usability tests
• Focus groups
• Surveys (online)