I’ve been thinking a lot about context recently. As designers, we know that context is that vital ingredient in the designer soup that helps us ensure our solution is spot on for our target users, that it’s working for them, supporting whichever direction they want to take in their tasks, speaking their language, and above all doesn’t require them to think.
But, how do we designers communicate why context of use is worth investing in? This blog post aims to help you communicate the need for context to non-designers, and to find a balance between the designer’s and the non-designers ideal level of context.
What do I mean by context?
Context can mean many things to different audiences, but here I mean the ‘context of use’ in which users perform the tasks we’re designing for. This can be at a general level where we’re seeking to understand common working patterns that are relevant to the design, or at a more detailed level where we’re learning how users respond to very specific situations.
Communicating this need for ‘context of use’ to non-designers – particularly project stakeholders – is essential to establishing a good design process. It’s also vital in ensuring the project plan includes adequate time and resources to really get to know what the users need. But it can be really difficult to articulate this need clearly and succinctly.
I’ve often struggled to communicate why context of use is worth investing in, so in true designer fashion I’ve created a diagram that has helped me and might be useful to you too.
Let’s start with the vertical axis…
On the y-axis you get the depth of context – that is the level of understanding about what users do, how they do it, and what their goals are. I’ve marked out 3 points on this continuum:-
- Research context – the crucial first level, when we’re familiar enough with the broad roles and responsibilities of our users (and any industry-specific terminology) to have useful conversations with them.
- Ideation context – the next level, where we know enough about the users goals and workflows to explore how we may improve things for them – our design activities at this stage are as much about validating our understanding as they are about finding solutions.
- Design context – at this level we’re ready to make design decisions that we believe will provide our users with a great experience, and be able to justify these decisions using our detailed knowledge of our users.
Beyond this, there’s the mythical “I know everything there is to know about the users” but I didn’t include it since it’s, well, mythical!
Now the other axis…
Here I’ve put the breadth of context. Every project has boundaries to the context of use, usually defined initially by scope documents that talk at a high level about business requirements, and (if we’re lucky) about user requirements too, so I’ve marked this on the diagram as the project scope.
Any context of use that falls within the project scope directly relates to what our solution delivers, such as the actions the user performs, and the stages within their workflows when they perform those actions. Anything outside of the project scope is the wider context, and is not directly related to your designs, such as actions users may need to perform before they start performing the tasks in the project scope, or afterwards.
A simple example is, if the project is for placing an online order then the user may have needed to create an account before they can order, and may want to track and amend their orders after they’ve placed them.
Here are some other examples:
- In healthcare, the project scope might be enabling hospital admissions staff to capture patient information, in the wider context of in-patient administration.
- In banking, the project scope might be enabling accounting clerks to make online payments, within the wider context of corporate banking services.
- In online travel, the project scope might be enabling business travellers manage their itineraries, within the wider context of self-service for business travellers.
What non-designers believe is enough context of use
Non-designers – particularly those who haven’t been involved in a design-led project before – are likely to think the only context of use that is required for their project is that specifically relating to the project’s requirements. This can be drawn as a pillar, where the only context of use gathered is within the boundaries of the project scope:
This point of view is perfectly understandable – for non-designers, anything outside of the project scope is likely considered superfluous and irrelevant. After all, why spend time and money finding out about user tasks and goals that aren’t going to feature in the delivered solution?
What designers believe is enough context of use
The ideal context of use for a designer looks something like this:
Every good designer that I’ve had the privilege to meet craves a comprehensive context of use – it’s in their DNA to want to understand everything they can about the users and the world they live in.
Designers always consider the project scope as the starting point for establishing context of use. We want to understand not only those tasks the project directly affects, but also the workflow these tasks are part of. We need to understand the wider aims and objectives, and the terminology the users use, so we can reflect this in our designs and ensure the users’ experiences are harmonious with everything else they do.
A balance of context and cost
In reality, project costs in terms of time and budget will almost always curb our designer ambitions for a comprehensive context of use.
Given this, a pragmatic balance looks something like this:
A well-planned design project allows for some investigation into the wider context of use around the project scope – this provides the best balance between the needs of the designer to understand the wider context, and the needs of the project to keep to deadlines and budget.
With this amount of context of use, designers can ensure their solutions make sense within the users’ wider workflows and work harmoniously with closely related tasks.
Overlapping context between projects
Lastly, when you’re talking with project sponsors about context of use, if there’s the possibility that you could be engaged in other closely related projects, you should show them this:
I’ve drawn a second project with a similar balance of context – you can see there’s an overlapping area that I’ve labelled shared context, which will have already been gathered during the first project.
Shared context provides many benefits:
- designers on the second project may have enough context of use to engage in meaningful questioning or even explore ideas from day one
- design elements from the first project may be directly reusable in the second one
- design consistency between the projects will be much easier to achieve
- new learnings on the second project may uncover further improvements for the original project
It really is a win-win scenario!
In contrast, if the context of use gathered for each of these projects were limited to the project scope, there would be no shared context, no knowledge or design reuse, and potentially less consistency between designs.
To summarise, I started by calling out the need to communicate why context is so central to good design, and proposed a diagram that illustrates both the depth and breadth of context. I then contrasted what non-designers usually consider adequate context for a given project with what designers might consider ideal, and talked about how a balance of context and cost can be achieved between these viewpoints.
Lastly I outlined the improved efficiency, consistency and design reuse that a balanced approach to context can provide in situations when we are engaged on multiple related projects.
To find out more about how RMA delivers the kind of digital solutions we do, visit Our Approach.
I’d love to hear your thoughts about this post, so please do get in touch at email@example.com.