There is a question I get from clients and collaborators fairly often, usually right after they have seen both my Figma files and my GitHub repos sitting open in the same browser window:
"Wait — you do both?"
Yes. And not in the way that sometimes gets packaged as a selling point, where design means resizing a Figma template and engineering means wiring it to a CMS. I mean the real thing: designing the system before building it, making deliberate decisions about hierarchy, interaction, and information architecture, and then implementing those decisions in code myself, end to end.
I do not say this to impress anyone. I say it because the order matters. Designing before coding is not a workflow preference. It is a discipline that changes the quality of what gets built, the speed at which it gets built, and the number of times you have to tear it apart and start over.
This post is about why I work this way, what it actually looks like in practice, and why I think every engineer who wants to build better products should at least understand the design layer, even if they never open Figma.
THE PROBLEM WITH JUMPING STRAIGHT TO CODE
Most developers, and I was one of them, treat design as a phase that happens before the real work. Someone hands you a mockup, or you sketch something rough on a notepad, and then you start coding. The design is a reference artifact, not a thinking tool.
The trouble is that code has momentum. Once you have scaffolded a component structure, written your routes, and wired up your data models, changing the underlying idea becomes expensive. Not just in time, but psychologically. You have already built something. Pulling the thread feels like destruction.
So you compromise. You bend the UI to fit the architecture you have already created. You make the feature work the way it was built rather than the way it should work. And the product quietly becomes worse in ways that are hard to articulate but obvious the moment a real user touches it.
Designing first short-circuits this. When you are working in Figma or even on paper, the cost of being wrong is almost zero. You can throw away a layout in thirty seconds. You can restructure an entire user flow in an afternoon. You can test three different approaches to the same interaction without writing a single line of code.
The best code you will ever write is the code you never had to refactor because you thought clearly before you built.
WHAT "DESIGNING FIRST" ACTUALLY MEANS
I want to be specific here, because "design first" can mean a lot of things. I am not talking about pixel-perfect mockups of every screen before writing any code. That is a different kind of waste: over-designed artifacts that take weeks to produce and then get immediately modified the moment they hit reality.
What I mean is this: before I write a component, I need to understand what it is trying to do. Not just what it needs to render, but what decision or action it is facilitating for the user, how it relates to the things around it, and what it should feel like to interact with.
In practice, this looks like:
Sketching the user flow, even rough boxes and arrows, before opening my IDE
Identifying the primary action on every screen and making sure the visual hierarchy supports it
Thinking through the empty states, error states, and loading states before writing the happy path
Deciding on spacing, type scale, and color role before writing any CSS
Asking "what does the user need to feel confident here?" before deciding what information to show
None of this takes weeks. For a single feature, it might take an hour. For a full project, a few days. But that investment consistently reduces the total time to a finished, polished product, because you are solving the hard problems before the code makes them expensive.
THE ENGINEERING BENEFITS ARE CONCRETE
Here is what surprises people when I explain this: designing first does not just produce better UI. It produces better code.
Cleaner component architecture
When you have designed the UI before building it, your component boundaries are usually obvious. You can see which elements repeat, which ones share state, and which ones are truly independent. You end up with components that are actually reusable rather than components that are technically reusable but in practice never get reused because they are too tightly coupled to their original context.
Fewer breaking changes
When design happens after code, you frequently discover that the interaction you need does not fit the data model you already built. You need to paginate something you built as a flat list. You need to show related items in a context where you only fetched the primary record. Designing first forces these questions to the surface early, when they are cheap to answer.
Better API contracts
This one is underrated. When you know what the UI needs to display before you design the API, you write endpoints that actually match real user needs rather than endpoints that match your database schema and leave the frontend to do expensive gymnastics with the data it receives.
In practice, I have caught significant backend design errors in the Figma phase that would have been painful refactors post-implementation. A dashboard that needs to show aggregated data across three related entities in one view changes the API design conversation entirely. It is far better to have that conversation in Figma than in a pull request.
THE OBJECTION I HEAR MOST
"That is fine if you are building your own projects, but in a real team, there is a designer. You just implement the designs."
Yes. And understanding design makes you dramatically better at that, too.
Engineers who understand design do not just implement specs. They catch problems in specs. They notice when a design is technically implementable but will perform badly. They ask the right questions in design review instead of discovering the problem in QA. They understand why a spacing decision was made and can therefore make the right call when implementation details require a deviation.
The best engineers I have worked with do not treat design handoffs as instructions. They treat them as conversations. And you can only participate in that conversation if you understand what is being designed and why.
You do not need to be a designer to think like one. You just need to care enough about the user's experience to ask the question before writing the code.
WHERE TO START IF YOU WANT TO BUILD THIS HABIT
You do not need Figma. You do not need design theory. Start with this:
Before you write your next component, draw it on paper first.
Not to make it pretty. Just to answer: what is this component trying to do? What does the user need to see? What actions do they need to take? What happens when things go wrong?
If you can answer those questions in a sketch, your code will be better. Every time.
From there, the skill compounds. You start noticing when layouts are fighting users instead of helping them. You start catching your own mistakes earlier. You start writing APIs that serve UI needs instead of database convenience. And eventually, you stop thinking of design and engineering as separate phases, because they are not. They are the same problem, approached from different angles.
CLOSING THOUGHT
The best products I have used do not feel designed. They feel inevitable, like they could not possibly work any other way. That feeling is the result of decisions made before a single line of code was written.
Design first is not a workflow. It is a commitment to taking the user's experience seriously enough to figure it out before you make it expensive to change.
If you are building something right now and you skipped this step, it is not too late. Open a blank file. Draw what you are building. You will see the problems immediately, and you will be glad you found them now.