Elevating Design: Beyond Code and Tools

The relationship between design and code is a persistent topic of discussion, frequently resurfacing in the industry. I've previously explored how 'design is a search, not a pipeline,' the significant influence of tools on what feels achievable, and the pitfalls of premature constraints. I remain skeptical of the industry's push for grand unification, which often reduces complex design processes to mere code, mistakenly labeled as progress.

Recent debates primarily focus on whether designers should code, if code is the optimal medium for design, or how code supposedly 'represents the truth' of a design. However, I believe centering this discussion solely on code and specific tools is overly simplistic.

To me, the more critical question is how we envision designers contributing in the future, particularly with the advent of AI and new powerful tools. How will professional roles evolve, and what new expectations will we place on them? Will designers effectively become engineers, subject to the same demands? Will engineers, in turn, hold similar expectations of designers? Will traditional roles like 'Head of Engineering' and 'Head of Design' eventually merge into something like a 'Head of Craft'? While titles themselves may not be paramount, these questions are vital as they highlight our core values and understanding of how work gets done.

A practical concern also arises: if designers are increasingly directed towards direct coding, what are the potential gains and losses?

Part of the complexity in this discussion stems from the varied interpretations of 'design.' Its meaning is deeply influenced by the individual designer, the domain, market conditions, and customer needs. In consumer product development, rapid iteration and testing are often crucial due to the unpredictable nature of user motivations. Conversely, B2B or enterprise environments often provide more context, allowing for design based on established parameters. Some industries demand extreme reliability and clarity above all. The operational environment—stakeholders, clients, company culture, and the designer's personal skill set—also plays a significant role. A visually-oriented designer might lead with visuals, while someone proficient in code might integrate it earlier. For others, design simply means getting a functional button on the screen and moving forward.

The broad spectrum of software design encompasses diverse tools and methodologies. The polarized 'code vs. no-code' argument often misses the underlying point and fuels unnecessary division. My intention is to elevate this conversation beyond mere tools and ensure they don't dictate the future of design. We must avoid devaluing conceptual and divergent thinking simply because new tools streamline execution. Even engineers, who spend their days immersed in code, regularly step back to sketch architectures, plan systems, and evaluate tradeoffs. While code is the ultimate home of software, it isn't always the optimal place for every decision.

To elaborate, I must first share my personal understanding and approach to design. I am not a formally trained designer; my expertise has been honed through hundreds of self-taught design projects over two decades. Therefore, I am not advocating for gatekeeping or a singular 'correct' design methodology. However, I firmly believe that design is rarely a linear process. It involves moving between different levels of abstraction, and while the end outcome is the goal, investing in the journey significantly enhances the final product.

Designing the Problem

Through this extensive experience, I learned to first question the problem itself, rather than treating it as a given. When presented with a task, my initial questions are: 'Is this a genuine problem?' 'What if we don't pursue this?' 'Who defined this problem?' This might sound philosophical, but I've consistently found that the most common reasons for design projects to stall or fail are unclear problem definitions. If stakeholders have different problems in mind, they will never align on a solution. The resulting 'solution' becomes a compromise attempting to address multiple disparate issues, rather than a focused answer to one core problem. This complexity is amplified with a larger number of stakeholders.

To counter this, I adopted a two-pronged approach: first, I would articulate the problem as I understood it, and identify all relevant stakeholders. Then, when presenting potential solutions, I would reiterate the defined problem to gauge reactions. If discrepancies arose, I would pause the discussion until alignment on the core problem was achieved. One might ask, what does this 'corporate-sounding' approach have to do with design? In any project, you will always have stakeholders—be they colleagues or customers. It's crucial to discern whether feedback indicates a flawed solution or a fundamental disagreement about the problem itself. Sometimes, you might unknowingly be designing for the wrong problem. Understanding the problem is the foundational first step; it's the bedrock upon which you design and build.

At Linear, we quickly recognized the necessity of 'projects' for companies. While the roadmap item might simply read 'build projects,' it prompts a deeper inquiry: Why do companies organize work into projects? Why not just proceed with the next task? What are the consequences of not having projects? Project management is an extensive discipline with numerous methodologies. However, when building a specialized tool for software companies, the focus narrows: what truly matters to them? Simply put, projects serve as a natural abstraction for companies to manage streams of work, facilitating accountability, ownership, cross-team collaboration, predictability, and visibility. One might question the need to research something seemingly so basic or well-understood. While not always necessary, exploring the landscape and history provides crucial orientation. It uncovers assumptions ripe for challenge and helps decide which established traditions to follow. Crucially, understanding the problem first guides product vision, influencing what aspects to optimize and how to steer development. At Linear, this insight led us to view projects as perhaps the most vital unit of work—products are built from them, organizations revolve around them, and their completion is celebrated. This understanding provided clear direction for the problem we aimed to solve.

Designing the Solution

I conceptualize designing the solution as occurring in two distinct stages: the conceptual stage and the execution stage. The conceptual stage involves identifying the overarching form the design will take, while the execution stage focuses on building it out and bringing it to life on screen. Consider projects within an issue tracking tool: they could be treated as a large issue with sub-issues, a folder or label for issues, or a distinct entity linked to issues. These are conceptual ideas that can be explored without screen mockups. The decision hinges on your understanding of users, the company, and your desired product vision. All these concepts are viable and can be observed in various real-world products.

Given our belief that projects were significant and distinct from individual issues, they necessitated their own entity and form. A project, in our view, required a recognizable structure and functionality that clearly communicated its status, rationale, user feedback, prioritization, timeline, and connection to broader initiatives. Demoting projects to a mere label or a loose collection of issues felt inadequate. This conceptual stage might involve discussions, sketches on paper, work within a design tool, or even preliminary code. Its essence is to give shape to ideas, explore different directions, and ultimately select the one that best serves the defined problem and product vision. Once a direction feels robust and convincing, it's ready for broader feedback. The concept is then tested through its construction.

This is the stage closest to the final output, where the design concept is actualized and shaped into a tangible product. Working directly with code, or 'the material,' is fundamental here. It's also a phase where new insights can emerge, occasionally necessitating a return to reconsider the initial problem or concept. There are various ways to leverage code at this point. One can build specialized tools or 'sketch' with disposable code, which removes the constraints of production-ready code and fosters a more exploratory process. My point is that while the execution stage might seem like the 'real' part of design, a strong foundation of context and confidence has already been established. When challenges arise from the material, you approach them with that inherent confidence. To frame this in terms of Large Language Models (LLMs): the design work performed beforehand represents the goal, context, and prompt built for the agent to address the problem. The execution work then involves guiding the agent through specific decisions.

After reading all this, one might wonder about the time commitment. 'Who has time for this? We need to ship. Why not just build and iterate?' I don't believe it's a matter of time. While my explanation might be lengthy, the process itself can be quite rapid. It's about allocating the necessary time. My concern is that without this built-in context and clear goal, development might lead to iteration, but not necessarily in a direction that was intentionally chosen.

This brings me back to my initial premise. Our industry often lacks patience. When building designs directly into production becomes the default approach, the cultural and organizational incentives to thoroughly consider problems, concepts, and intentions begin to erode. We risk devaluing the 'why' behind our designs in favor of mere output. My apprehension isn't directed at code or the tools themselves. Rather, it's about a potential decline in thoughtful consideration, which could, in turn, lead to a decline in truly unique and well-designed products. The challenge lies in sustaining this critical thinking and intentionality, even as new tools and technologies continuously emerge. For me, design has never been about the specific function or appearance of a button, or the medium used. It has always been, and remains, about identifying the correct problem, establishing the right intent, and formulating a clear vision. Every feature designed and built today should represent a deliberate step toward realizing that overarching vision.