"Design isn't just about visuals" gets unanimous approval in any meeting. The support ends when the business gets stuck and someone has to decide who sits at the table. That's when design becomes the team that makes things pretty afterwards, with the decision already made somewhere else.
The visual is the residue
What shows up on screen is the visible part of a chain of decisions that stays hidden: which problem is worth solving, which behavior justifies the priority, which trade-off the team accepts. Color, type and spacing are the layer left over once those questions were answered, or left unanswered.
When the brief jumps straight to "make a modern screen", the visual comes out with no decision tied to it. It looks like design. It's guesswork with a nice finish.
A system with a thesis holds up to "why this shape and not another" with an answer that traces back to the business. Without a thesis, the answer is "because it looked good".
An argument from 1919
The argument is older than digital products. Walter Gropius founded the Bauhaus in 1919, putting woodworking, typography and architecture in the same building. The bet was that form and function come from the same decision, not from two steps where one solves and the other decorates.
"Form follows function" isn't even from the Bauhaus. It's Louis Sullivan's, an American architect, in 1896. The German school turned the idea into a teaching method and into mass production, decades before screens existed.
The same question became a discipline twice more. Cognitive ergonomics, after the war, was about reducing human error in airplane cockpits and power plant control panels. HCI (human-computer interaction), in the 1980s, took the question to computers: understand the user's mental model before designing the interface. Both were born from decisions under risk.
IBM in 1956
Before "tech" existed as an industry, IBM already treated design as a business decision. In 1956, it hired Eliot Noyes to build a design program for the whole company (products, store architecture, visual identity) under the same thesis, with Paul Rand in charge of the brand.
The decision was Thomas Watson Jr.'s, IBM's CEO. His read was that the company's image of competence depended on every touchpoint saying the same thing. In 1973, he put it in a line that became a principle: "good design is good business".
All of this at a company of typewriters and mainframes, with no internet and no apps. The problem was keeping decisions coherent at global scale, and the visual was where that coherence showed.
Where design happens
The heavy lifting has always happened before any tool opens: telling which user behavior is signal and which is noise, choosing the metric the solution needs to move, figuring out which stakeholder objection is territorial and which is technical.
That's decision architecture. Screens, typewriters and buildings are the record of that decision, so someone else can use it without reopening the discussion.
Once the decision has a name, it gets easier to know who should make it: usually whoever studied the problem, not the highest title in the room. Teams do better when each person decides on what they know best.
When design only comes in at the end, the lesson is expensive. Ask for the screen, don't like it, ask for another version, still don't like it, until someone realizes the right question was never asked.
The disappearing screen test
Take any design deliverable and ask: if this screen disappeared tomorrow, which business decision would be left without an owner? If the answer is none, it was decoration with an approval process around it. If it points to a specific bet, it was design, even hidden behind the pixels.
The decision still has to prove itself after launch, in the data and in user behavior, looking at the metric it was trying to move: conversion, retention, time to first value. And a product that works keeps being adjusted, one decision at a time, as usage shows what the hypothesis didn't predict.
Once you see design this way, the fight about taste turns into a fight about criteria. It's more tiring on a Friday afternoon, and it's the kind of fight that kept IBM's program standing for decades after Noyes.
For you, founder: every approved screen carries a business decision, even when it's never said out loud. Naming that decision before asking for the visual usually saves rounds of revisions.
For you, designer: a simple question helps open this conversation: which business decision does this screen represent? It's worth asking early, not only when a request arrives without context.
For you, PM: a brief that arrives as a finished screen left behind a decision the team could have made together. Bringing that decision into the brief usually prevents rework down the line.
For you, tech: the same logic applies to code. Architecture decided without business context is also guesswork, just compiled into production. Understanding the why before implementing saves rework the same way.
