We all know it. Some of us repeat it as doctrine. This single quote has been so influential on the software design practice that it’s shaped the entire career arc of product designers for the last 23 years. Many people interpret this quote as saying something like ‘form follows function’, and they use it as a vehicle to separate look and feel from functionality; that a piece of software doesn’t have to look good so long that it delivers for users. But we know that’s not true, and very few of us want to design that way.

If you break down this statement, you have two sides of an equation. On the one side it’s pretty self explanatory: visuals and aesthetics, haptics and motion; i.e what a product looks and feels like. The other side is a little more nuanced. How a product works can be interpreted as what it does for a user or the manner in which it performs a job. We tend to look at usability metrics and how intuitive a product seems as a measure of whether or not it works well. We also like to consult the encyclopedia of usability principles and “best practice” ( ← which is a made up thing btw) to determine if we’re building a good, well-functioning product.

Part of the reason I think designers, product managers, stakeholders, etc. read this quote and hear “aesthetics come second” is because functionality has traditionally been the largest hurdle. It’s arguably the most resource intensive, time consuming and expensive aspect of building. Just getting a product or feature up and running, so that you can test, learn and refine, is the core premise of MVP-driven development. When developing a feature, it either works or it doesn’t — you have it or you don’t — whereas with aesthetics there are often degrees of correct.

This is all pre-AI of course.

I recently decided to put in some focused practice using just an LLM chat as my primary (and only) design tool. I’d go to Mobbin, pick a few apps and try to build them from scratch using only prompts, no references. As a self-taught designer, copying websites and apps in Figma is how I learned to design, and to this day I think re-creation is a helpful exercise to understand technical craft. What I found was that Claude Code is exceptionally good at adding raw features (I can’t tell you how many times someone has told me about how they ran out of features to build into their products). Most things I wanted to implement were up and running in fewer than 3 prompts. I found that where I spent 80% of my time was building interactions and complex visual elements. AI was great at giving me an MVP and even suggesting what more we could build next. It makes sense given AI is principally designed to generate something from nothing, to go from 0 to 1, but in instances where there are degrees of correct it requires more direction. In my experience, what an LLM generates for you is, in a lot of ways, a foil to design against.

So I took two things from this exercise, one is that it’s much cheaper to build MVP features, but perhaps more expensive to design them. The other is that simply having a feature is no longer a moat or a point of differentiation. AI just puts more fuel on top of what is already a copycat industry. Yes design does help in differentiating a product, but according to our Jobs quote, aesthetics are just one side of the equation — if we’re to create interesting, differentiated, high-value products, its’s important that we understand what it means when we talk about how our products work.

Here’s what I think it means:

How a product works is what happens at the intersection of how a product functions independent of user input, and how a human uses the product to accomplish a task.

You might be thinking, ‘yeah duh, that’s what an interface is’, and yes the interface is the communication layer within a holistic design strategy that aligns how product function with task in the most effective, valuable way possible. For example, an engine powers a car — it doesn’t tell the car where to go or how fast to work, it simply turns fuel into motion. A vehicle works by pressing the accelerator/brakes in tandem with a steering wheel to direct the vehicle from point A to B. Now contrast this with a self-driving car, which monitors traffic conditions through sensors and positioning systems, instead of a wheel and pedals. The self-driving vehicle itself has broader functionality independent of a user and therefor works differently, by intervening and cueing rather than operating and navigating.

The driving interface accounts not just for the user’s experience; it creates a process by which the the most value is made consumable by the user via design.

If we look at digital products, what is our engine and what is our steering system? Information passes through the product and where it surfaces and is made available to the user. The steering system is the interaction layer on top of it. Just as a driver is the point of intersection between an engine and steering system, our users (or agents) are the same intersection point of information and behavior.

But we don’t just want to design products that work. We need products that work flawlessly. So how can we better understand what a great product looks like vs. something that’s just good enough? I think it’s how well a product or feature aligns with it’s ecosystem.

There’s two general sets of resources that a product has available to it: material resources like information, connectivity, compute, form factor; and behavioral resources like time, attention, cognition and access. A user of a b2b sales prospecting product may be seeing a high volume of leads [abundance of information] but a tight window of time to qualify them [lack of time]. A customer of a beauty retailer might be shopping for a very specific SKU [abundance of attention], but not know the exact product name among a large catalogue of options [lack of information]. A well designed product is one that identifies a bottleneck in the experience and either removes it or optimizes for it.

So what happens when features are cheap and every software maker has the ability to implement any feature into their product? Why would a feature drive high adoption in one product, but worsen the experience in another? It comes down to understanding and optimizing the ecosystem that exists in your product.

To illustrate how ecosystem affects the value of a feature, imagine two financial planning products that both want to add an agent chat feature. Both products pull the same bank data and the agents have access to similar tooling. The objective of both products is to help users build net worth.

Product X is goal-first. Users name what they’re saving for, and the product allocates funds across investment accounts to get them there.

Product Y on the other hand is behavior-first. It analyzes current spending, then offers budgets with investment allocations built in.

Both products share the same bottleneck: investable funds. Product X benefits from having an abundance of context around things like time horizon and costs of goal items. Product Y benefits from the user’s attention to day-to-day spending. Whether this feature works well within a product depends on whether the agent feature either helps the user invest more money, or make their existing allocation go farther.

In Product X, a user might ask the agent to build a budget that frees up more money to invest, shortening the time it takes to hit their goal. The agent is able to leverage bank/spending data it already has access to in order to build the user’s awareness of what their day-to-day budgeting would look like with more intensive saving and investing. It directly addresses the bottleneck.

In Product Y, a user might give the agent a fixed time horizon or goal, like buying a $30,000 car next year. This added context could be used to be smarter about picking certain investment instruments (theoretically helping make more of the user’s cash) or highlight which budgets would help them achieve that goal. However in either of these examples, the agent is simply reinforcing existing functionality; it’s not adding to or extending native functionality that brings a user meaningfully closer to a task.

Despite being fundamentally equivalent features, the difference in product function and ecosystem give an undifferentiated feature significantly different meaning, and ultimately value.

We talk a lot about judgement and the importance of being able to communicate what to build and why as an important mechanism in a world where AI can build almost any software. But I would argue that equally important is an understanding of what already exists; what resources does my product and user have in abundance, what do they lack? Does a feature integrate functionality and task in a way that is a value-add?

These aren’t new questions or new ideas, after all this whole piece is inspired by a statement Steve Jobs made more than two decades ago, but if the cost of code is in fact going to go down, it’s a matter of not what we build for our users but how what we build create value that will differentiate well-designed products that lead the market from the copies trying to keep up.

Advertising was built on a simple premise — art serving commerce. Turns out what drives our economy is also an effective lens into who we are, which is one of the most fascinating synergies. The one thing that I think some of the best ads achieve is that they surprise us in some way. They stick with us because they introduce us to something new; a new way of thinking about a product, of using language, a perspective of culture or our society, or even a new way of thinking about what an ad can be. They’re often reflective of ourselves; what we expect, assume or think we know, and challenge those things. As a whole, creating good ads, like creating art, is a very human exercise.

If I were to ask you what your top 3 favorite (or most memorable) ads were, chances are the ones you’d choose are multiple decades old. Creating these insightful, human communication concepts is not very efficient nor repeatable; two attributes that conflict enormously with how we approach business today. And perhaps the most incongruent aspect is that they often don't create a trove of data to analyze, meaning even if you hit on a great idea you may never know exactly why it was successful.

Much has already been written about the ‘blanding’ of corporate creative so I won’t go into that too much. Needless to say there’s been an effort to de-risk and optimize products and communications; to let the data that iterative development produces guide us towards our next actions. We rely on ‘best practice’, because that’s what we have the most data to support. This new process favors intentionally safe changes that can be tweaked without disruption until made effective enough to make a difference. If you think about it, we’ve been letting computers dictate our decision making for a while now, long before ChatGPT. It’s just that humans used to be needed to make the deck explaining the rationale behind the decisions, but now the computer can make the deck too.

Now, another important thing happened that went hand-in-hand with the blanding movement, and that is we moved everything onto platforms. Shopping, family/friends, education, work, etc. Just about everything was platformed and mountains of data was captured from users; who they were, what they do, etc. The more we know about users, the more efficient and optimized the product can be to deliver as much ‘value’ as possible. Platforming’s most consequential impact was that, unlike advertising where a human insight was needed to connect an idea with a desired behavior, platforms didn’t have to understand what customers were thinking because they create a steady stream of data on what they were actually doing.

This was a significant collapse in how we thought about the relationship of art and commerce. The art side of that tandem, where insights about people was how products could connect on a human/cultural level and hopefully drive behavior, became less and less recognizable. Sure there was still some image-making or copywriting involved, and it was generally created by people with a B.F.A using design tools, but we decided in order to best serve commerce, the objective of these communications wasn’t to influence behavior or empower a consumer to make a choice, but to create quality signals. The real behavioral shifts came from ‘nudges’, like serving consumers product and copy in algorithmically determined spaces or fabricating senses of urgency. The platform became the mechanism for influencing behavior via a feedback loop designed to reinforce existing behaviors. The platform serves as both the product and the ad, and value moved from being exchanged to being extracted.

The insights that made products human became less and less part of the equation as platforms prioritized collecting and optimizing human, but machine-readable, behavior like clicks, data, efficiency, ironically at the expense of actually understanding people.

Human-Shaped Software

I think a lot about where AI fits into our everyday, and I keep coming back to the idea that a lot of the AI anxiety that we collectively have is because, for a long time now, we’ve actually been building software for machines and selling them to people; and we’re finally at a time now where machines can be the users. Sure, as product designers we spend a lot of time trying to make software human-shaped and usable, but in reality a computer is much better suited to completing many of the tasks our software is created to facilitate.

This doesn’t mean that software isn’t for humans at all. However it does mean that we need to reconsider what using software means to people. Humans no longer need to be users of software, instead they can be consumers of it; and that distinction is important. Using software often means that the value comes from the output or result, but consuming software means the value comes from the experience, how it makes you think and feel, and how those feelings impact your behavior. For example, we use an instruction manual, but we consume a magazine. Different in purpose but equally valuable to a human.

Most of our modern design approach stems from usability practices. We design to reduce friction, for more intuitive UI, collect accurate data, etc. We operate under the assumption that everything is a task and that software must reduce the time and effort necessary to complete those tasks. We’ve determined that successful products are those that are easy to use, whereby easy to use often means ‘frictionless’. We’ve even built a whole industry worth of tools and methodologies dedicated to measuring usability so we know exactly where and what to design; which happens to be the engine that AI can run on to perform design tasks. It’s very possible that large swaths of designing software products, as we’ve thought about it over the past 20 years, is a solved problem.

And that’s a really great thing.

Software For Humans

In a world where AI is the user, and potentially a designer of software, we need to take the idea that digital products are meant to be consumed rather than used a lot more seriously. This means breaking away from the task-based ‘jobs to be done’ style of designing products, where efficiency equates to effectiveness. It means we need to think beyond software that simply smooths out a problem, and toward software that satisfies a human need. Consuming software doesn’t mean that the user has a passive relationship with the product, such as streaming a movie; it also doesn’t mean that the product can’t be a tool for some task. After all software is software and designing software to be ‘consumable’ doesn’t change what it is. Consumable software is rather a design philosophy where the purpose of a product is shaped by knowing something about people. Rather than creating solutions to problems we want to design experiences for insights.

For example there’s a lot of problems with living abroad and connecting with friends and family. Aside from the time differences and lack of physical presence, not having the ability to be present leads to feeling guilty and stressed about not maintaining relationships the way we used to. These are all tangible, human problems that software might be able to help us solve. But they are problems without a unifying insight or something that attaches a product to a human. An AI agent can reach out to our friends, while we’re asleep in another timezone, and check in to help relieve the stress of unmaintained relationships. Sure the problem that we’re looking to solve is rooted in the human experience, but the solution does not carry that humanity through.

However what could a product experience look like if we instead looked at designing for the user to spend time with the experience, rather than tactically solving a problem. There’s this phenomenon where even though you may not have seen a friend for a long time when you finally catch up with them it feels like no time has passed. It’s a distinctly human insight, one that evokes a feeling, that we could design a solution experience around. If instead of our product trying to bridge the gap in communication between friends under a given circumstance, what if our product’s primary objective was to create it’s own version of the feels-like-yesterday phenomenon. This might involve contextualizing communications around memories, shared interests, times of year or upcoming events; things that distract and obscure the things that might weaken a relationship like distance or the time between your last phone call and instead celebrate the history and rituals of a friendship.

Pointing Ourselves Out To Us

As humans, we’ll always want to buy products, consume services and accomplish goals, and in the world we live in all of those things involve interacting with software in some way; software remains an effective communication layer, especially in an agentic world. If the agentic vision comes to fruition, agents will understand our intent and execute actions on that intent. Humans will likely perform a single iteration for every 100 interaction an agent performs on their behalf. Many of the commercial spaces that humans inhabit online today will either be inhabited by agents, or just cease to exist. Human intent, how we think about the world will carry much, much more weight given that agentic actions (compute) will be spent on executing on it. In a world where humans are spending less time participating in the value extraction loop of current platforms, how will they be reached, and more importantly how will their behavior be understood, influenced and shaped? What will resonate with people?

I began this article talking about how great advertising’s ability to point ourselves out to us is what makes it memorable, and I think it’s possible that people will come to expect something similar with software. It’s becoming increasingly clear that as agents perform many of the rote, taxing, unpleasant digital tasks, we as humans may have more energy and time for experiences that are less efficient, but more emotionally and intellectually stimulating. It’s possible that the rules of product design, things like friction is failure and speed is success, will become usurped by rules that prioritize treating the user like a human rather than a machine. When AI handles the "using" of products, humans will be left with the "experiencing" piece, and that creates both a necessity and an opportunity to design software that connects with people on a human level the way the best creative always has.

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.