Design for Real Life

Design for Real Life argues that we need to take accessibility more seriously. This goes beyond just conforming to a set of content presentation guidelines (e.g. the W3C standards), and goes to your overall design process. You can buy the book from A Book Apart

  1. Identify and challenge assumptions

    Think about what assumptions you’ve built into what you’re designing. What will happen if someone falls outside these?

    Facebook’s Year In Review – a feature designed to help people celebrate and share their great year – wasn’t designed with the experiences of people who’d not had a great year in mind.

    Inappropriate Year In Review images included:

    • a photo of the user’s apartment on fire
    • a photo of an urn containing the user’s father’s ashes
    • a sonogram of a pregnancy that later ended in miscarriage
    • a photo of a friend’s gravestone

    Facebook’s design team had a narrow vision, and so excluded all of these users. Meyer and Wachter-Boettcher challenge us to bring “edge cases” to the centre. “Instead of treating stress situations as fringe concerns, it’s time we move them to the center of our conversations – to start with our most vulnerable, distracted, and stressed-out users, and then work our way outward.” All users will benefit from this more focused, understandable and empathetic approach.

  2. Make space for real people

    Give people “enough room within our interfaces to be themselves.” For example, gender is often presented as a binary choice between male and female, which doesn’t fit with our current understanding of gender. Facebook is an example of best practice here, allowing people to choose male, female or custom – which is a free text field with a list of common choices as prompts.

    Other examples of systems not giving people space to be themselves include systems that can’t handle names longer than a certain length (e.g. 15 characters), systems that don’t accept hyphens in names, or ones that don’t accept names that don’t pass culturally-specific test of validity. (e.g. Facebook rejecting Shane Creepingbear’s name as not real.)

    Organisations often make assumptions about what matters to users, or about who they are. The ‘Apple Health’ app didn’t include period tracking on launch, even though it boasted that it tracked ‘all of your metrics that you’re most interested in’. Its implicit focus was on men. And period tracking apps themselves often have a bias towards straight, sexually active, partnered people.

  3. Incorporate stress cases

    A DIY and home appliance retailer was looking to improve its product guides. Originally these were written in a chirpy, positive tone, for happy, confident home-improvers. But sometimes users are more stressed when carrying out these tasks. The team found that there were two general categories of use: “urgent” and “upgrade”. They updated their style guide to write for the urgent case. This improved the guides for all users, as the clarity of information increased. Guides now feature installation availability and time-frames, estimated cost ranges, greater user of subheadings to allow for easy skimming, one-sentence summaries, reassuring tone.

    You can incorporate stress or crisis cases in usability testing. And you can test how a product performs in a cognitively-demanding environment by either testing in that environment, or by tiring people out mentally before the testing – e.g. by giving them some maths tasks to carry out.

  4. Only ask necessary questions in forms

    Organisations are often pushy to obtain as much information as they can from every web form. Often this is done with a total disregard for the user’s experience. Caroline Jarrett has a protocol for evaluating each question you want to include:

    1. Who in the organisation will use the answer?
    2. What will the answer be used for?
    3. Is the answer required or optional?
    4. If the question is required, what happens if the user enters rubbish data just to get through the form

    This question protocol can help open up a discussion about the true business value of each question.

  5. Learn from users

    Work to understand how your users see the world. This goes deeper than just testing top tasks on your website, or discussing product features.

    Steve Portigal recommends three types of question:

    1. Gather context and collect detail. e.g. asking about a sequence (Describe a typical workday) or specific examples (What was the last app you used?)
    2. Probe. e.g. ask for clarification of how a system works.
    3. Draw out contrasts. Useful for uncovering frameworks and mental models. e.g comparing processes or approaches.

    Open-ended research is about opening up questions and ideas, expanding your vision and the types of question you ask. This helps you move towards a design process centred aroudn real people and their needs.

    Customer mapping can help you identify pain points, broken flows, and content gaps, through analysis of lenses, touchpoints, channels, actions, thoughts and feelings. Adaptive Path have produced a guide to customer experience/journey mapping.

  6. Making the business case for accessibility

    Karl Groves, an accessibility consultant, argues that there are only three business cases for anything. Here’s how to argue for accessibility for each of these:

    1. It will make money. You can use accessibility to stand our from your competitors. e.g. Slack gaining users through ease-of-use. You can reach new audiences if more people are able to use your product.
    2. It will save money. You can cut customer service costs. The UK government found that as of 2011 it was receiving 150 million avoidable calls a year – calls for which an online service existed. This represented a possible annual saving of around £4 billion a year. Improving accessibility saves you money by increasing user retention – which is between 5 and 25 times more cheaper than acquiring new customers.
    3. It will decrease risk. Accessibility helps you avoid negative experiences and associated backlash – e.g. Facebook’s year in review generated a lot of negative press.

One reply on “Design for Real Life”