The DNA of Product Design

Why using LLMs as our primary design tool could be a breakthrough for product design

Starting Over

Why hire a designer anymore? That’s the question we, as designers, need answer. When you can vibe code a prototype (or even production code) with as much or as little input from a human as you’d like, we need to figure out where designers fit in. To do this we need to be honest with ourselves about what we’re actually doing in this profession and what we want product design to be. It’s an opportunity to refocus on what matters. Most of what has worked, what was best practice and what our process used to be, needs to be thrown out all together. We need to get comfortable with the discomfort of leaving pixels behind; letting go of the hundreds of hours we spent honing Figma skills, because it simply makes no sense to be as hands on as we’ve become accustomed to being.

Now that doesn’t mean that our craft is worthless, in fact I’d argue that design craft is more valuable in an AI world than a Figma one. I’m just suggesting that, in a world where LLMs are our core design tool, the transition that the product design practice needs to make looks far more like a decisive shift rather than a gradual integration. Some people have proposed a softer transition of the designer role to something less hands on and something more of a manager; Designers as orchestrators, facilitators, or context builders/curators, essentially a babysitter of the tool and it’s outputs. I suppose there can be roles like this, but in my opinion this it’s not a design role, and by no means are designers exclusively qualified to take on these tasks (nor would they want to). In order to fully take advantage of LLMs as a core design tool, we need to start over.

Who Authors a Design?

We occasionally need reminding, in between Figma sessions and stakeholder alignment meetings, that the craft and the profession of design isn’t about using tools. Figma fluency and contributing to design systems are some of the exportable skills we practice, but design itself occupies a place between strategy and execution. It’s the decisions and tradeoffs we make, the opinions, perspective and references we bring the judgement, instinct and, dare I say taste (bleh), we cultivate over years and years of practice. Designers utilize all of it to conceptualize how a product works, looks, and feels; how it achieves an objective and how it builds a relationship.

Up until now the authorship of a design was a visual, attributable reflection of a designer’s talent and skill as both a problem solver as well as a visual craftsperson. It was something a designer could truly own from end to end, point to and say that’s mine. What do we own when we’re no longer deciding where to place each pixel where a user will eventually see them. Who authors a design when the robot performs the fabrication? Who authors a design when the design artifact is no longer a reflection of exactly what came out of our brain, but instead what was interpreted and fabricated by an LLM?

Creating a Tool For Designers, Not a Tool as a Designer

I wanted to try to answer some of these questions, and in doing so hopefully create a tool that allows for LLMs to be the designer’s primary tool, maybe not replacing Figma entirely, but heavily reducing it’s dominance in how we spend our time. This tool wouldn’t relegate designers to glorified directors or overseers of the AI tool, but actual authors of the final design. Many AI tools make it feel like human input is a nice to have, where human provided context is welcomed but not required to get something spun up; but a tool built for design needs to embrace and depend on the human to perform the real design work alongside it. Because moving the product design practice looks like working more on formulating the concepts that drive our products and less on the execution of those ideas. Taking the best parts of our executional workflows and applying to our strategic workflows. We have the opportunity to use the best of what AI tools offer us, finding, crunching and structuring data, to develop new design tasks that reflect where we should be putting most of our focus, doing “real design work”.

It’s important to note that despite our best efforts, design is still an inherently messy practice (if you’re doing it right), and it can be difficult to pinpoint where exploration and ideation stops and execution begins because that’s a lot of time how our best insights surface. So a new design tool needs to reflect how designer’s really work which is often in between conceptual and visual spaces.

One Shot is Not Enough

The uncomfortable thing about AI is that it raises the floor dramatically for what constitutes good design. Using a general purpose tool like an LLM means that a hobbyist is using the same tool as a professional. And just like we need to refine what real design work matters, we need to also understand what makes us professional; and it’s not based on what tool you use. I’ll give you an example:

I can shoot a basketball, but I can’t play in the NBA. Playing professional basketball requires a feel for how plays develop, an instinct for real-time decision making and above all consistent high level craft. Design is no different. What makes a professional, and why you need one, is simply because, like a basketball game, our behavior and our environments are constantly changing. A professional basketball player is able to make 99/100 shots, against various opponents, on any court, in front of an arena of 10 people or 10,000 people. They are consistent and reliable experts at their craft regardless of the situational or environmental variables; they instinctually know, through years of practice, how to be successful and professional designers need to exhibit these same qualities. Anyone can hit one shot alone in their driveway, few can do it in an NBA game.

The Importance of Design Math

Designing with a general purpose LLM also means that our interactions are mostly confined to a text box, with some other window (e.g xcode or a browser window) to preview changes. That in itself is a huge change, and presents us with an important task related challenge: where does iteration happen? If I don’t have a canvas on which to brain dump my ideas, and a space to quickly test changes while determining the best execution of a problem, where does that happen? How can I oscillate between strategy and execution?

AI tools offer us a higher fidelity product to work within; rather than an abstraction of a product mocked up in Figma, AI give us the real working thing. The price of that higher fidelity is a canvas. However, that doesn’t mean that we can’t iterate on solutions, it simply means what we iterate on changes.

Figma makes it easy to play with visual and structural changes such as layout and flow. AI makes it easy to iterate on interactions, motion, and more holistically develop how a product feels. We should embrace the layers of a product that AI provides us access to that we didn’t have before, rather than trying to recreate an old process with a new tool.

I would also argue that many experienced designers have a good sense of what solutions will work and not work before putting pixel to canvas, and when you lack a canvas, that experience becomes extremely valuable. There is a very real instinct that designers cultivate over time about what solutions work in different contexts, how to judge whether a solutions is heading in a successful direction and how users might respond to different types of solutions. Being able to process problems and formulate solutions in real time is critical when working at higher fidelities, and in a world where code can be fabricated in minutes. Being able to do the “design math” in your head is a professional skill.

A Really Good Calculator

When we talk about AI, what happens when we replace the word generated with calculated — does it change our perception or approach to AI tools? Yes LLMs generate information for us, but there is a lot of data fetching and crunching that drives those generated results. So what if we used AI as less of a partner that completes whole tasks for us, and more like a calculator that can find and compute anything, so that we can identify problems and solve them faster and more completely?

What that might look like is a designer formulating a hypothesis, such as, “a new interaction model would create a stickier experience”. The AI tool finds and summarizes the relevant information regarding the relationship between conversions and the common interaction models in use. The designer then provides their own analysis and opinion of the summary, along with additional problem specific context, prompting the tool to further evaluate the problem space, much like you would use a calculator to prove a solution one calculation at a time. This recursive exercise puts the designer in control of discovery and solutioning, while the LLM is responsible for what it’s best at, which is fetching and processing information. By the time it comes to fabricate a solution, the LLM has been along for the entire problem solving journey and posses the necessary context to generate a prototype.

Contrast this approach with writing (or let’s face it generating) a long PRD and asking the tool to solve it from 0 to 100%, the later yielding a much more average result that requires a human to digest and understand after the fact because they let the tool interpret the problem instead of driving the interpretation and building context themselves.

Designing Systems Over Design Systems

Over the years, product design has adopted the idea that interfaces are created by assembling a set of subcomponents that determine almost every piece of a product, from UI to motion. We know this is atomic design.

Sticking with the science metaphor, I propose that instead of creating atoms and molecules that make up a design system, we instead create layers of instruction that are processed by the LLM to fabricate the product. Designers will define things like the problem space, hypothesis, interaction models, actions, tokens, principles, artifacts, etc. and the tool will compile the hard and soft values you specify and fabricate the product based on the defined layers.

The designer, alongside ai, is responsible for ideating on elements, aesthetic and interactions individually, and the LLM uses each separate layers to determine the relationships and dependencies between them. For example a card in a carousel might require a different layout and affordances than a card in a stack. Rather than a designer designing two cards, they define interactions (swipe left/right, swipe to scroll) and artifacts (a card), as well as what the user will be intending to do in the product and why. The tool will take these inputs and develop the card artifact appropriate for each use case and interaction type. Should the designer want to iterate on a change, for let’s say the swipe sensitivity — the layers provide a distinct separation of concerns, and the tool can then recalculate the relationship between them and fabricate a revised experience.

In this example, authorship still belongs to the designer. They’re are no longer defining “This is what a card looks like on this screen”; instead they are defining that a card should exist, what it should do the user, the model for it’s use and interaction. I would argue that by spending more time developing the shape, purpose and meaning of a product or interaction is a far more valuable use of a designer’s experience, intuition and craft than trying to get exactly what’s in our heads onto a screen.

You might be reading this thinking that what I’m describing takes aesthetics and visuals out of the hands of the designer — which might be particularly worrying to the ‘taste’ crowd. However it does not, because there’s a layer for that. What you do lose is the responsibility of needing to think through every single variation, state, and use case. Which means you can spend more time iterating on achieving the right visual language and less on the implementation.

The fact is that an LLM can put things on a screen much faster and in higher fidelity that we can, but it’s up to us to figure out what other humans need, how they’ll feel using a product, what resonates, and ultimately what relationship they’ll have with a product.

Introducing Product Design DNA

I’ve created a .md file that does exactly what I’ve described above; it assists a designer through the creation of what I’m calling “DNA” for product design. Like it’s biological counterpart, product design DNA is the logic and instruction of a product’s design; not pixels, not components, but the system of decisions that generates them. It starts with the problem: what’s broken, where the friction is, what forces resist change. Then it defines what exists (entities), what users can do (actions), and what principles govern tradeoffs. The design system comprised of tokens, appearances, interactions flows from that logic. a designer can change a principle, and see the whole product shift. If they add a friction point, gaps surface automatically. AI becomes the primary design tool. The designer thinks in systems and concepts, AI handles fabrication. DNA is the source of truth while code is just a fabrication of it.

Part 1: Problem Space

Before designing anything, you define what you’re solving:

• Foundations — What is this product? What’s its posture—fast, calm, playful, professional?

• Problem Statement — What’s broken today? For whom?

• Friction Map — Where does the pain concentrate? What’s a major friction vs minor annoyance?

• User Forces — What pushes users toward change? What pulls them back?

• Success Criteria — What does “solved” look like? How would you measure it?

• Anti-goals — What are you explicitly not solving?

This isn’t an exercise in creating documentation. What the designer is doing here is building active constraints. Add a feature that doesn’t address a friction point? The LLM flags it. Scope creep into an anti-goal? You get push back.

Part 2: Product Definition

This is where the designer defines what they’re building:

• Schema — What entities exist? A Project, a Task, a User. What properties do they have? What states can they be in? How do they relate?

• Genome — What can users do? Create, delete, assign, archive. What triggers each action? What’s the failure mode? Is it reversible?

• Principles — What values guide decisions when rules conflict? “Clarity over speed” means you sacrifice efficiency for understanding. Principles are ordered by priority thus interact with each other.

Schema and Genome are the nouns and verbs. Principles are the adjectives, they shape how everything behaves.

Part 3: Design System

Now you define how it looks and behaves:

• Tokens — Raw values. Timing (50ms, 200ms, 350ms), spacing (4, 8, 12, 16, 24), colors, typography. The constants. You might not know these right off the bat, but as you design, you’ll want to fine tune certain pieces of the UI.

• Appearances — How each entity looks. A Project Card has an Intent (”compact, utilitarian, like a file in Finder”), a Layout, Tokens used, and Variants for different states.

• Conditions — How context changes behavior. Mobile tightens everything. Offline grays out unavailable actions. Power users skip confirmations.

• Modules — Reusable interaction patterns. Hover-reveal, swipe-to-delete, pull-to-refresh. What triggers them, what tokens they use, what happens when interrupted.

• Examples — A vision for use that traces a user action through all layers.

Connective Tissue

And here’s where everything comes together: every layer of DNA is connected to every other layer. What makes designing in this way a bit different is that once you have used your DNA to fabricate your product, iterating and making changes becomes easier as you can target specific layers and re-fabricate the result.

For example:

• Friction Map → Schema and Genome should address the major frictions

• User Forces (pull-back) → Principles should overcome resistance

• Success Criteria → Examples validate against them

• Schema States → Appearance Variants and Conditions

• Genome (undo model) → Modules (confirmation dialogs, undo toasts)

• Principles → Everything (resolve conflicts, guide ambiguous decisions)

If a designer changes one thing, that change propagates. AI traces them and re-fabricates the product:

> add swipe-to-delete to task rows

Adding swipe-to-delete module.

This may require:
- Appearance: Task Row needs delete affordance
- Schema: Task needs "deleted" state  
- Condition: What happens offline?
- Genome: Delete action exists, but undo model is "destructive"—
  swipe-to-delete implies reversible. Conflict?

Walk through each?

Here we’re leveraging the strengths of AI, to exhaustively fetch various pieces of information, take direction and then formulate and distribute a result to each part of our system. The DNA remains the source of truth and the fabricated code reflects how the designer shapes the system. Of course a designer can also change code directly, but the AI will make sure to keep everything synced.

Changing a Designer’s Tasks, Not Their Job

DNA represents a fundamental shift in the focus and tasks of a product designer’s work. Figma makes pixels malleable. You can drag, adjust, tweak—see immediately what 8px vs 16px feels like. Iteration is fast because the medium is visible.

But the capital D Design, the decisions that drive how a product is used, what it feels like and what it means, has always been invisible:

• Why does this product exist?

• What friction is it relieving?

• What tradeoffs are we making?

• What principles govern when rules conflict?

• How do entities relate?

• What does success look like?

These decisions happen in docs, in meetings, in designers’ heads. They’re hard to see, hard to share, hard to iterate on. So they calcify early or stay fuzzy forever.

DNA makes the invisible visible.

DNA is a canvas and artifact you can look at, question, and change. The principles aren’t just a model or north star, they’re a ranked list you can reorder and see what breaks. The schema isn’t a data model, it’s the conceptual foundation you can reshape.

DNA provides a designer the canvas to iterate on capital ‘D’ design tasks just like they would work on lower level design tasks. It turns the more abstract and least tangible parts of the product design craft into visible, malleable inputs.

What that means is that designers spend their time differently. Designers will need to spend more time on principles, goals, game-feel, problem definition, intent and constraints the same way they would work on layout, color, type and motion. And DNA does this is a way that rooted in the practice of product design specifically, designed to prioritize details and specifics, and requests a design-focused vocabulary, context, inputs and references. DNA places focus on design first followed by product vs. creating the product and backing into a design. This is a tool created for product designers, not PMs, not engineers.

Of course using DNA and allowing AI to fabricate a product based on a designer’s system means that designers don’t have full and total control over what goes where, but I would argue that in a world where our tools give us deeper control over shaping concepts, we don’t need it. If we spend 100% of our time of Real Design Work, rather than spending 75% on getting things onto a screen, we end up doing more design at a deeper more meaningful level, more fully utilizing all of the true design skills and experience we’ve gained.

You can start building and designing with your own DNA by downloading the design-dna skill.

npx skills add tylercecchi/product-design-skills --skill design-dna   

It’s by no means a complete solution, but it’s a starting point toward building and utilizing new tools that harden the fuzzy, but high impact aspects of the design process that designers would benefit from having deeper access to.

Update:

I made an update to this skill. In the previous version, creating a DNA required a designer to develop at least some information for each layer before any code fabrication happened. While it’s very helpful to define your problem space as well as possible upfront, it puts too much distance between starting a project and beginning to iterate, discover and design.

The way this skill now works is a designer will still provide some foundational info for their product (form factor, posture, libraries, etc), and can then iterate on a sample html page, or jump straight to creating code. The DNA layers will begin blank, and will update as the designer iterates on their design. For example, you might want to add a header that shows a users account balance with the ability to trigger a drop-down showing a behind-the-scenes formula so the user can understand how their balance is being calculated. The skill will subdivide that prompt into parts and add them to the appropriate DNA layers [header —> schema, click balance drop-down —> module, etc]. The skill then recalculates the relationships between each layer and fabricates the update of the account balance header, as well as any downstream or tangential changes that might arise due to the updated DNA.

As you’re iterating it helps to not only provide information for what you want to change, but also why you want to change/add it. This help develop your problem space layers which are fundamental to building the context of your product and fabrication of your code.