Some more hastily tapped out weeknotes, though from the comfort of my home office, this time, rather than a train platform.

A 3-day week this week, all of it spent doing strategic work with colleagues in the Manchester office. Today I’ve got the day off to nerd out at ffconf1.

The three main tasks I did this week were

  • review feedback from Design System Day 2023 and decide what we should keep, add, do more or do less next time, so that it can better achieve its goals
  • define some objectives and key results (OKRs) for our community strategy, so that the direction and high-level goals are more clear to others
  • shape a stream of research with our user researcher that will form a growing base of insights about our service proposition

We were co-located in Manchester. It was lovely to work with people, face-to-face, drawing on walls. You can do that stuff online, it’s not impossible, but my preference is for free-flowing conversation, no distractions from notifications, and scribbling on walls and paper, not digital whiteboards.

Community strategy

Most of what I did was retrofit some structure to an already great strategy that Imran has been executing. We want to add more people to that workstream, make it a little squad, so the structure is mostly for their benefit. But defining the key results, some kind of performance indicator, was also essential for being able to show our senior management team and others that the community model works. That it feeds in to growing the design system’s userbase and impact.

We didn’t get as far as defining the OKRs, but we did review the strategy so far: the problems it’s looking to solve, for whom and how. The behaviour change it intends to create. Off the back of reviewing that, we wrote some hypothesis statements for all the different initiatives. For example, because people are intimidated by looking silly or don’t think our Slack channel is active, we think that that posting in Slack more regularly about interesting blog posts, useful conversations, and asking questions will mean people move from being lurkers to more active participants, measured by an increase in new posters.

Next we’ll need to get all the hypothesis statements up on a wall, see which we can combine or group together, and then decide a sequence of tasks. You can’t do it all at once. Sequencing the initiatives will form a roadmap, and grouping the statements together will form some OKRs.

The other main thing we achieved that day was deciding which community members we’d focus on. We’ve got a handful of very engaged people and many lurkers, but we need to bring in more of the lurkers and get them participating actively. The Dunning-Kruger effect tells us that people with low to medium experience in a field are more likely to engage compared to people who’ve been in their roles a long time, so bringing out those folks should be more fruitful.

We’ll see, anyway. Onwards!

Shaping up research

The main problem to solve here was to give our user researcher a continuous body of work. Research on the team can be very stop/start: there’s lots to do when we start looking at new component or pattern, then it goes quiet while the designers and developers do things, and then there’s a big need for the researcher when we get to usability testing. It’s hard to fill the gaps because you don’t know how long a gap will last, and working on components and patterns isn’t the only workstream: we want to improve the design system as a service too.

The day was mostly focused around defining a lens for the research and some problem statements to kick things off. It’s a big space and the blank page problem can be hard to push through, but I dug out some work Ignacia did on the service design a while back and we used that as a base. (It felt good not to reinvent the wheel! This team remembers.)

Rather than research all the stages of the service, we’ve decided to focus on the first one, when people explore which components and patterns they might need for a given project and the GOV.‌UK Design System is one of the resources they review. We believe that we do things very well for people who’ve got lots of experience in their role or have been in the government digital space for a while, but people on the lower end of those scales aren’t as well catered for.

For example, the people working in customer support who are suddenly given digital responsibilities and have to wear multiple hats. Or the people who’ve transitioned to being a designer after many years working in another field. Or the people who’ve been in tech for a few years but only recently started working in the public sector, who don’t have a good picture of the landscape and have no idea why they’re being told that date pickers are bad.

Anything we learn about these people should enable us to make improvements to our service that benefit everyone, and make it easier for the people after them to use the design system too. It feels like there’s high turnover in government, people joining and leaving the space regularly, and the data shows that there’s a skills deficit, so you can bet that more people need help and more people will join over the years. So it makes sense to focus on those people. It’ll be a while before a platform like GOV.‌UK Forms can sustain them, and they’ll still need to know which components and patterns to use anyway, which is help and guidance we provide.

Moving back to a more regular cadence of research will be great, a bit more like the old days. And we’re not re-asking the same questions, we’ve given the research a totally new lens and focus. Onwards!

Ethics in design

This week was all about exploring and analysing risks and harms using a set of different tools. They shared a bunch of different resources we could use in team workshops, one of which I had used before. It reminded me that I’d done some work like that on a team before, so I’ll write it up soon.


  1. Nearly missed my train to East Croydon because I was tinkering with my website, which feels rather apt.