Apply for a clown car licence

I’m writing this on the train home from London. I left the house 14 hours ago and I’m still not back. I’m wiped.

It was a great day.

Becca, Tash and I ran a full day of training on prototyping in code with the GOV.UK Prototype Kit. There were 20 people in the room, from central government departments, the wider public sector and consultancies. Some of our own joined, because we train our people on this content too.

We started with the basics of HTML and CSS. Then the kit itself. The aim was to build a service and publish it online. The service was “Apply for a clown car licence”.

Why a clown car licence? For fun, and because nobody would believe it’s a real government service. And it’s still within the common service pattern of applying for a thing.

Little moments of joy

The best part of the day was watching people get something working.

Sure, there were parts people found frustrating. A line of code deleted by accident. Syntax that wasn’t quite there yet. But the frustration is what made it so good when the page finally loaded and they realised they’d made a thing.

There were actual little physical joy reactions. It was lovely to see.

Why we do this in person

People were at different levels, and that’s okay.

Not everything went to plan. Different organisations have put different security controls on their laptops, so not everyone could get to the software they needed, like the terminal or GitHub Desktop. That’s no reflection on anyone in the room. We worked around it where we could, and we’ve offered to follow up once people have sorted things with their IT departments.

We never stopped. Keeping a sense of the whole room while helping people one to one kept all three of us busy. It’s also why this is the sort of thing you need to do in person, so you can troubleshoot together.

Why designers should know how to code

I believe all designers should know how to code.

Not because they should become developers. There’s a sweet spot much, much sooner than that. It’s another tool in your toolkit.

It’s about understanding the medium you’re designing for. I wrote back in 2017 that interactions are made of code, not mock-ups, and I still think that. A prototype in code makes the interaction real, and that gets you better evidence from research sessions. It also leads to deeper conversations with developers, translating design intent from policy and problem to working software.

Not every prototype should be in code. But when it should, it’s better to know how than to make do with Figma or a similar design tool.

And it shouldn’t become a prototype so complex that you’ve created a whole new environment to maintain, one more before dev, test and prod. That’s why we kept repeating why we prototype in the first place. To learn something new. To communicate intent. To validate or disprove an assumption. At some point the deep collaboration with developers should be happening, and the product should be the thing you maintain.

Thank you Becca and Tash, for organising and for assertively controlling the room. You were great.

And thank you to everyone who came and gave it a go.