Context is king (and queen)
6 minute read
"Always design a thing by considering it in its next larger context – a chair in a room, a room in a house, a house in an environment, an environment in a city plan."
Eliel Saarinen
Context: easy to understand, easy to forget about
I design software for small business owners. I am not a small business owner.
I sit in a nice modern office with my nice 15” MacBook Pro, working flexible hours and doing the things people do in tech companies. Most of the people I am designing software for are not even remotely like me. Sure, some of them work in nice offices and have MacBook Pros. Some even dress like me. But our jobs are different.
It’s dangerous because it's easy to relate to some of the tasks that these businesses carry out. I send some invoices, therefore I should understand how someone sends an invoice, right?
The thing is, when I send an invoice, it’s usually for a side project I'm working on. It probably doesn’t matter when I get paid, as long as I do. It certainly won't impact my life heavily.
For our clients, it’s their livelihood. It’s the difference between being bankrupt or not being able to pay their staff. In Australia, invoices are paid an average of over 10 days late - imagine the impact that has on an economy with over 2 million small businesses (the population is only 25 million!).
If I get made redundant tomorrow, I’ll go out and find another job in the industry. If someone’s small business goes bankrupt, it’s a life-changing event.
So the same action - sending an invoice - can exist in extremely different contexts. By considering the next level of context - and sometimes the one beyond that as well - we can go a long way into better understanding our customers and making sure our solutions are solving real problems.
Mistakes of context
Derren Brown illustrates a great example of the difference context can make in his book ‘Happy’. He created an experiment where he showed people three anagrams and asked them to work out which words they were.
Initially he showed them the following words:
WHIRL
SLAPSTICK
CINERAMA
Well done if you got any - in actual fact the last one was the only ‘real’ anagram (for ‘American’). The first two were just there to make the third one harder. And it worked! Derren found that when the first two words were replaced with much easier anagrams, a much higher percentage of people were able to solve the third one.
TAB
LEMON
CINERAMA
Bat, melon and American if you’re still playing along.
The lesson? The context it's in can make a task easier or harder. We should be directing attention to where the task sits as opposed to directly on the task itself - as Eleil's quote at the start of this article suggests, 'consider it in its next largest context'.
Question the context you've been given
Knowing what level to solve a problem at is one of the biggest differentiators between junior and experienced designers. Considering the wider context in which a problem exists and correctly framing it takes a lot of work. And usually some challenging conversations.
It can be easy to go ahead and solve a problem using the frame that’s given to you.
“This page has 40% conversion, let’s get it to 50%”.
On the face of it this is an easy problem to solve. You can go off, do some usability testing, iterate on your design and make the page convert better. You might get it to 50%.
But what if rather than convert better, there’s a previous step where you’re losing customers from even getting to this screen? The higher up the funnel, the more potential customers you’re losing. The challenge here is that often this isn't the thing you've been asked to fix. If you work at a larger company there could be politics at play. Maybe your team's goals are connected specifically to the '40% page'.
It's worth noting the role experience plays. If you're in your first design role I wouldn't be expecting you to have these conversations in the same manner I would a senior designer with ten years experience.
Mental models for context
There are some useful models for framing context when designing. Steward Brand wrote about 'how buildings learn' in the early 90's and the following diagram illustrates his concept:
Brand suggests that some layers of buildings, primarily the outside layers, exist for a much longer time than the internal layers. For example, it's easy to move 'stuff' in and out of a house, this happens all the time. The 'skin' however might be a bit harder - it still changes, but less often. The site itself is the slowest changing of all.
Stewart evolved this thought into the concept of 'PACE' layering, which describes how complex systems learn. There's also an article on the Abstract blog relating this to design.
I don’t agree 100% with the levels that Abstract have proposed, but the concept is useful.
For the purposes of this conversation, the model can help you think about what level your work is at. Maybe you're thinking in interactions when you should be thinking about the flow. Maybe you're thinking about the flow without considering the larger app that it's a part of. Maybe you're working at the wrong pace - maybe you’re moving too slowly when the level you're working at needs a faster pace, this is possible too.
You’d be surprised how often no-one is considering the next level. Maybe there’s a drive for a particular metric causing blindness. It’s funny the things we miss when we’re focussed on a goal.
In the end: research, research, research
It's easy to assume we are just like our customers. We are guilty of making many assumptions when it comes to context. There's a whole group of cognitive biases centered on the idea that we think we know what other people are thinking. We don't.
I'll go back to my example - I've spent three years working on small business software so it's easy to 'think' I know what it's like to be a small business owner. I really don't - I get plenty of glimpses inside but I have to keep my biases in check. For me, that means making sure I've done the research - and that's primary research, not desk research, not secondary research - and considering the next larger context (and sometimes the one beyond that!) of whatever it is I'm designing.