Why Your Products Aren’t Working: The Lost Art of Contextual Design
Recently, I learned that my nine-year-old daughter needed glasses for the first time. She was ecstatic, while I felt the familiar parental dread of spending more money on items that might get lost in a week.
We went to the eye doctor’s shop just outside the exam rooms. As my daughter excitedly tried on various frames, I glanced at the prices and felt shocked — none were under $400, not including lenses. The salesperson reassured me that our insurance would cover some of the cost, but after navigating his complex pricing formula, we’d still be out at least $400 for a child’s pair of glasses. I decided to look for alternatives.
A few friends suggested an online retailer with reasonable prices and fun designs. You might recognize the name, which rhymes with Schmarby Barker. I installed their app and browsed their catalog, but we decided it would be easier to visit a nearby store.
The store was sparsely decorated with beautiful displays and a few tables scattered about. I wasn’t sure where to begin, but my kids quickly gravitated toward the displays and tried on glasses with the carefree enthusiasm of children. Eventually, a staff member approached and asked if we needed help. I mentioned that I wanted to buy glasses for my daughter and me.
She pulled out an iPad and asked for my name and email. I immediately empathized with her.
Digital Products Fall Flat When They Don’t Fit the User’s Context
There’s a reason Instagram accounts like Misspelled Starbucks Names exist. Spelling and typing someone’s name and email can be incredibly challenging, especially in a loud, hectic environment where the customer wants to finish their task and leave.
Watching her struggle to enter our information from the printed prescriptions, I couldn’t help but wonder if anyone who designed this app ever actually used it in an actual store setting. The iPad’s tiny screen, small font, and poorly sized tap targets made it difficult for anyone to read, let alone the employee struggling with it. This was a store where people came to correct their poor vision!
I imagined that the design and development teams had worked with high-resolution screens, assuming their product would be “responsive” enough. Yet, the result was an app frustratingly inadequate for its intended context.
Eventually, she had to call for help from another employee because the app had been updated overnight, and the new layout was unfamiliar. They were embarrassed and apologized, which is a pet peeve of mine. Employees should not be left to troubleshoot a malfunctioning app on the fly.
The Solution: Reviving the Lost Art of Contextual Task Analysis (CTA) and Mapping
It doesn’t have to be this way! Organizations can create intuitive, easy-to-use solutions by designing products with the user’s actual context in mind. To do so requires understanding the context in which users interact with a product, which leads to a more relevant and engaging experience.
By understanding the context in which users will interact with a product or service, designers can tailor the experience to align with their expectations, goals, and limitations. This personalization leads to a more relevant and engaging user experience, as users feel that the product understands and caters to their specific requirements.
To achieve this, teams should conduct a thorough contextual task analysis (CTA) before designing anything. CTA involves studying the environment, tools, technology, and user’s skills, knowledge, and motivation. This approach helps identify areas for improvement and design more effective solutions.
Unfortunately, many teams skip task analysis, going straight from high-level journey maps to prototyping without sufficiently in-depth understanding and context to guide their day-to-day decisions. This results in mediocre or mismatched user experiences that ultimately leave customers dissatisfied.
Start by Understanding What Users Are Trying to Achieve
Before designing a single screen, research what your target customers are trying to accomplish. This research typically includes reviewing existing studies, conducting contextual inquiries, interviews, and diary studies.
Focus on:
- Situation/Trigger: What prompts users to start the task?
- Desired Outcome(s): How will they know the task is complete and satisfactory?
- Knowledge: What information do users need to start and complete the task? How accessible is this information?
- Decision Points: What decisions do users make that impact the task?
- Inputs/Outputs: What tools or information are used? What data needs to be considered?
- Environment: How does the environment influence task performance? The impact of their environment is often underestimated and can lead to frustration with otherwise straightforward products.
Document how tasks are completed without technology first. Seek out people doing the activity (or similar, representative activities) using only pen and paper or interacting with people. This fresh perspective will help you see new angles and avoid being anchored to existing solutions.
Once you’ve gathered and analyzed the data, determine the model you should build.
Choosing the Right Model for the Context
When selecting a model, consider:
- Audience: Who will use this information? Executives? Cross-functional teams? Just you? How polished does it need to be?
- Activity Timeframe: Is the task completed in a single session, a week, several months, or years?
- Key Takeaways: What are the essential insights from the research?
- Company Norms: What formats do they prefer? PowerPoint, written documents, or charts?
- Design and Product Maturity: How often are they currently making strategic decisions based on user-centric insights?
I still go to James Kalbach’s Mapping Experiences before and after the research to get ideas and guidance on what I need to make sure to collect and how I might structure my analysis to get to the final product. I have my go-to’s, and generally mix and match the following:
Business Process Modeling: I was trained in business model and notation BPMN 2.0 many years ago and still use it with my teams. It leverages standardized elements to represent workflows to capture users’ activities, scopes of responsibility, decision points, and information flows. It’s extra handy for capturing different levels of detail, allowing for drill-downs into processes and activities. It’s best to start from the highest level process and then break each high-level activity into more detailed processes/tasks.
- Best for complex processes with multiple actors. I especially like it for capturing B2B and federal government processes.
- Holes and inefficiencies in processes jump out very quickly, as well as gaps in my understanding of what people are doing. The standardized notation makes producing and reading new processes easier without reorienting.
- Considerations: Learning to do it well takes time, and a weak process model can be misleading. There’s also a steep learning curve for stakeholders to take in what’s captured and feel comfortable reading the models.
Task Flows: Larry Marine and Debbie Levitt’s Disruptive Research describes this relatively lightweight method of capturing tasks. Like BPMN, this approach starts with a high-level overall task flow and then creates more detailed task flows for each separate task. Larry uses different colored sticky notes to represent different aspects of the user’s task:
- Green represents the actions that users need to do.
- Yellow represents a step the system can do.
- Purple represents objects, tools, or information that the users need.
- Orange represents questions or issues about the task.
Here’s a handy overview:
- Best for rapidly capturing tasks and helping required knowledge pop (and present opportunities for improvement). I’ve found it helpful for B2C tasks with fewer actors/humans involved, but I think it can be used for anything.
- Opportunities to optimize the tasks jump out very quickly, as well as areas where the need for user knowledge can be addressed or eliminated through the solution.
- Considerations: Unless it’s for something I’m working on alone, I usually massage the post-it view into something more “consumable” or polished before sharing.
Job Maps: Developed by Tony Ulwick and Lance Bettencourt, Job Maps are a model for defining and understanding people’s jobs to be done (JTBD). It defines jobs as a universal sequence of steps that comprise the complete process. People “hire” products to help them get the job done through these steps, which aren’t intended to be captured verbatim but to ensure the entire process is covered in the map you create.
- It can help companies identify new opportunities to create customer value if done well because it looks past current solutions.
- These are easiest to create if you’ve structured your interviews to align with the method described in the book Jobs To Be Done: Theory to Practice.
My caveat: while JTBD is powerful, many people misinterpret the concept and, therefore, miss out on the benefits. For example, they believe a button or a page has a job to be done vs. understanding the person has the job, and the product is hired to help them do it. Why does this matter? It quickly closes teams’ minds to other solutions that could be developed to help that human get the actual job done better/faster/cheaper.
I recommend assessing whether you and your team will invest the time and energy to understand the JTBD theory before applying it to ensure you avoid falling into this trap.
Now, Develop Solutions That Fit Users’ Contexts
Investing in this up-front work makes solution development more efficient and focuses on real problems. Each design decision becomes more evident, and solutions better align with users’ needs.
And, of course, as solutions are developed, regularly assess their performance in realistic conditions through in-context usability testing to ensure you haven’t missed something that renders your solution difficult or impossible to use.
Before you leave
Like what you’ve learned? Show your support by hitting the clap button! You can clap up to 50 times 👏 👏 👏
Want more Bland in your life? Follow me!