How it Works

Designing high-value products in a low-differentiation world

“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 designing interactions, complex visual elements and molding the shape of the applications. AI was great at giving me an MVP getting me 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 you’d be right. But an interface is only the communication layer within a more holistic design strategy intended to align 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 car ‘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 much broader functionality independent of a user, and therefore needs to work differently, through intervention and cueing rather than operating and navigating. Pulling into a parking space, presumably something that both human operated and self-driving cars to, demands very different levels of information (what spaces are available?) and cognition (which space should I choose?) before a user even engages with the communication/interface layer. A human operator can resolve and take action on these factors in real time, while the user of a self-driving car may set parking or drop-off preferences beforehand, removing the deciding/directing process entirely. A highly differentiated product means that the ‘parking experience' is going to look meaningfully different but despite the self-driving car being classically ‘easier to use’, both designs work well because they optimize around the same question:

How do we position the user to capture the most value from the product’s functionality?

It’s the Ecosystem, Stupid

An important aspect of figuring out what works well is understanding the ecosystem of your product, and an increasingly critical for designing digital products in a world where AI is quickly reducing the barrier to feature implementation. A product ecosystem (the way that I think about it at least) is basically just the resources it has available to it, and there’s two categories those resources can fall into:

• Material — hardware/infrastructure, information, connectivity, compute, form factor

• Behavioral — time, attention, cognition, access, routine/cadence

In practice the alignment of these resources make up the friction or texture of a product. For example 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 (allows the bottleneck to drive the experience).

Resource Management

In a low-differentiation environment, it’s critical for product features to seamlessly align with the greater product ecosystem. Despite feature parity, digital products work with varying resources, and depending on a products ecosystem; a feature might be highly adopted in one product, but worsen the experience in another.

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.

So Why is This Important?

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.