Tools for Others
We can now build tools. But what happens after we've got all the shaders we need?
Back in March I got accepted to speak at Berlin design conf Hatch in September. On main stage no less! A few hours before Paula Scher! Swoon.
When I submitted my proposal in February I was ultra clear what I’d be talking about: tools. Building our own tools as design teams, for creativity and expression. It was genuinely (I felt) an original thought at the time, informed by Near Future tool building workshops I’d run with teams including 60 designers at Wise.
And to be clear, I fully believe this to be a valid endeavour. There’s no better way than tool-building to both learn the edges of what’s possible with code in a low risk environment, scoped to hours not days. We saw everything from layout builders and asset generators to fully interactive camera-driven hand-wavey art experiments, all created by non technical designers in a few hours.
However, as the nutty AI hype cycle in 2026 tends to lead to, by June it was starting to feel like I was seeing shader tools, icon animators and interactive 3D globe dashboards daily — all of them cool, but also fairly surface level.
Tom and I even created a fully functioning drunk version of MS Paint in 15 minutes in front of a live audience (try it here). Fun, but not useful.
Going Deeper
Those kind of things are great for a first try (and if you want to build one yourself you should join our upcoming workshop). But what do we do to go deeper?
I’m thinking truly problem-solving, maintained tools that get adoption across teams, find internal product market fit and become vital.
When thinking about tools for my own practice across Near Future and Toy, I realised that one problem that’s dogged me for the best part of two decades was imminently solvable.
That problem is composing emails.
I’ve been helping emails look not shit for most of my career as a designer. Whether hacking HTML myself, fighting dreadful WYSIWYG editors in mailchimp and the ilk, or hiring ‘email developers’ (do they still exist?) to roll out consistent styling across Deliveroo’s marketing comms.
It’s always the worst job. Not just because you’re limited in what you can do to make an email look good and stay compliant, but because you just know that the person actually creating the emails, whether now or later, will end up finding a way to screw it up on the way out. Poor contrast, bad padding, just looking wrong.
And it’s not their fault. You’re all working within the constraints of a third party tool which doesn’t offer enough opinions or guardrails. Of course it doesn’t, you’re one of thousands or even hundreds of thousands of customers.
No longer!
I can now change that. For ooda.run, a hosting product I’m developing, it took under an hour to develop the email composer that I would previously have killed for. Try it here
In short I can now
- Write emails in markdown in a Notion-style composer
- Insert buttons and other elements (pre-designed, no styling options)
- copy the HTML and drop into my email sending platform
Now, I’m a team of one, but if I’d been in any of these roles where I was handing this off to another team, this would have been even better. Designers codify the design language and make updates to styles and building blocks, marketers write emails, confident that they will always look on-brand.
Our tools don’t need to be for us
The point is not the email tool. The point is that as designers most of the design that happens in our companies isn’t done by us. We as the arbiters of design craft have always spread ourselves so thin across product, brand, marketing, internal comms etc. that something drops, but if we look to build tools for other teams not only can we free up our time but we can encapsulate ‘good’ in those tools and increase the design output of others for free.
So next time you reach to build a shader tool, think about what you could be building for your colleagues outside design.