Design

When software shipped on a CD, design was the last station on the line. Someone handed over a finished set of screens, and the job was to pick the button colors and draw the icons. The request usually arrived as a single sentence: make this look nice. The money had already changed hands, so whether the buyer learned the program well or opened it twice and forgot about it, the seller's revenue came out the same.

That arithmetic flipped once products moved to the web and phones and started letting people try before paying anything. Signing up takes one click, switching to a competitor costs almost nothing, and a person who cannot work out what to do in the first five minutes simply closes the tab. A closed tab files no complaint and asks for no refund, so it never tells anyone what went wrong.

A particular sentence started showing up in meeting rooms around then: we have more features, so why is everyone using the other one? Line the feature lists up side by side and the comparison goes your way, and yet out of 100 people who signed up, eight came back the next day. Nobody could explain it. Engineering had built what the spec described, product had written down every requirement, and design had drawn what it was given. Everyone had done their part and the result still was not there. What nobody owned was deciding, in advance, what a first-time visitor is trying to do on this screen.

Taking on that question moved design from the end of the line to a seat next to the decision about what gets built at all. And once it moved, the work outgrew any one person. Talking to users, cutting content into pieces and naming them, deciding how a single button responds, writing the wording, setting the rules that keep separate screens from drifting apart — all of it landed inside the same field. That is why the design axis has so many branches under it.

The terms under this axis split fourteen ways. Three questions make the map readable: who does the work (roles), what gets designed (core concept, structure, interaction, visual, content, accessibility), and how the work gets done (process, research and evaluation, design systems, deliverables, tools, standards, ethics).

Roles divide the people, and there are nine seats. What separates them is not drawing skill but how much of the decision each seat owns.

1. A UX designer designs the whole path a person takes toward a goal. The unit of work is the run from signup to first real result, not a single screen.
2. A UI designer turns that path into actual screens — what sits at the top, what gets folded away, how large the type is, how much space goes between things.
3. A product designer carries both ends, from framing the problem to the finished screen. It is the most common title at companies under a hundred people, and it is best read as the two seats above before they have split apart.
4. An interaction designer decides how the product answers a press, a drag, or a drop.
5. A UX researcher plans and runs the work of asking users questions and watching what they do.
6. A UX writer writes the words that live inside the product.
7. A brand designer builds the logo, colors, and type that the company shows to the outside world.
8. A design engineer moves between mockups and code and ships the implementation.
9. A design lead sets the team's direction and quality bar and answers for the outcome.

At a small company, seat 3 absorbs nearly all of the others. As headcount grows, research and writing usually break off first — not because people who can do all three are rare, but because the days look nothing alike. Ask someone to run three user interviews in the morning and draw screens in the afternoon, and the screens with a deadline are what survive.

The "what gets designed" side has six branches. User experience (UX) sits above the rest: everything a person goes through while using the product, which covers the welcome email, the error text, the slow load, and the support reply as much as it covers the screen.

Information architecture (IA) is the skeleton — how content gets divided, what each piece is called, and where it lives. In building terms, it is the stage where you decide how many floors there are and what each floor is named, so when it comes out wrong, no amount of decorating helps anyone find the room they came for. For a document product, the questions sound like this: do documents group into folders or into tags, and does a sharing permission belong to the document or to the folder around it.

Interaction design covers the action and the answer. Press save, see nothing happen, and most people press it again within three seconds, which is how the same document gets saved twice. Gray the button out on the first press and put the word "saving" next to it, and the second press never comes.

Visual design builds hierarchy out of what is visible. Four buttons of the same size and color mean a reader has to read all four; make one of them solid and the rest get skimmed. Picking colors and type looks like taste from the outside, but the purpose is deciding what gets read first.

UX writing designs the wording inside the product. "An error occurred" and "This file is over 20MB and can't be uploaded" report the same event, but the first one sends a person to support and the second one sends them back to shrink the file.

Accessibility (a11y) is about the product still working for someone who cannot see well or cannot use a mouse. It reads as a courtesy extended to a small group, and in practice it is the same barrier that catches a person holding a bag on a crowded train and a person trying to read faint gray text in direct sunlight.

The "how the work gets done" side has seven branches. The design process sets the order of operations: research, narrow the problem, produce several options, test them with users, then fix and ship. UX research methods are the tools pulled out at the first and fourth of those steps — interviews, surveys, and usability tests, where someone uses the screen in front of you and you watch where they get stuck.

A design system is the one agreed source for colors, type sizes, spacing, and parts, so none of it gets decided again on every screen; each reusable part inside it is called a UI component. Let button colors drift screen by screen and three years later the product runs on seventeen shades of gray, with nobody left to ask which one is correct.

The remaining four branches cover the conditions around the work. Design deliverables are what leaves your hands — mockups, prototypes, specifications. Design tools are the software that produces them. Platform guidelines are the rules Apple and Google each publish, which is why the same feature sometimes has to be built differently on iPhone and on Android: a back action that lives in a top-left arrow on one platform lives in a system gesture on the other, and ignoring that makes an app feel foreign on the device it runs on. Dark patterns are designs that push people toward choices against their own interest, such as hiding the cancel button somewhere nobody looks, and this is the one branch on the list named after something to avoid.

The fourteen branches run in a line. Research says what the problem is, information architecture puts up the skeleton, interaction and visuals and wording put flesh on it, the design system packages the result so the next screen can reuse it, and accessibility makes the whole thing work in more situations. Roles divide up according to which stretch of that line a person owns.

"This isn't a UI problem, it's an information architecture problem. Renaming the menu won't make it findable."

Redrawing the screen comes after fixing the skeleton that divides and names the pieces.

"Before we look at mockups, can we go through what came out of the research?"

Agree on the evidence behind the drawing before arguing about which option looks better.

"There's no button like this in the system, so I drew one for this screen. Should it become a component?"

A question about whether this stays a one-off or gets registered as a shared part every other screen uses.

When Pagedeck decided to rebuild its sharing settings screen, the first thing Noa did was read support tickets rather than open a design file. More than 40 tickets a month said a document sent to someone outside the company would not open, and the cause turned out to have nothing to do with where the button sat: permissions lived in two places, on the document and on the folder. Noa and Mia settled where permissions belong before a single screen got drawn.

The review of the first mockups produced three different kinds of comment. Theo pointed at the cost of building it, since changing folder permissions means recalculating every existing document. Mia pointed at scope, since the screen has to work for teams on the free plan too. Noa pointed at the contrast of the gray label, which disappears in bright light. Those are engineering, product, and design concerns in turn, and leaving any one of them out of the room means building the screen twice.

The most common mistake is reading design as the job of making things look good. The visible output is a screen, and most design encountered outside of work is a poster or a logo, so the reading is an easy one to arrive at. But most of the hours go into deciding what to show and what to hide, what order to ask things in, and what words to guide someone with; the screen is that set of decisions made visible. Leave the mistake in place and design gets scheduled for the last two weeks after engineering finishes, by which point the structure can no longer move and the only things left to adjust really are colors and spacing. The request to make it look nice ends up making itself true.

The second mistake is treating design as a matter of taste with no right answer. People do say "I like the one on the left" in reviews, and some of it genuinely is taste. Still, the part that can be settled is wider than it looks. Time to reach the goal, the share of people who finish, the brightness difference between text and background, the size of the area a finger has to hit, whether the same thing is called the same word on every screen — all of that can be measured or checked. Hand the decidable part over to taste anyway and decisions start following whoever holds the most senior title in the room, with no record of why, which means the same argument gets held again from scratch six months later.