AI Before Design

Anyone developing an app or a program decides early on how it should look and how it should be used. This shaping is called design: buttons, menus, screens, workflows. For a long time, the order was clear. First the product was designed, then technology was added, often including self-learning software. AI Before Design reverses this order. First, a team examines what self-learning software can actually do well in this particular case and where it makes mistakes. Only from this answer does the design of the interface then emerge.

Why bolted-on AI features often fail

The approach is a reaction to a common problem. In recent years, many companies have taken finished products and placed a chatbot next to them. The result was often a button with a small star icon that nobody used. The feature did not match what users actually wanted to do at that point.

The reason lies in a difference from classic software. A normal calculator always delivers the same result for the same input. A language model, meaning a program that continues texts, answers the same question a little differently each time. Sometimes it is also simply wrong. An interface designed for reliable answers breaks down under such conditions.

That is why proponents of the approach argue: the uncertainty of the technology must flow into the design from the very beginning. It cannot be hidden afterward behind a nice interface. Anyone who tries anyway ends up building a product that looks good in testing and disappoints in everyday use.

From prototype to interface

In practice, such a project begins with experiments rather than sketches. The team feeds a model with real data from the intended use case. Then it measures how often the answers are usable. A typical question is: Is the hit rate at 95 percent, or closer to 70?

This number determines the design. At 95 percent, the software can handle a task on its own and simply display the result. At 70 percent, the design must leave control with the human. Then the system suggests three options, and the user chooses. Both variants are good products, but they look completely different.

A comparison helps: an architect does not design a house before knowing the building ground. You build differently on rock than on sand. The model’s capabilities are the building ground for the interface. An important distinction applies here. AI Before Design does not mean that design becomes unimportant. It merely means that design comes later in the process — and stands on firmer ground because of it.

The approach in products and job postings

The principle becomes visible wherever AI features do not overwhelm the user. Writing programs mark suggestions in gray text until you accept them with the tab key. Programming tools display suggested code for review instead of simply inserting it. These patterns are no coincidence, but a direct response to the error rate of the models.

In business news, the term usually appears in connection with organizational changes within companies. Firms report that designers and developers now work together on early experiments instead of one after another. Job postings often contain phrases like prototyping with models as part of the design process.

A common misunderstanding is to interpret the approach as a call to build AI into everything. The opposite is meant. Anyone who tests early often notices that a model is too unreliable for a particular task. The result is a product built entirely without that feature — and that counts as a success of the method.