Lately, I’ve been questioning one of the more beloved words in our industry: “craft.” It shows everywhere – in portfolios, product copy, and job listings. But is it helping us describe what we do? I think craft might be the wrong fit for modern design and development.
Saying Goodbye to Craft
Let me preface this by saying that I love great design. I love clean, reusable, maintainable code. I appreciate thoughtful interactions, polished interfaces, and the feeling you get when something just clicks because it was built with care.
But I’ve been thinking a lot about the language we use to talk about our work – and one word in particular keeps bugging me: craft.
Craft shows up everywhere these days. Designers are “crafting experiences.” Developers are “crafting performant, scalable components.” You hear people say, “We take pride in our craft.”
It sounds nice, but the more I see it, the more I feel like it might not belong – at least not in the way we keep using it.
The Problems with Craft
Harry Roberts, in his 2013 post, The Problems with Crafting Code, summed it up pretty well:
“Crafting code sounds slow, meticulous, bespoke, indulgent, self-serving, and inefficient.”
That hit me. Because when I think of the kind of work I want to do – and help others do – it’s not about bespoke. It’s about creating systems. About enabling teams to move faster, build better, and create consistently great user experiences across scale.
Craft implies a kind of artisanal, hand-made preciousness. But modern product development? That’s more like industrial design – thoughtful, yes, but repeatable. Testable. Maintainable. Collaborative.
And that’s where I think the word falls short.
It Can Become a Performance
Designer Cennydd Bowles wrote a compelling post called Against Craft, where he makes this point:
“Craft is inward-looking. It can prioritize the creator’s emotional needs over the needs of the user. It can become a form of design performativity, an aesthetic of doing the job well rather than actually doing it well.”
That one stung a little. Because haven’t we all been there? You get caught up in refactoring something until it’s just right or spend a little too much time polishing a component that maybe didn’t need all that attention – and it felt good. It scratched an itch.
But was that time well spent? Did it make the product better? Did it make someone’s experience smoother or more accessible?
Sometimes yes. But not always.
Rejecting the Label
Mark Boulton, a seasoned designer and educator, offers a compelling viewpoint on distancing ourselves from the craftsman label. In his article, I’m not a Craftsman, Mark explains that associating our work with craftsmanship can be limiting and doesn’t fully encompass the collaborative and systematic nature of modern design and development.
“I’m not a craftsman. I don’t work alone in a shed, chiseling away at some piece of wood or stone, creating something unique and personal. I work with people, on problems, in teams, with deadlines, budgets, and constraints.”
This perspective aligns with the notion that our roles are multifaceted, involving collaboration, problem-solving, and adaptability. Embracing this view encourages a shift towards valuing the process and outcomes of our work rather than romanticizing the notion of solitary craftsmanship.
It Romanticizes the Work
Dan North, in Programming is not a Craft, pushes back even harder:
“Software is too important to be crafted. It is designed. It is engineered. It is invented.”
What I love about that line is how it reframes the stakes. We’re not carving wood here. We’re building tools, platforms, and systems people rely on every day – to run businesses, to learn, to express themselves, to earn a living.
That’s not to say we can’t or shouldn’t care about quality. We should. But quality doesn’t have to mean crafted. It can mean tested, thoughtful, and well-documented. It can mean usable, accessible, and inclusive. Those are much more important than pixel-perfect.
It’s Vague, Too
Even outside tech, the word craft is muddy. The American Craft Council explored how the word has been used over time – everything from fine art to DIY rebellion to “just” handiwork. It means a lot of things to a lot of people.
In our world, that lack of clarity is a problem. If I tell a team, “we value craft,” what does that mean? Does it mean consistent design tokens? High test coverage? Cross-browser accessibility?
Language is important. Especially when you’re working cross-functionally. Craft might feel cozy and inspirational, but it doesn’t help align the work or clarify expectations.
What Should We Say Instead?
If “craft” is too vague or self-indulgent, what are we trying to communicate? When we say we value craft, I believe we’re often referring to our commitment to clarity and quality – things like code readability, design consistency, and a focus on user outcomes.
We want to show that we sweat the details, which translates to prioritizing accessibility, performance, and UX polish. It’s not about perfection for perfection’s sake but about delivering something that works well and is easy to maintain. We take pride in our work, but that pride is reflected in the ownership we take as a team, in our documentation, and in our sustainable, long-term approach. Finally, the elegance we seek is not in decorative flourishes but in simplicity, scalability, and the thoughtful systems that make products resilient and adaptable over time.
One Last Thought
There’s nothing inherently wrong with caring deeply about your work. I do. I always will. But I think we owe it to ourselves and our teams to be more precise with our language.
“Craft” may sound romantic, but it’s not the clearest or most helpful way to describe the work we do as designers and developers. Our industry has evolved. So should the words we use.
Let’s leave “craft” to the ceramicists, the luthiers, the leatherworkers. What we do is design, build, scale, test, maintain, and evolve.
And that’s more than enough.