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 focusing this debate on code and tools is reductive.
The bigger question for me is what happens to the way we see designers contributing in the future, especially now with AI and these new tools. How are roles evolving and what do we expect from each of them?
Are designers now engineers, with the same expectations? Are engineers starting to have the same expectations of designers? Will we still have a ‘head of engineering’ and a ‘head of design’, or will it be something like a ‘head of craft’? Titles don’t matter 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 are led in the direction of engineering, designing directly with code, is that a good direction? What do we lose or gain?
Part of the reason this discussion is getting messy is that design means different things to different people. Your view on this depends on what kind of design you do and how you understand design as a practice.
I believe that design comes in many flavors. It is influenced by the person, the domain, the market, the customers. With consumer products, you may need to test ideas quickly because motivations are difficult to predict. In B2B or enterprise you often have more context and you can design from there. Some industries require extreme reliability and clarity. The environment is also important. Stakeholders, customers, corporate culture and your skills as a designer. If you are more visual, you lead with visuals. If you’re strong in code, you might be able to use it sooner.
And for some, design simply means getting the button on the screen and moving on.
So there is a broad domain of software design, containing different tools and methods. The code versus 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 ensure that 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 implementation easier.
Even engineers who work with code all day are moving away from it. They draw architectures, plan systems and reason about trade-offs. While code is where software lives, it is not always where all decisions must be made.
To explain what I mean, I have to start with how I understand design and how I put it into practice.
Designing the problem
First of all, I am not a formally trained designer. It has been self-taught over the past twenty years through hundreds of design projects. So I am not advocating gatekeepers, or a certain “correct” way of designing. But I do think that design is rarely linear. You work at different levels of abstraction and move between them. And while the outcome is the goal, spending time on the journey can improve the outcome.
Through that work I learned to first question the problem and not treat it as an assumption. When I’m 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 discovered is that the most common reason design projects drag or fail is because the problem wasn’t clear. People will not agree on solutions because they have different problems in mind. The solution becomes a compromise of many different problems, rather than a clean solution to one big problem. This only gets worse if you have too many stakeholders.
To address this, I would do two things. Write down the problem as I understand it and ask who the stakeholders are. Then, when I presented solutions to those stakeholders, I would repeat the problem to see if it generated responses. If it were, I would stop and get some space to solve the problem. So what does this have to do with design? This sounds quite businesslike.
You will always have stakeholders, if not colleagues, then customers. You need to understand whether feedback is true because the solution is flawed, or because people disagree about what the problem is. Sometimes you design for the wrong problem. The problem is the first part of the equation. It is the basis of what you are trying to design and build.
At Linear we quickly knew that companies needed projects. So what’s on the roadmap are ‘construction projects’. Everyone agrees that it is necessary. But if you think about it more closely, why do companies organize their work into projects? Why not just work on the next task? What happens if they don’t have projects?
You can delve deeper into project management. There’s a whole discipline behind it, and there are many ways to do it. But if your vision is to build a purpose-built tool for software companies, you start to limit yourself. What do they actually care about?
Simply put, projects are a natural abstraction for companies to manage workflows. They help with responsibility, ownership, cross-team collaboration, predictability and visibility.
Now you may be wondering why you are investigating something that is so basic or well understood. Sometimes that is not necessary. But getting to know the landscape and history gives you orientation. You find assumptions you can question, or you decide which traditions you want to follow.
Most importantly, learning about the problem first will help you decide what to do about it. In which direction the product vision pulls you. What you want to optimize and influence.
At Linear we saw that projects are perhaps the most important work unit. Products are made from it, organizations focus on it and you celebrate when one is shipped. That understanding gave us a direction for what problem we were trying to solve.
Designing the solution
I am thinking of designing the solution in two phases: the conceptual phase and the implementation phase. The conceptual phase is finding the general form that the design will take. While the execution phase builds it out and gets it onto the screen.
Record projects in an issue tracking tool. You can treat them as one large issue with subissues, a folder or label of issues, or its own entity associated with issues. These are conceptual ideas that you can consider without putting anything on the screen. The decision comes down to your understanding of users, the business, and the vision you want. All of these concepts can work, and you can find them in real products.
Because we considered projects important and different from problems, they had to be their own entity, with their own form. A project should have a recognizable form and functionality that communicates status, reasoning, user feedback, prioritization, timing, and connection to larger initiatives. Relegating projects to a label or a loose collection of songs didn’t feel right.
This conceptual phase can take place in words, on paper, in a design tool or in code. It’s about shaping those ideas, trying different directions, and ultimately choosing the direction that best serves the problem and the product vision.
Once I have a direction I believe in, it’s ready for broader feedback. You test the concept by building it.
It is the part closest to the final output. You ensure that the design concept actually works and give it something real. Coding, or working with the material, is essential. And there are times when you gain new insights and have to go back and revisit the problem or concept.
There are several ways to use code in this phase. You can build or ‘sketch’ tools with disposable code. This removes some of the limitations of the production code and makes the process more exploratory. My point is that you may see the execution phase as the real part of the design, but you have already established a foundation of context and trust. When the material fights back, you push with that confidence.
Think of it in LLM terms. The design work you do before is the purpose, context, and prompt you give to the agent to address the problem. During the implementation work, you guide the agent in specific decisions.
After reading all this, you might be thinking: who has time for this? We have to ship. Why not build it right away and figure it out as you go? I don’t think it’s the time. My explanation may have been long, but the process itself can be quick. You just spend the time necessary.
My feeling is that without that built-in context and purpose, you may be moving toward a direction, but not a direction that is deliberately chosen.
This brings me back to where I started. Our industry is not very patient, and once you start building designs straight to production as standard, the cultural and organizational reasons for considering problems, concepts and intentions begin to evaporate. We start to devalue the why behind our designs in favor of the output.
My concern is not the code or the tools themselves. It’s a decrease in consideration, and therefore a decrease in unique, well-designed products. The question is how we can keep that alive, even as new tools and technologies emerge.
For me, design has never been about what the button is or does, or what medium you work with. It was and is about finding the right problem, the right intention, the right vision. The feature you design and build today should be a deliberate step toward that vision.
Thank you to Charlie Aufmann, Tuhin Kumar, Ramon Marc, Conor Muirhead, Gavin Nelson, Raphael Schaad, Jeff Smith, and Soleio for their comments and discussion on this topic.
#Design #code #Linear