Designing for the other side of the screen
Main illustration: Shawna X
Solve real problems. It’s become a universally agreed upon principle when designing products.
Less agreed upon is just how truly difficult this is to achieve. Good intentions don’t build great products, and wanting to solve a problem isn’t the same as actually solving it.
Even when you’ve done the hard work of understanding the problem, it is really, really hard to stay focused on it throughout the process. It becomes all too easy to focus on the details of what you’re building rather than the people you’re building it for.
What screens are good for
As designers, screens are at the heart of our work.
What you’re building is a change in what people do, and how they feel while doing it.
We sketch them on whiteboards. We iterate on them in wireframes. We share them, critique them, and work to improve them.
When designing digital products, screens are essential. Be it a wireframe, static mockup, or a prototype, they help us share ideas. They provide teams with a shared visual aid to talk through product decisions. As we create them in higher fidelity they become the symbol of what our team is building and show the progress we are making.
But when they become the symbol of how the team represent the product to themselves and the outside world it’s all too easy to start believing those screens are the goal itself.
A tradition of screens
Our traditional design processes aren’t much help. The design tools we use just help us produce screens. Design collaboration software is built entirely around the sharing and critiquing of screens.
These traditional processes and tools lead us inevitably to a mountain of screens. Screens with multiple different versions, multiple different tweaks, multiple talking points. While we all know screens aren’t an end in themselves, when you’re up at midnight working on v123_final_really.sketch, it’s hard not to feel that way.
In our endless echo-chamber of screens, remaining focused on the underlying problems becomes really hard.
The more screens are involved, the less we focus on the problem.
How we keep focused on the problem
I’ve been part of many teams that became blinded by screens. In the stacks of screens we built and debated we ended up with solutions that never really solved a problem.
But I’ve seen those very same teams transformed by watching people use the screens and software they’ve designed.
We all know that observing people use our products gives us actionable insights. But it is also the best way to focus on what is important.
Showing what you’ve been working on to someone who has the problem you’re trying to solve is when you see the real thing your team is building. It isn’t the screen, or even software. What you’re building is a change in what people do, and how they feel while doing it.
For the first time the whole team can see that the thing they are making isn’t pixels or code. It’s a change in how people live their day-to-day lives.
Having good intentions at the beginning isn’t enough to help get you over the finishing line. Throughout the whole process you need to keep forcing yourself to always look beyond the screen you are producing to the behaviour you’re hoping to change.
Next time you’re in a meeting debating the merits of a screen, don’t forget that it is just an artifact of the process, a task along the way.
All the really interesting stuff is going to be happening on the other side of the screen.
