How it Works

In an AI world, the cost of design decisions went way up

“Design is not just what it looks like and feels like. Design is how it works.”

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.