Designing with code is a recurring discussion, and it’s flared up again. I’ve written about it twice now. Design as a search, not a pipeline. How tools carry opinions, and how those opinions shape what feels “reasonable” to attempt. Why constraints that arrive too early can close off possibilities before you’ve had a chance to find them. I’m skeptical of the industry’s drive toward grand unification, collapsing a nuanced process into code and calling it progress.

The recent discourse has focused on whether designers should code, whether code is the right medium for design, how code “presents the truth” of a design, and so on. But I think centering this debate on code and tools is reductive.

The bigger question to me is what happens to how we see designers contributing in the future, especially now with AI and these new tools. How do roles evolve, and what do we start expecting from each of them?

Are designers now engineers, with the same expectations? Do engineers start having the same expectations of designers? Will we still have a “head of engineering” and “head of design”, or does it turn into something like “head of craft”? Titles don’t matter that much, but these questions are useful because they reveal what we value and how we think the job gets done.

And then the practical question. If designers get funneled toward engineering, designing with code directly, is that a good direction? What do we lose or gain?

Part of why this discussion gets messy is that design means different things to different people. Your view on it depends on what kind of design you do, and how you understand design as a practice.

I believe design comes in many flavors. It’s influenced by the person, the domain, the market, the customers. In consumer products, you might need to test ideas quickly because motivations are hard to predict. In B2B or enterprise, you often have more context and can design from that. Some industries require extreme reliability and clarity. The environment matters too. Stakeholders, clients, company culture, and your skills as a designer. If you’re more visual, you lead with visuals. If you’re strong in code, you might use it earlier.

And for some, design simply is getting the button on the screen and moving on.

So there’s a broad domain of software design, with different tools and methods inside it. The code vs no-code argument often misses the point and becomes a polarizing force.

What I’m trying to say is that I want to elevate this discussion above tools, and make sure tools don’t take over the future of design. I don’t want us to needlessly devalue conceptual and divergent thinking just because new tools make execution easier.

Even engineers who work with code all day step away from it. They draw architectures, plan systems, and reason about tradeoffs. While code is where software lives, it’s not always where all decisions should be made.

To explain what I mean, I have to start with how I understand design and how I’ve practiced it.

Designing the problem⁠

First of all, I’m not a formally trained designer. It’s been self-taught through hundreds of design projects over the last two decades. So I’m not advocating gatekeeping, or any one “right” way to design. But I do think design is rarely linear. You work at different levels of abstraction, move between them. And while the outcome is the goal, spending time on the journey can make the outcome better.

Through that work, I learned to question the problem first, not treat it as an assumption. If asked to work on something, I start with: is this a real problem? What if we don’t do this? Who defined the problem?

It sounds philosophical, but what I’ve found is that the most common reason design projects drag or fail is that the problem wasn’t clear. People won’t agree on solutions, because they have different problems in mind. The solution becomes a compromise of many different problems, instead of a clean solution to one major problem. This compounds when you have too many stakeholders.

To tackle this, I’d do two things. Write the problem the way I understood it, and ask who the stakeholders are. Then when presenting solutions to those stakeholders, I’d repeat the problem to see if it caused reactions. If it did, I’d stop and get the room to align on the problem. So what does this have to do with design? This sounds kind of corporate.

You’re always going to have stakeholders, if not colleagues, then customers. You have to understand whether feedback is true because the solution isn’t good, or because people don’t agree on what the problem is. Sometimes you’re designing against the wrong problem. The problem is the first part of the equation. It’s the foundation of what you’re trying to design and build.

At Linear, we knew quickly that companies needed projects. So what goes on the roadmap is “build projects.” Everyone agrees it’s needed. But if you think about it more, why do companies organize work into projects? Why not just work on the next task? What happens if they don’t have projects?

You can go deep on project management. There’s a whole discipline behind it, and many ways of doing it. But if your vision is to build a purpose-built tool for software companies, you start narrowing. What do they actually care about?

Simply put, projects are a natural abstraction for companies to manage streams of work. They help with accountability, ownership, cross-team collaboration, predictability, and visibility.

Now you might ask why research something so basic or well understood. Sometimes you don’t need to. But learning the landscape and history gives you orientation. You find assumptions you can challenge, or you decide which traditions to follow.

Most importantly, learning the problem first helps you decide what you want to do about it. What direction the product vision is pulling you toward. What you want to optimize and influence.

At Linear, we saw that projects might be the most important unit of work. Products are made of them, organizations orient around them, and you celebrate when one ships. That understanding gave us a direction for what problem we were trying to solve.

Designing the solution⁠

I think of designing the solution in two stages: The conceptual stage and the execution stage. The conceptual stage is finding the overall form the design will take. While the execution stage is building it out and getting it onto the screen.

Take projects in an issue tracking tool, you could treat them as one large issue with sub-issues, a folder or label of issues, or its own entity connected to issues. Those are conceptual ideas you can consider without putting anything on the screen. The decision comes down to your understanding of users, the company, and the vision you want. All of these concepts can work, and you can find them in real products.

Because we saw projects as important, and different to issues, they needed to be their own entity, with their own shape. A project should have a recognizable form and functionality that communicates status, reasoning, user feedback, prioritization, timing, and connection to larger initiatives. Demoting projects to a label or a loose collection of issues didn’t feel right.

This conceptual stage might happen in words, on paper, in a design tool, or in code. It’s just about giving those ideas a shape, trying different directions and eventually choosing the direction that serves the problem and the product vision the best.

Once I have a direction I believe in, it’s ready for broader feedback. You test the concept by building it.

It’s the part closest to the final output. You make the design concept actually work, shaping it into something real. Code, or working with the material, is essential for this. And there are times when you gain new insights and have to go back and revisit the problem or concept.

There are different ways to use code in this stage. You can build tools, or “sketch” with throwaway code. This removes some of the constraints of production code and makes the process more exploratory. My point is that while you might see the execution stage as the real part of design, you’ve already built a foundation of context and confidence. When the material fights back, you’re pushing with that confidence.

Think of it in LLM terms. The design work you do before is the goal, context, and prompt you’re building for the agent to address the problem. The execution work is where you guide the agent through specific decisions.

After reading all this, you might think, who has time for this? We need to ship. Why not build right away and figure it out as we go? I don’t think it comes down to time. My explanation might have been long, but the process itself can be fast. You just spend the time needed.

My feeling is that without that context and goal built in, you might be iterating toward a direction, but not one that was chosen intentionally.

This brings me back to where I started. Our industry is not very patient, and once you start building designs directly to production as the default, the culture and organizational reasons to consider problems, concepts, and intentions start evaporating. We start devaluing the why behind our designs in favor of output.

My worry isn’t the code or the tools themselves. It’s a decline in consideration, and with that, a decline in unique, well-designed products. The question is how we keep that alive even as new tools and technologies emerge.

To me, design was never about what the button is or does, or which medium you work in. It was and is about finding the right problem, the right intent, the right vision. The feature you design and build today should be a considered step toward that vision.

Thank you Charlie Aufmann, Tuhin Kumar, Ramon Marc, Conor Muirhead, Gavin Nelson, Raphael Schaad, Jeff Smith, and Soleio for their comments and discussion on this topic.