Week 87: How the sausage is made
Over the past week I’ve been involved in a workshop and some conversations about the design process.
Whilst most of our teams within NHS England are now using the NHS prototype kit, some teams are also using Figma to document every variant of every screen. I can see how it can be useful to be able to visualise the flow of a service, but I fear that expecting designers to maintain both a coded prototype and a Figma version could slow things down and be unnecessary duplication.
Teams also vary in how much detail about designs they add to Jira cards, and whether they use Confluence or Mural or Word or other platforms to document stuff.
I don’t think we need this to be consistent across teams. The design process can and should vary according to the context, dynamics and preferences of each team.
Design artefacts are just that: artefacts. The only thing that really counts is the actual thing that gets built and used by real people.
I try to avoid thinking of any designs or prototypes as being the ‘single source of truth’. It’s all too easy to end up with designs that are months and months ahead of a live service, and even if all the build work is on your roadmap, plans can change.
The relationship between design and development is something that needs constant work to develop and improve, especially as people come and go in a team. In my experience, the closer the 2 disciplines are to each other, the less you have to formally document. Regular conversations and demos beat reams of written acceptance criteria.
We’ve also had discussions about whether and how to version designs. I don’t think there’s a single answer here either. Some teams in an early stage might have distinct iterations of a design, whereas other teams with a live service may be continually tweaking and updating, or be working on several things concurrently.
For coded prototypes, I tend to recommend that designers avoid maintaining several versions within a single prototype unless there are good reasons to, as it can soon get unwieldy and hard to keep all the versions working independently. An alternative strategy is to make use of some of the Git features that developers use. You can use branches to try out different ideas in parallel. Or make use of the commit history to view a design as it was several months ago, if needed. It’s incredibly powerful but there is a learning curve - so this is something we could offer more support and guidance on.
I also advocated again for writing design histories. These can go beyond documenting just what the designs are, but instead describe the intent. The why to go with the what. They’re also a place where you can describe any discarded ideas that didn’t work, or things you’d like to have done but couldn’t yet for pragmatic or technical reasons.
I’d love to hear from other teams about how they document their designs. Other disciplines too - I’m sure there are some interesting debates within the user research community on how best to write up their research and in what level of detail.
Ultimately there are many ways to make the sausage.
A short week for me this week and next week, as I’m currently on a TGV en route to thr Alps for a ski weekend!