Design Systems
10 min read
How to start a design system without over-engineering it
You do not need a hundred-component library on day one. Here is the minimum viable system that pays for itself immediately.
design systemsstartupsprocess
Product Design
When a product has depth, structure is the feature. How to organize dense functionality so people can actually find and understand it.
Information architecture is the part of design users never notice when it is right and never forgive when it is wrong. For products with real depth, structure is the feature: it is the difference between powerful and overwhelming, between a tool people master and one they abandon.
Here is how to organize dense functionality so people can find it, understand it, and trust that the map will not move under them.
Start here
The most common IA failure is exposing the system's structure to the user. The org chart of your backend, the way your data happens to be shaped, the internal names for things, none of that should be visible in the navigation. Group by the tasks people are trying to accomplish, in the language they use for them.
This is why IA starts with research, not a sitemap. You cannot organize around the user's mental model until you know what it is.
Written by
Jayesh Velossa
Founder & Creative Director
Complex products need hierarchy, and that is not a problem. People will dig through several levels if they trust the map, meaning the structure is consistent and each level's logic is obvious. What breaks trust is unpredictability: the same kind of thing living in two places, or a section whose contents you cannot guess from its label.
Use a small number of stable top-level areas, a predictable second level, and consistent patterns for where a given type of thing lives. Consistency buys you depth.
Name in the user's words
A label that makes sense to your team but not your user is a dead end. Test names with a first-click test before you build. If people cannot guess what is behind a label, the structure has already failed.
IA is cheap to test and expensive to fix after launch. A card sort tells you how users naturally group things. A first-click test tells you whether your labels lead them to the right place. Both take a day and save months, because restructuring a shipped product means migrations, relearning, and eroded trust.
Validate the map on paper, then build it.
Good information architecture is invisible on purpose. Model the user's world, keep the hierarchy predictable, name things in their language, and validate the structure before you commit code. Get it right and depth stops being a burden and becomes the thing that makes your product feel powerful instead of confusing.