Effective labour

We’re now fully into the “let’s make some stuff” phase of our exploration of how to make better use of native code. Before the work started, my ambition was to spend about half my time on this with the team for the last quarter of 2025. So far, so good, but retaining enough brain space to keep on top of everything else I’m meant to be doing is a challenge. Much to my chagrin, the rest of the world has not ceased to exist simply because I have something fun to do. How rude.

This is just the beginning. We’ll see how things develop over the coming months, but to date we’ve avoided Figma entirely. Tosin has been making lots of drawings on his iPad and a great many diagrams have been sketched in Mural, but the team has primarily been working directly in Xcode and Android Studio. For my part, I find SwiftUI to be a reasonably expressive medium. Its a language and/or framework that makes it easy to mock up an idea in a small amount of time and I can query an LLM (no comment) if I get stuck. The result is that our sketches are real software, on a phone, that you can put in front of a teammate or user.

I cannot stress enough how much more effective this approach is for explaining a concept than drawing pictures in a layout programme. Several times in the past few days, there have been moments where the team was discussing something in the abstract (read: chatting on Slack) and we’ve been able to either make a screen recording or say “open the thing on your phone” and that clears it all up. How will transitions between screens work? I’ll just show you. What do you mean when you say “filtering an inbox”? Here, like this. Working this way comes with an ostensibly higher cost – one does need to learn to write some code – however I think this is a mirage. If the goal of the prototype is to demonstrate how something works, I’m not convinced that the effort truly is any greater. Further, the difference in how effective these prototypes are as a tool for collaboration more than makes up for any new skills one might need to learn.

Early experiments look very promising. (Massive caveat: these are just thin interface prototypes that haven’t revealed anything about whether we can afford the changes in the long term.) Comparing these early sketches to the live app is, to quote one member of the team, a moment of “what the heck is that?!” The differences between the two is shocking, which is surprising because they are different in exactly the ways we predicted when pitching to do the work in the first place. And yet, these differences are hard to explain in a convincing way with just words. Being able to experience them directly is revelatory.

Anyway. Things are good and I’m enjoying myself. Being able to spend time with a team running experiments is a privilege. Onward. Here are some links.

• Team dynamics after AI, by Duncan Brown. I have saved so many quotes from this that at a certain point I gave up and just pasted the full text into my clipping file, but here’s a good starting point:

  It seems to me that what we choose to have reflected, magnified, transformed by this magic mirror that is AI reflects, in turn, on us. I am going to argue that irrespective of the merits of our choices (which are often real merits), the use of AI always promotes the legible, the quantifiable, at the cost of the illegible. But as teams and systems scale, the illegible – usually the social and the small-p political – tends to dominate the work.

• Design by cliché, also by Duncan Brown. Glad we have a name for this now!
• Iterate, if you can, by James Plunkett. This section about designers and researchers owning the issues with Discoveryitis is a good prompt:

  It might be useful if the disciplines of design and user research really owned the issue of Discoveryitis. i.e. getting curious about cases in which upfront design work has inhibited iteration, and about why people sometimes feel (not always fairly) that designers/user researchers are saying people should delay trying things out in the real world. Maybe this could lead to some useful guides and professional development – ways for design and user research to fit as well as possible with Test & Learn.

• If not the Mac, what?, by Watts Martin. Nails my feelings exactly. I could read another 1000 words about the specifics, but this bit is spot on:

  “[M]acOS Tahoe marks the first time I’ve ever sat down in front of an Apple-designed UI and thought: this just looks bad. It’s not “Liquid Glass” that’s the issue, per se: it’s how half-assed the Mac implementation of it is. (…) UI widgets just look too big, with weirdly low information density. There’s drop shadows under buttons for that First Day With Photoshop feeling.”

• The strategy is enquiry, by Giles Turnbull. A succinct take on how to look at policy and strategy through the lens of an iterative or agile process.
• Monthnote: August/September, by James Higgott. A double-month update from our Head of Product. Absolutely agree about the highlight of SDinGov.
• Care as infrastructure, by Rachel Dietkus. This was the first talk I saw at SDinGov in September and it set an impossibly high bar. It also inspired my post from a month ago.
• An e-bike for the mind, by Josh Brake. On the trade-offs of e-bikes, AI, and computers more generally. “In so many ways, we accepted them into our lives with a false promise of augmentation without amputation. Only in retrospect are we noticing what’s been cut off.”
• I am sorry, but everyone is getting syntax highlighting wrong, by Nikita Prokopov. Ignoring the intense yellow background of the page itself, this is a nice breakdown of what makes for good syntax highlighting and how, if you highlight everything, you highlight nothing.
• Research is a leadership skill; don’t cede it to AI, by Pavel Samsonov. This is very good on user research, the production of facts vs. knowledge, and when the work is done.

  In other words, research is not done when a fact is produced. It is done when the fact has become knowledge – a process that requires creating not only facts but alignment. Influencing stakeholders is not a distraction; it is the work.

• Accessible numbers, by Laura Parker. A really great resource for “designing services for people who need help with numbers” (which is everyone).
• The cost and price of the NHS, by Lauren Bevan. Bookmarked for future reference.
• The redeployment, by Steve Messer. A weeknote about changing roles and AI (mostly).
• Choosing friction, by Jenny/Phire Phoenix. Leaving aside how this is about AI, this article has some absolutely wonderful passages that can be applied to most everything. For instance:

  It is not virtuous to suffer, and discomfort is not noble. But everything in my life that is worth having, love and friendship and art and community, I found by fighting my way through discomfort. Pain does not mean growth, but growth does require pain. It is so easy in our rotten modernity to choose convenience and ease, to avoid friction at all costs and tell ourselves it is self-care. I choose the friction of refusal because I worry that if I forget how to be uncomfortable, I will forget how to grow. Refusal, like acquiescence, is habit-forming.