A useful design system has three layers: tokens for colour, spacing and type, components built from those tokens, and rules stating which component to use in which situation. On portals and business software the value is not aesthetic: it removes decisions repeated on every new screen and moves accessibility and error states inside the components.
Open a business application that has been alive for three years and count the buttons. Not how many there are, how many kinds there are. Usually four: the original ones, the ones from the module built by a different developer, the ones from the section redone in a hurry before a trade fair, and the ones nobody remembers agreeing to. Same story for date fields, tables and confirmation dialogs.
Nobody decided this. It accumulated, one urgent screen at a time, and everyone learned to live with it. The interesting part is that the users complain about it far less than the budget does.
The cost shows up in the estimates, not on the screen
Every new screen in that application starts with a round of decisions that have already been made four times: which button, which spacing, how errors are shown, what happens while data loads. Each decision is small. Multiplied by every feature for three years, it is the reason a form that should take a day takes three.
The second cost is testing. Four kinds of table means four sets of behaviour to check after any change, and in practice it means nobody checks all four. Bugs then arrive from the section that gets used least, which is also the section nobody wants to touch.
It is not a component library
A design system worth the name has three layers. The tokens come first: colours, spacing scale, type sizes, border radii, the handful of values everything else is built from. Then the components that consume those tokens. Then the usage rules, which are the layer most teams skip: when to use a modal instead of a page, when a confirmation is required, where errors appear in a form, what the primary action of a screen is allowed to be.
Skipping layer one produces a library where every component hardcodes its own grey, so changing the palette becomes a search-and-replace across the codebase. Skipping layer three produces a beautiful library used inconsistently, which looks identical to having no system at all from a distance of two screens.
The rules can be one page. We usually write them as a list of pairs: use this, not that. Use the drawer for editing a single record, the page for anything that involves more than one. Never put a destructive action next to the primary one. Errors go under the field, never only at the top. It is unglamorous documentation and it is the part developers actually read.
Ten components cover most of the work
Portals and business software are mostly forms and tables, which is good news, because the useful surface is small. Button, text field with its label and error, select, date picker, table with sorting and pagination, modal and drawer, notification, empty state, loading placeholder, and a form layout that decides where labels sit. Get those right and the next screen is assembly rather than design.
What is not on that list matters too. Charts, complex filter builders and anything with drag and drop are worth leaving out of the first pass: they are the components most likely to be needed in exactly one place, and building them for a hypothetical second use is how design systems get abandoned.
The states nobody designs
Mockups show the happy path: a table with eight rows of plausible data. Production shows the rest. The table with zero rows, the table with forty thousand, the one where the request failed, the one the user is not allowed to see, the one still loading over a slow connection in a warehouse.
On internal software these are not edge cases, they are half of what people actually look at during a working day. An empty state that explains what to do next, rather than showing a blank rectangle, removes support calls. A permission-denied state that says who to ask removes more. Designing them once inside the component means every screen inherits the answer, including the screens built two years from now by someone who never read the guidelines.
Accessibility comes free if it lives in the component
A visible focus ring, sufficient contrast, a label properly tied to its input, keyboard navigation that follows a sensible order, an error announced to screen readers. Solved inside ten components, these apply to the whole application without anyone thinking about them again. Solved screen by screen, they never get solved, which is the situation most teams discover when accessibility becomes a legal requirement rather than a preference.
How to introduce one into a living project
Not by rewriting. The version of this that fails is the one where a team stops feature work for two months to build a component library, then comes back to find the business has lost interest. The version that works is boring: extract the tokens first, since that is a mechanical change with no visual impact, then build components only as new screens need them, then replace old ones opportunistically whenever a screen is already being touched for another reason.
One thing does need protecting: a component nobody owns drifts back into four buttons within a year. Someone has to be allowed to say no to the fifth variant, and the answer to "we need a slightly different button here" has to be a conversation rather than a new file. That is a process decision, not a design one, and it is the reason most design systems succeed or quietly die.
None of this is about making the software look nicer, though it usually does. It is about making the twentieth screen cost less than the fifth. When we work on interface and design for a long-lived application, that is the number we are trying to move.
