I reckon product teams need 3 things from designers. And, as a designer, your life will be easier if you can spot which of the 3 things a team needs at any point in time.
The 3 things are:
- making things visible
- making real things
- making things make sense
When I talk about ‘teams’ I mean multidisciplinary product teams who are building, operating, and iterating their services. I’ve worked on a few of these teams while at the Government Digital Service (GDS), and I have insight into lots more from being a service assessor (you should become a service assessor too).
When I say ‘designers’, I mean content, graphic, interaction, and service designers. But hopefully, this advice is useful to anyone involved in making things as part of a team.
Making things visible
This is when someone, maybe you, has an idea for how the future should be different. You make that idea visible and understandable so the team can decide whether to build it for real.
You could make sketches, prototypes, mock-ups, diagrams, maps or presentations – whatever helps the team understand what the concept or idea will be like for the person who has to use it. You might test what you’ve made with users to see if your assumptions are correct.
This work can also be about making the present visible. You could analyse some data or help communicate research findings so the team has a better understanding of the context in which they’re working.
This work is valuable on 2 levels:
- Making sure everyone on the team has a shared understanding of the idea
- Developing the team’s understanding of the problem: if your idea doesn’t solve the problem then it says something about how well you understand the problem
But this work is also risky. It can bring up more questions than it answers. For teams who operate a service, it can be frustrating to have someone telling them to step back and ask what problem they are ‘actually’ trying to solve when they feel like they have plenty of problems already.
You should be careful not to spend too long working this way. The more detail you add at this stage, the more design can diverge from delivery.
I try to add just enough detail to realise the way in which I’m wrong, then I start again. If I repeat this process enough times I find myself getting attached to an idea. That’s when I know it’s time to stop working on it and share it with others.
It can take a few minutes to do a good sketch, but it takes months of team effort to develop a real product. Making things visible is part of that process, not a deliverable in itself.
Making real things
Design should be engaged in production because a high quality product comes from obsessing over hundreds of small details.
This is why it’s useful to learn some coding, and how to raise a pull request.
It’s hard to justify prioritising a story on some backlog to make the apostrophes curly, not straight, or make elements of the interface line up. But if you go and fix these things yourself, it signals that you care about the quality of the product. Teams pick up on that, so eventually caring about details becomes part of the team’s values.
If you have a team that cares about the quality of the product then they’re likely to come and ask you when they don’t know something. They’ll start to use their expertise to ask thoughtful questions about your work that will improve its quality, and your practice.
This only happens if you make time for it and if you’re available to answer questions that come up as developers are building things. There will always be design decisions that you can’t anticipate. You don’t want those decisions made only on the basis of what’s technologically straightforward.
When you get good at this you can make small improvements which are shipped to production the same day. It’s hard to overstate the value of small, frequent, real improvements. With time it leads to a radically better product.
Crucially, making small, frequent improvements gains the trust of the team. You have to have the team’s trust before you can do the other kinds of design work the product needs.
The risk with obsessing about details is that design becomes a blocker. That’s when the only way you have to make good design happen is by stopping bad design from shipping. This sounds great – you have control – but it will make people do the least to get past you, rather than the best they can for the product and the user.
Making things make sense
Something you’re taught when studying design is how your thinking is shaped by your choice of tool. In art this is direct: a pencil sketch expresses a different quality to a sculpture. At work there’s a difference between thinking in paragraphs, to thinking in Powerpoint, to thinking in Post-it notes. They are tools, and choosing the right one is important.
The process you use shapes your thinking too: a meeting has a different outcome to a workshop, which has a different outcome to a one-to-one conversation.
When it comes to making software we don’t – at a fundamental level – have a choice of the tools or process. We have code, and we have some form of agile.
Agile is a good thing. But it’s important to be conscious of the kind of product you get from an iterative, incremental way of working.
If all you do is add features then the product will, eventually, no longer make sense as a whole. Even if the features are useful and sensible, the product will be confusing to use.
So the hardest, but most important contribution that a designer can make is to keep the product coherent. Ian Bogost talks about the designer’s role being to “make things even more what they already are”.
This work could be ensuring an element appears in the same place from page to page. It could be checking things are named consistently from place to place. It could be removing a checkbox once the reason for it existing has changed.
It’s especially hard to maintain coherence when a new feature comes along, but that’s also when coherence can suffer the most. To avoid such pinch points the team needs to feel empowered to do this work continuously, in anticipation of new features and in response to them.
You can’t do all the things all at once
There’s a lot of stuff in the post above. It would be overwhelming to do all of it all at once. The only way to do any of it is to work out which work to do when.
It can feel endless too, as well as overwhelming. I trained as a graphic designer. At university there was always a deadline for handing the work in. Later, working for agencies, the work would be handed over or delivered to the client at the end of a project. Working in product teams and working in government is a bit different. Developing different approaches takes time.
But hopefully things become more straightforward once you can tell which approach is right for a situation.
The 3 approaches we’ve talked about all involve making something. Where in your team’s work could the practice of making be helpful? Are there ways of framing your work you’ve found useful? What’s been your experience of joining or working on a long-running product team?
