It’s going to be tough writing weeknotes this week as I didn’t bother tracking all my tasks. Also didn’t set goals at the start of the week, so felt a bit aimless at times, but still got plenty of good work done.

What did I do this week? Here’s a half-remembered list. (I did way more than this.)

  • Joined the fortnightly sprint ceremonies: show & tell, retro, and planning
  • Added a guide to our team playbook
  • Caught up with our community designer on plans for launching Task List, a new pattern co-designed by the community
  • Spoke to a recruiter about a new contracting opportunity
  • Went to our Wednesday morning fika, where one of our designers introduced her history and what she likes doing
  • Planned the final stages of our WCAG 2.2 work, with a focus on getting it released after the festive break
  • Caught up with the Head of User Research on upskilling people across the programme
  • Joined the final Ethics in design class
  • Caught up with our deputy director
  • Met our new colleagues in Comms
  • Checked-in with our senior management team
  • Spent an afternoon working through my thoughts on a strategy for the GOV.‌UK Design System
  • Caught up with a couple of our devs, mostly to check understanding on release plans
  • Added videos from Design System Day to the website
  • Met a team in another department looking at ‘AI patterns’
  • Wrote a note for the leadership team on how we’re collaborating on design across directorates
  • Some other stuff I cannot remember

Speeds of collaboration

During the pandemic, I really nerded out on remote-working principles and practices. I was obsessed with learning how to do it well. Xander and I ran an experiment with the GOV.‌UK Pay team where we worked asynchronously for two weeks, I kept notes on how companies we adapting their offices for hybrid remote-first working, and I wrote about the free-range future of work.

One of the things I learned was how to use instant messaging, email, documents and meetings properly. The four speeds of collaboration. The basic idea is that collaboration happens at different speeds and the medium of collaboration sets some rules. If you post a message on Slack, that’s instant messaging, and everyone’s going to assume you need an answer right away. When that’s not necessarily the case, maybe you’re just starting a slow-burning conversation. But without prefacing your message with whether it’s urgent or not, everyone’s likely to treat it as urgent because you’re using an instant messaging tool.

I figured that was something most people knew but I don’t think they do. And for reasons I can’t remember, a designer helpfully brought it up in our retro when talking about how to get help from other people on the team. They also suggested a basic template for giving team-members more context about your ask, so I added it to our team playbook.

While adding it, I looked in the GDS wiki to see whether there was any guidance on async communication, remote-first working, and how to use time in the office properly – I wanted to link to and point at things the organisation had shared. But I found nothing. Which really surprised me, to be honest. We had guides for that at Claimer and NHS Digital, but not at the organisation leading digital transformation in the UK government.

I’ll add a bunch more stuff to the team playbook but perhaps it’ll be useful to run some lunch & learns or add stuff to the wiki. I’ll ask people working in Business & People Services (the ops and HR bit).

Ethics in design

The final lesson went over Ariel’s theory of professions and why those have ethical responsibilities (which I knew from reading his book). Then we looked at cultural differences in ethics, responsibility in design, and making the case for design ethics. That last bit was all about how to write a business case for design ethics, how it can increase revenue, decrease costs or decrease risk. As the only product manager on the course, I really felt like I was in my element there!

It’s been an excellent course, not just because it has practical tools you can use but also because it dives into philosophy and ethical theory, the hard academic stuff. Check it out.

Thinking through strategy

George and I spent a few hours working through my thoughts on a new strategic model for the GOV.‌UK Design System. I’ve been building this model up over time, informed by a few workshops with the team and working on growth and community strategies too. I’d got to a point where writing in docs just wasn’t doing it any more, so I asked George if I could get it all out and have her pick holes in it.

First thing to mention: it was lovely to just slam some things up on a whiteboard, haven’t done that in yonks. A content designer from GOV.‌UK even said it gave him the warm-fuzzies seeing people doing that again. A hark back to times of yore.

The strategic model I’ve had in my head seemed pretty hare-brained, I didn’t really know if it could work, but working through it with George I was able to validate that parts of it do work because we’ve been doing that stuff already. And we can prove it.

The biggest help she gave was asking about the strategic context. That’s something I’d mentioned on some documents but not the main place I was collating all my thoughts. What is the strategic context? Simple. Technology is always changing and people’s expectations change with it. What was good enough in 2018 is now old-hat, and people expect more ease and convenience in a modern, high-quality user experience. This is something I’ve been banging on about since 2019: transforming government to be user-centred isn’t finished.

So, anyway, we had this big model sorted and all the factors were highlighted. We could show how adding a few more people to the team to do specific activities would lead to growth, a better quality design system that meets its users’ needs, and would free up capacity on our team for maintaining the thing. The next thing to think through was how to frame it. Usually I’ll reach for classic product management narratives: if we do X, it will lead to Y measurable benefit. However, the biggest problem any design system has is traceability – you never know exactly how much impact you’re having. It’s a hyperobject.

George suggested some policy-style narratives instead, the sort you see used to support government policies, which are even harder to measure. If we do X for society, it will lead to Y societal benefits. More Theory of Change than business case.

I’m fairly certain I’ve everything I need to pull this together now. Thinking out loud, my next steps are:

  1. pull the model together and explain it, showing the potential return on investment
  2. run that past the team, highlighting the risky assumptions
  3. add those risky assumptions to the discovery objectives we wrote a few months ago
  4. plan a discovery around those objectives
  5. reach out to teams in government, and
  6. run the discovery.

This should mean I can end my time on the GOV.‌UK Design System by handing over a validated strategic model that they can start implementing, using it to shape roadmaps, ways of working and hiring plans.

I hinted at some of what’s next at Design System Day, so check out the video at 26m59s for more on that.

‘AI patterns’

A team dropped us a line to talk about ‘AI patterns’, as they wanted to make sure they were looking at this in the right way. We’re always happy to help out with this stuff, so it was good to get involved.

Largely they were asking about how to style a chatbot interface, but their interaction designer had done some good work to look at how people had done that already.

‘AI patterns’ seemed to be shorthand for ‘use large language models to augment support provided by people over the phone’, which was the assisted digital companion to a list of searchable, filterable documents that users could look through themselves. Basically, if a user didn’t look through those documents, they could call up a phone line, tell the support agent what they wanted help on, and the support agent was supposed to re-key that help request into a large language model which would spit out an answer.

Which seems like a really expensive, cumbersome way to get an answer to people.

First of all, running and maintaining large language models is expensive. You’ve got to pay for input tokens – some times output tokens too – and that could cost 5–10 pence per session.

Then you’ve got to think about how much it costs in people time to tweak and engineer the model to spit out useful answers based on the prompts. Highly skilled developers need to do that, and those people cost lots of money.

I could go on, but I’ll stop there before it becomes a rant.

As much as I think it’s worthwhile to be exploring new technologies, you need to make sure the juice is going to be worth the squeeze. Spending several months and tens of thousands of pounds trying to add automation to a process that works well already is a waste of money and time. Use technologies appropriately, don’t just follow the latest hype.

Running

Did zero training this week. Thought I was coming down with a terrible flu last weekend which made me feel worse on Monday, but it never really hit. So I guess I’ll pick it up again next week.

Bookmarks

Feeling particularly proud today as I’ve managed to fix a broken automation. Whenever I archive something in Pocket, a Zapier automation adds that to a running Google Doc which holds a list of everything I’ve read since 2019. It’s been a bit flaky recently, missing out some of the articles or blog posts I’d read. So I replaced it with my own automation that calls Reader, meaning I get rid of Pocket all together!