Building blocks
A simple framework for reviewing work on a service
Kirsty recently referenced my ‘building blocks’ in a blog post about how to use walls to share your work inside your organisation and to the wider world.
This is an approach that I’ve shared with the design team at FutureGov and that I’ve also used elsewhere.
In design leadership roles I’ve found myself increasingly looking at the work of other teams as well as having to help organise the work of teams I’m working with directly. In both scenarios this often means talking through a wall space and key project artefacts with a team as part of a design review (both formally, and sometimes more informally).
I’ve always believed in the importance of making work on services as visible and as open as possible. This will often be focussed on outputs and activities centred around user research and design — I particularly like Kate Towsey’s GDS post about wall spaces as vertical campfires (published in 2014). Maintained and developed effectively, these spaces can also make development backlogs, roadmaps and business priorities visible as well.
When working with teams I’m always looking for evidence of a number of things. This is about getting a sense of how aligned the work (focus), ways of working (approach), and outputs (quality) are to delivering value within the constraints the team are working with (e.g. scope, remit, time and money).
When looking at any space, and as someone being asked to give feedback, I’m immediately thinking about whether I can see a problem statement or a useful or usable vision (goal) for the work. There should be user needs, research insights, some variations of maps showing user journeys as well as internal processes and roles. There should also be evidence that the team has captured and understood assumptions and key hypotheses that are being used to frame the work they’re doing.
Visually representing work for an end to end service
This is an illustration of a set of ‘building blocks’ for an end to end service.
This is a mental model. All of these ‘blocks’ are part of what I think about as a good foundation for the work that’s being done. I’m mostly looking out for what’s missing or anything that might be misaligned. I treat all these things as key components of keeping work focussed in order that we can deliver the best possible solution, product or service.
When something is missing or unclear it effects the foundation of the work.
You should be able to feel when what’s in front of you is not solid as it needs to be. When I say solid, again I mean the foundation of the work. Are we building or developing solutions based on solid research, insights and the right framing of the brief? i.e. the most important challenge is understanding the right set of problems, and then building the right things for the right people in the right places.
In the illustration, I’ve broken down sets of artefacts and outputs into different categories:
- Entry point.
- Framing/detail.
- Shape/direction.
- Active/doing.
You could organise this in different ways. These types of artefacts and outputs will map to other frameworks like a double diamond just as easily.
I like these labels as they give me a sense of the overall narrative for the work. From an entry point or where we’re starting, to how we’ve framed and then shaped the work, until finally, to what we’re actually doing right now. If you use this format to present your work it will make you focus the conversation towards what you’re working on and doing right now (which should be where you need the most feedback with everything else provided as context).
Remember that when something isn’t quite right in how a team is focussed or working it’s often because one of these building blocks or a number of things might be missing, neglected or has got lost in the design process. Talking and working through the outputs set out in a space will start to show you how everything holds together.
Artefacts and naming conventions might change from project to project, but good foundations and visibility of the assumptions, conversations and thinking behind work on a service is a vital check point for reviewing progress. Similarly, I’ve used this as an approach to organise project spaces with teams I’ve been part of. It can act a planning tool for how to set out artefacts and project outputs in order to create a coherent narrative–helping you to talk through your work with others.
