The Chats

Writing these on Wednesday night and I’ll publish them on Thursday night because Friday is holiday time.

This week I

  • caught up with a team answering our call for speakers for Design System Day 2023
  • did a workshop on roles & responsibilities, and one on our contribution & product development model, at a team coaching session
  • picked up a good perspective on what it takes to run the design system from Tom
  • checked in on the team’s work to update GOV.‌UK Frontend to be compliant with WCAG 2.2
  • prepped for check-in with our senior management team
  • filled in a data protection impact assessment for a new tool
  • met with the excellent Jess to pick up tips on open source, maintenance and communities at GitHub
  • met with my Strava crush, Tom, to talk about design, data and running
  • met with design evangelists Linda and Mike to learn how they iterate and develop Apple’s Human Interface Guidelines
  • added a contribution guide to our team playbook
  • updated the roadmap, and
  • joined (or facilitated) the usual fortnightly show & tell, retro and sprint planning ceremonies.

Coaching

Stefan ran a great workshop at the start. The team went over the principles that Imran, Kelly and I set back in April and rated which ones we were doing best at and which ones we had room to grow on. We reviewed the answers as a team and many people thought we could do better on ‘Transfer power’, which is fair enough as we’ve only made a dent as a collective.

Everyone thought we were doing well on ‘Progress, don’t perfect’, which initially I wasn’t sure about. But then Stefan asked us to think about examples or reasons we answered the way we did. And as I thought about it, I realised the team had done a fair bit on that principle recently. Which made me feel bad for not realising it sooner…but I felt great about the progress the team has made.

Next up Kelly ran a workshop we put together on roles and responsibilities. The team have been wanting to know what their roles are, where they fit in, what they should and shouldn’t do, and we wanted to address that. But I didn’t want to tell them because I believe they know. So instead, we read through the DDaT profiles for each role and marked down things we knew we were expected to do and things we weren’t sure about. We went through the ‘Not sures’ as a team and either clarified a responsibility or put a pin in it, to come back to it later.

After lunch, I ran a workshop on our contribution & product development model and where people fit in. Using our iterated model as a base, I asked each discipline on the team to note down whether they had a driving role, a supporting role, or needed awareness only at each stage of the model. It was pretty much bang on, although there’s a couple of opportunities to downgrade roles (from supporting to needing awareness) and create some co-driving.

Once that was done, I asked each discipline to note down their top two needs from other disciplines in order to do their job well. I wish we’d had more time for this as we could only cover the top need, but people were able to sign tacit contracts with each other or ask for more clarity. We must revisit that workshop and nail it down, as it’s going to make multidisciplinary working so much smoother.

What it takes to run the design system

Right now I’d say the team is working close to full capacity. Some tweaks to processes will help but it’s mere optimisation for marginal gains. The GOV.‌UK Design System is a well-adopted, mature design system – it’s in a great place! – hence the demands on our team. But the backlog is years long, we don’t have time to review and iterate the existing catalogue, and managing the community needs a small team itself.

To scale the Design System to meet the demands placed on it, we’re going to need to distribute and devolve governance and assurance. And that’s a big experiment. If it doesn’t work or it’s not sustainable, the team will need to grow. Not by many, maybe 3 or 4 people, but that’s a bigger budget when purse strings are tightening.

Open source, maintenance and communities

Jess is a staff product manager at GitHub and looked after the Sponsorship and Maintainer products until a recent restructure, so I wanted to find out if she’s come across any best practice with sustaining community contributions for open source software. She had tons of advice, and thankfully a lot of it validated what we’re already doing.

Documentation needs to be tight, making it clear you want help is a must, and making community contributions sustainable is a decades old problem no one has really solved. But by continuing to believe in and add effort to the cause, we might just crack it one day.

Interface guidelines

Apple’s design language is 40 years old, so it was great to get some hunches confirmed (and a few tips to boot) from Mike and Linda on the Human Interface Guidelines team.

There is a paradigm shift in GOV.‌UK’s design language soon, from static web-based experiences to dynamic multichannel experiences. The challenge is keeping the look and feel, the brand, consistent while meeting many of the expectations and constraints put on our 10-year-old design language. It’ll happen slowly. Ideally you won’t realise it’s happening. Boring magic and that.

We can help make that happen but also we mustn’t get in the way of teams innovating. So it was helpful to learn from what kind of things work well. Quelle suprise, a strong design community of practice helps maintain consistency, but so can designing new capabilities for our service.

I made many notes in that chat but don’t have them to hand, so I’ll add them at a later date.

Bookmarks

· Weeknotes

0 replies, 0 reposts, 2 likes