Update: Karri Saarinen posted a more nuanced article about his thoughts here: https://x.com/karrisaarinen/status/1999623683065987330?s=61

I figure I'd rebut this "refinement" of his thoughts here:

A lot of the commentary I’ve seen is about making design quality happen through better implementation, which is great but not really about designing.

If design isn't caring about "how it works" then I'd agree. I obviously do not agree.

I tend to think about design as a search, not a production pipeline.

You can search and explore – and still care about how it works – during the "messy" phase of design.

The thing I want to preserve is a phase of thinking, and not pretend it is not worth our time. Early design needs freedom. Later design needs reality. When those phases get collapsed, you can still ship and fast. But you might also trade the search for the shortest path.

Well, this is what we call in journalism burying the lead (or lede if I have to prove my stripes). Of course, I agree with him 100% on this.

But I also believe that design in code gives you a different type of freedom: The freedom to actually use a real thing in your hands, and feel how it works, rather than imagine an abstract experience in sketches and mockups. And that refinement of use over time, THAT is just as valuable a commodity as the freedom to explore and not lock into a design.

In other words, a wordy way to say: Why not do both?

Why not do both.


A rebuttal to Karri Saarinen’s post on designing in code: https://x.com/karrisaarinen/status/1999382416218292586?s=61

Bullshit!

Design is the craft of intention. The problem to solve. The form you want to make real in the world.

I design in code because I like to work as close as possible with the actual material. Like how a mason works directly with stone and mortar, or how a guitar luthier works directly with wood and glue.

Designing with code means you are closest to the tools that render intent for digital products.

I know working with code is not for all designers. Should a designer use non-code tools to communicate intent? Of course! Our mason can explore options with miniature clay models. Our luthier can sketch new instrument designs on paper.

I do the same for digital design. I start with pencil sketches, and when appropriate, digital canvases.

But, I can also render intention in code with interface mockups and functional prototypes, which are both very effective at rendering intent accurately.

Saarinen’s claim that working directly with the materials of rendering intent – whether stone, wood or code – stifles creativity and idealism, and over-constrains the design … well, it’s utter bullshit.


Ironically, near the end of his post he tells designers to “get close to the medium.”

And yet, Saarinen advocates the exact opposite: Keep your distance from the medium! Stay away from code tools. Don’t work directly with the materials that render intent.

Saarinen’s core takeaway? Designers, dream big, imagine the future – and stay in your fucking swim lane. Design generalists are toxic, so hand off to coders to build your intention for you.

That’s a fine approach for Saarinen’s work. Steer clear of the code, design specialists!

But don’t believe for a second that designing with code – working directly with the materials that render your intent – leads to local maxima and ruin, or is somehow an inferior design process.

Thanks for letting me blow off a little steam.

This reflection brings to mind a saying that has stuck with me over the years: 



“When judging a debate, listen more closely to the person who’s done it, than the person who can’t imagine doing it.”