Inclusive design is where innovation and imagination flourish. Meeting the needs of the widest variety of people does not inhibit creativity. It opens our minds and inspires excellence.

In her article in .net magazine, Sandi Wassmer of Copious explains the ten principles for inclusive web design an overview of which is listed below:

1. Equitable – Be welcoming, don’t discriminate and engage with people. Create different user experiences and make certain they have equally valuable outcomes. Aesthetics matter.
2. Flexible – Provide options. Think who, how, why, what, where and when people will be using your website. Make sure there is choice for diverse users and maintain device independence.
3. Straightforward – Be obvious and not ambiguous. Make sure your website’s features add value, not complexity. Remember, good design is as little design as possible.
4. Perceptible – Don’t assume anything. Make sure your website’s purpose is clear, its content, structure and sequence are meaningful and convey information to all of the senses.
5. Informative – Make sure people know where they are on your website and provide ways for them to find what they’re looking for. Be timely, predictable, uncomplicated and precise.
6. Preventative – Provide easy to follow instructions and gently guide users in interacting with your website. Help them to minimise errors when submitting data, through well considered form design.
7. Tolerant – Handle errors respectfully and indicate precisely what the error is, where it is and how to fix it. Remember to let people know the outcome.
8. Effortless – Don’t make demands or place restrictions on your users. People should not have to work or think hard to find what they want on your website. Ensure it can be used efficiently and effectively.
9. Accommodating – Be approachable, uncluttered and give people room to manoeuvre. Make sure that your website is unobtrusive and can be accessed by different devices of all shapes and sizes.
10. Consistent – Follow standards, guidelines, conventions and best practices. Provide a familiar environment with memorable functionality.

With different devices, configurations, browsers, personal settings and assistive technologies, and no agreement on how to achieve interoperability, web builders must do their best to accommodate the diverse ways people access the internet. Building with this in mind will ensure your visitors have a quality experience.

Inclusive design enables us to create great, meaningful, on-brand internet experiences for the widest audience possible. However, inclusive design is also a new way of thinking, and its overarching aims may not mirror those of your organisation or clients. Change takes time, so you may not be able to do everything at once. If you just start thinking about accessibility and plan your projects with users in mind, you’ll be on the right path. There will be trade-offs and tough decisions, but this is where inclusive design really comes to the fore. It challenges us to hone our craft and fosters real creativity and innovation.

The following are free-to-read books on user experience, available online:

Human Computer Interaction

• Mental Models in Human-Computer Interaction: Research Issues About What the User of Software Knows by John M. Carroll and Judith Reitman Olson
• HCI Models, Theories and Frameworks: Toward a Multi-disciplinary Science by John M. Carroll

User Experience / Interaction Design

• Search User Interfaces by Marti A. Hearst
• Designing Interfaces – Patterns for Effective Interaction Design by Jenifer Tidwell
• Thoughts on Interaction Design by Jon Kolko. with contributions from Ellen Beldner, Uday Gajendar, Chris Connors and Justin Petro
• The Fable of the User-Centered Designer by David Travis

Web Accessibility

• Just Ask: Integrating Accessibility Throughout Design by Shawn Henry
• Building Accessible Websites by Joe Clarke
• Dive Into Accessibility: 30 Days to a More Accessible Website by Mark Pilgrim

If there are any more you think need or can be added to the list, please leave a comment.

1. Visibility of system status — The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
2. Match between system and the real world — The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
3. User control and freedom — Users often choose system functions by mistake and will need a clearly marked emergency exit to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
4. Consistency and standards — Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
5. Error prevention — Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
6. Recognition rather than recall — Minimise the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
7. Flexibility and efficiency of use — Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
8. Aesthetic and minimalist design — Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
9. Help users recognise, diagnose, and recover from errors — Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
10. Help and documentation — Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.

References

• http://www.useit.com/papers/heuristic/heuristic_list.html
• Nielsen, J. (1994b). Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.), Usability Inspection Methods, John Wiley & Sons, New York, NY.

Human-Centered Design (HCD) is a process used for decades to create new solutions for companies and organisations. HCD can help you enhance the lives of people. This process has been specially-adapted for organisations like that work with people in Africa, Asia, and Latin America. HCD will help you hear people’s needs in new ways, create innovative solutions to meet these needs, and deliver solutions with financial sustainability in mind.

The Toolkit is divided into four sections that can be downloaded individually or together:

1. The Introduction will give an overview of HCD and help you understand how it might be used alongside other methods.
2. The Hear guide will help your design team prepare for fieldwork and understand how to collect stories that will serve as insight and inspiration. Designing meaningful and innovative solutions that serve your customers begins with gaining deep empathy for their needs, hopes and aspirations for the future. The Hear booklet will equip the team with methodologies and tips for engaging people in their own contexts to delve beneath the surface.
3. The Field Guide and Aspirations Cards are a complement to the Hear guide; these are the tools your team will take with them in order to conduct research.
4. The Create guide will help your team work together in a workshop format to translate what you heard from people into frameworks, opportunities, solutions, and prototypes. During this phase, you will move from concrete to more abstract thinking in identifying themes and opportunities and back to the concrete with solutions and prototypes.
5. The Deliver guide will help catapult the top ideas you have created toward implementation. The realisation of solution includes rapid revenue and cost modeling, capability assessment, and implementation panning. The activities offered in this phase are meant to complement your organisation’s existing implementation processes and may prompt adaptations to the way solutions are typically rolled out.

Download the complete toolkit (PDF, 30.5MB)

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.

Norman’s approach is based on classical ABC model of attitudes. However, Norman changed the concept to be suitable for application in design. The three dimensions have new names (visceral, behavioural and reflective level) and partially new content. In the book, Norman shows that design of most objects are perceived on all three levels (dimensions). Therefore a good design should address all three levels.

• The Visceral level is obtained through intuition rather than from reasoning or observation. This level is influenced significantly by appearance, texture and sound of objects.
• The Behavioural level refers to the actions or reactions of a person, usually in relation to the environment, to an object or person. Behaviour can be conscious or unconscious, overt or covert and voluntary or involuntary. This level is about functionality and is influenced by pleasure and effectiveness of use (accessibility and usability).
• The Reflective level refers to the capability of quiet thought or contemplation. This level is influenced strongly by self-image, satisfaction, memory and the meaning of things. This level becomes more important as products mature.

Norman postulates that these three dimensions are interwoven through any successful design and that it is not possible to have design without all three.

The three dimensions interweave both emotions and cognition. Emotion is a necessary part of life, affecting how you feel, how you behave and you think. Without emotions, Norman suggests any decision making would be impaired. Emotion passes judgement and gives continual feedback allowing you to make valuable decisions and is therefore key in any approach to successful 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)