This week was busy but it felt rewarding. Tiring, but worth it. More time learning about the system around the design system, and how the design system is not really a thing at all. Plus a community event.

This week I

  • helped out on support
  • learned about our economic model
  • met our new deputy director, Amanda
  • caught up with our CEO, Tom
  • framed work on growth
  • ran sprint planning (poorly)
  • helped the team make a tricky JavaScript decision
  • joined an all-day workshop on Exit this Page
  • delivered an unconference for product people in the public sector
  • did high-level roadmapping for the quarter and beyond, and
  • talked more about the JavaScript strategy.

I’ve written that down because last week I wasn’t happy with my weeknotes, too much of the work I did wasn’t present. That’s bad because Future Me will have an unreliable record when looking back to see how I did a thing, and there’s not much substance for others to ask about, to comment on. Ideally my manager, their manager, and my manager’s manager’s manager can look at that list above and decide whether they want to continue reading. Same too for anyone who wants to learn about my work, how I do things and why. (These are my weeknotes, not the team’s.)

Growth and hyperobjects

I’m really appreciating the Design System team’s openness and open-mindedness, their willingness to share thoughts and ideas as well as discuss and develop those together. Three examples stuck out.

  1. Our community designer said how funnels were an unhelpful model to think about growth, and that flywheels are better, which I agree with. I could have used a flywheel in the growth presentation but, to be honest, I don’t know what one is. But I do talk about growth loops, which is the same.
  2. Our content designer asked whether the growth work could be labelled as service design, which it is. At the startup, I spoke to the CEO and CTO about how, for a product team, growth work is the same as product work, but it’s marketing that adds on positioning, narrative and inbound sign-ups. In conclusion, ‘growth’ is VC-funded startup rhetoric for service design.
  3. Our frontend lead shared thoughts on how our team doesn’t work on components, patterns and styles but rather the stuff that holds the design system together – the system itself. That chimed nicely with my thoughts on hyperobjects and my practice as a product manager to focus on the invisible matter.

Thanks to them sharing their thinking, I’m wondering whether our team needs to think about ‘the size of the opportunity’ in our growth work at all. Finding out who’s not using the design system and trying to reach them is starting to feel like a pointless endeavour. We know where the design system isn’t used: by anything that has an exception to be on GOV.UK.

Aside from collecting data on who is using the design system, to feed into our economic model and quantifying the benefits our team provides, I suspect it’s more worthwhile to focus on service design and eking more value for service teams. Educating on consistency, catalysing iterations and non-uniformity, making it simpler to get started or find what you need, help teams do less.

Product Unconference 2023

One of the main stories this week: I ran an unconference for product people in public service with the help of Debbie, Jukesie and a group of community-minded volunteers: Antonia, Dan, James, Keelan, Laurence, Lisa, Maxwell, Oliver, Ruth, Stuart, Tom, Tyronne, and Zuz. We had folks from central government, local government, the third sector, science & technology, and academia.

You can see the sessions people pitched and delivered, and there’s open notes associated with each of the sessions (except Fail Camp, for good reason). Interestingly no one used the themes of the day to shape their sessions, so maybe those are more relevant for finding external speakers.

Quite a few people thanked us for running it, which means it must have been good, and that makes doing this stuff worthwhile. I couldn’t have done it without the enthusiasm, support and collaborative work of Debbie and Jukesie though, so I’m looking forward to building on the day and doing more with them! Jukesie’s written about our further plans.

(A funny scene from the day: me digging around in the rubbish bag for drinks cans to recycle.)

We popped to the pub after the wrapping up the day, and I had good chats with a few people. After an hour or two, I took myself away. There were loads of people I wanted to talk to, but I was wiped from hosting and running the day. Despite leaving early and not drinking booze, Friday felt like a slog, tiredness reigned, so I’m sure I would have been worse off had I stayed longer. And anyway, I can catch up with people over coffee or video.

Exit this Page

Exit this Page is a component (potentially a pattern) weighted with the responsibility of the outcomes it hopes to achieve. The goal for Exit this Page is to help people who may live in an abusive environment to leave a page quickly, lowering the risk of their abuser spotting ‘bad’ behaviour. That’s a lot. Actually, it’s more than a lot, and the burden is weighing on the team.

There’s a need for us to get this component out, so that more services can implement it and users can (hopefully) benefit from it. But there’s tricky details to it, ways of interacting with the component that could highlight ‘bad’ behaviour to an abuser rather than allow the user to exit silently and swiftly. It’s a conundrum. But as one person in the steering group said, so sincerely: ‘Something is better than nothing.’

In the workshop, the team spoke lots about these risks and potential routes for reducing the risk, ways we could validate that our approach would minimise the potential for harm on users. But those conversations, thoughts, routes, all fizzed about in the air without us arriving on a collective viewpoint, a collective path forward. So I suggested we run a risky assumptions workshop to highlight the risks, possible mitigations and our confidence we’ll be able to mitigate those fully. We’re running the workshop next week.

JavaScript strategy

The JavaScript work is pushing and stretching my skills. It’s technical architecture work in the frontend, an area I don’t have much experience in, and it doesn’t only impact a thing we own but also many things that service teams deliver – and the way they do JavaScript. My approach thus far has been to have detailed chats with our frontend lead to help them figure it out, and to keep reframing it from ‘the JavaScript work’ to a narrative that shows the outcomes we’ll deliver. Very puzzling, very involved, frankly more enjoyable than I’d expected.

Bookmarks