Matthew Morek
@matthewmorek
Design tools are valuable for exploration, but in software the shipped product — not the design file — should be the source of truth.
A lot of teams still recreate their product UI in design tools so they can maintain a design reference. I think that’s backwards. In software, the code is the reference. Design tools are valuable, but mostly as exploratory inputs into an ongoing conversation, not as the canonical artifact.
I’ve worked with enough organizations of different shapes and sizes to spot a few recurring patterns. Regardless of company or role, people tend to treat design artifacts as the source of truth for a project.
That creates two problems straight away. First, engineers sit around waiting for the design phase to be “finished”. Then, once the product is built, development quickly outpaces the design artifacts that were supposed to guide it. The files fall behind, but the team still treats them as the reference point.
The design becomes the bottleneck.
Mostly through good intentions and a lot of professional pride. We assume the right way to build a product is to first produce a beautiful, comprehensive set of design files, then hand them to a strong engineering team to implement to spec.
That assumption slows everything down.
The order of execution is baked in. The delivery process is built around it. Once the machine is in motion, it becomes hard to challenge. Designers design, often in isolation, hand off heavily documented artifacts to engineering, then spend weeks reviewing the build for visual inaccuracies before anything goes live.
That’s a lot of wasted motion.
Meanwhile, the designers responsible for a given feature have often already moved on to something else. They’re too busy to sit with engineering and work through the real issues that show up during implementation. The result is predictable: mediocre execution, avoidable friction, and wasted time on both sides.
Design is a conversation.
A product needs a feature. People talk about the feature, reason about the feature, and explore it together. Design tools should support that exploration, not freeze it into an artifact that engineering is expected to reproduce faithfully later.
Engineering should be part of that conversation from the start.
Design and engineering are disciplines, not separate worlds. When teams are organized around disciplinary handoffs, you get half-baked products and a culture of blame.
“Engineering can’t execute the specs right.” “Design doesn’t understand the technical constraints.”
I’ve heard every version of this.
Form cross-functional teams early. Give them the problem, not a pre-decided artifact to implement. Let them work through it together.
Stop building the “real” design system in Figma or Sketch. Those tools are not the source of truth. The shipped product is.
If you want a predictable, inspectable system, build it into the product or alongside it. Engineers already build internal tools, debug views, and test harnesses. A UI surface that exposes components, states, and variations should not be a big ask.
For single-product teams especially, this is often more honest and cheaper than maintaining a parallel design system in a design tool.
This is not an argument against design tools. It’s an argument against mistaking draft media for the product’s source of truth. This is where people get nervous.
If engineers have code, what do designers have? Do designers just become UX generalists pushing flowcharts, state diagrams, and wireframes around? What happens to visual craft? What happens to polish?
It still matters. If anything, it matters more.
Designers should keep exploring visual directions, refining interactions, testing alternatives, and pushing the quality of the product forward. Sketch and Figma files absolutely still matter. Revisit them, improve them, remix them. Use them aggressively.
Just don’t confuse them with the thing itself.
Once the product is live, the product is the reference. The design files are part of the process that shaped it, and the process that continues to shape it, but they are not the canonical artifact.
Design is a process. A conversation. Not an output.
Don’t let the tooling convince you otherwise.