Your UI can look consistent and still leave users guessing where to click next.
I’ve worked on SaaS products where the design system was already in good shape. The team had reusable components, defined design tokens, and clear rules for building new screens. Everyone used the same UI patterns, and the interface looked consistent across the product. Still, users struggled to find what they needed.
They couldn't figure out where certain features lived. Some tasks took too many steps. Support kept getting questions about things that seemed obvious to the team.
So, what was going on?
I've noticed this pattern in products that have been growing for years. Teams add features, adjust workflows for enterprise clients, and respond to new customer requests. Eventually, the product becomes harder to navigate, even when the UI looks perfectly fine.
The first instinct is often to clean up the interface or build a new design system. Sometimes, that helps. But I'd first want to know what's actually making the product difficult to use. A consistent UI doesn't automatically make a product easy to understand.
A design system helps teams build interfaces faster and keep things consistent. Information architecture helps users find what they need and understand how the product works. Both matter, but they solve different problems.
A consistent UI doesn't guarantee a good user experience
A design system gives designers and developers a shared set of components, design tokens, and rules. Instead of building every button, form, or table from scratch, the team can reuse existing elements.
This saves time, reduces visual errors, and makes new features easier to build. For a growing B2B SaaS product with dozens of screens and different user roles, that's a big advantage. But consistent components don't tell you if users can find a feature or understand what to do next.
Imagine a CRM where every button looks the same, all tables follow the same layout, and forms work consistently across modules. The UI looks great. Yet users might have to open three sections to find one setting. Two pages might contain similar information, with no clear explanation of how they differ. The same action might appear in several places, while another is buried deep in the navigation. The interface may look consistent to the team, while for users getting things done is still harder than it should be.
I've seen teams improve their design systems and speed up development without reducing the number of support tickets about navigation. The new components worked well, but nobody had revisited how the product was organized. That's an important distinction to make before investing time and money in a redesign.
I usually look at three areas:
- UI consistency - do elements look and behave the same way across the product?
- Design system - does the team have shared components and clear rules for using them?
- Information architecture - are features and information organized in a way that makes sense to users?
These areas are connected, but each needs a different kind of attention.
Sometimes, the problem is bigger than the UI change
I remember a project where a client asked us to remove the dividers between sections on a screen. It was a very specific request about one visual element. We removed them, but the client still wasn't happy with the result.
After looking at the screen again, we could see the bigger issue. There was too much information competing for attention. Everything seemed equally important, and users had to figure out where to look first. The dividers were just the thing the client had noticed.
This happens quite often. People who work with a product every day know it inside out. They know where the features are, how the workflows work, and which details matter. But knowing the product so well can make it hard to see it through a new user's eyes.
A client might ask to change a color, move a button, or remove a visual element. Those requests are worth considering, but they don't always explain what's causing the problem.
When I look at a screen like this, I want to understand what the user is trying to do. Is all this information necessary at this point? Which details help users make a decision? Are several actions competing for attention? Could we simplify the workflow or move some information elsewhere?
Sometimes, a small visual change is enough. Other times, we need to rethink the screen's structure. The important part is understanding what the change should achieve before deciding how to make it.
Information architecture becomes harder to manage as a product grows
Early versions of a SaaS product are usually easier to use. There are fewer features, fewer user roles, and fewer workflows to think about. Then the product grows.
Sales asks for features that enterprise customers need. Product teams introduce new workflows. Different teams build separate modules. Permissions become more complex, and older features stay because customers still rely on them.
Each change may make sense on its own. Over time, though, the product can become a collection of features that don't fit together as well as they should.
Users may find the same information in several places. Related features can sit in separate sections. Even a simple task can require switching between screens and remembering details along the way.
Information architecture helps solve these problems by organizing features and pages in a clear way. It shows how different parts of the product fit together and helps users find what they need and know where to go next.
This gets especially tricky in enterprise UX. An administrator, a manager, and an employee might all use the same platform, but their responsibilities and permissions are different. They may need different views of the same information and different ways to complete related tasks. The challenge is to support those needs without making the entire product harder to understand.
A design system helps the team build these screens consistently. Information architecture helps the team decide how the screens should fit together.
A clean interface can still feel complicated
Notion is a good example of this. Its interface has a recognizable visual style, and its building blocks give users plenty of ways to organize their work.
At the same time, the number of features and customization options can feel overwhelming, especially for people who are still figuring out how to use the product.
A clean UI makes individual elements easier to scan. It doesn't necessarily make the whole product easier to understand.
The same thing happens in SaaS products. A dashboard can look polished but leave users unsure which metrics matter most. A CRM can offer several ways to reach the same customer record. An ERP can have all the right settings, but finding the one you need takes too long.
When I see these problems, I look at how users move through the product. If people keep opening the wrong section, I'd check the navigation labels and how features are grouped. If they switch between two pages over and over, I'd look at why the information is split between them. If they complete the same task through several different routes, I'd want to understand whether those routes serve different needs.
An information architecture audit can help answer these questions. It looks at how the product is organized and whether that structure works for the people using it. The outcome might be simpler navigation, a better grouping of features, a different page structure, or fewer steps in a common workflow.
These changes can make a real difference to SaaS UX, even when the existing UI components are already well designed.
A component library is a starting point
Tools like shadcn/ui and Radix UI make building interfaces much easier. They give teams reusable components and established interaction patterns, so developers don't have to start from the very beginning.
I think they're great foundations for many products. But having a library of components doesn't answer every design question.
- When should you use a particular component?
- Does the interaction make sense for the task?
- How should different patterns work together?
- What happens when a new feature introduces another user role or a more complicated workflow?
These decisions need their own rules.
For example, a team might use the same dropdown component across the entire product. That keeps the UI consistent. But if a dropdown contains dozens of options, finding the right one can still be frustrating. The component works as expected. The design decision might need another look.
A design system should give the team guidance on when and how to use its components. It should help designers and developers make decisions that work across the product, rather than just giving them a set of ready-made elements.
The same issue comes up with AI-generated UI. AI coding tools can produce polished screens surprisingly quickly. You can get buttons, tables, cards, and forms that look consistent enough to demonstrate a product idea.
The problems often show up when the team starts building on that work. Developers might find duplicated code, components that are difficult to reuse, or patterns that don't fit the existing product architecture. Some of the interface may need to be rebuilt before the team can maintain it properly.
Even when the code is reusable, the team still needs clear rules for how components should work together and how new features should fit into existing user flows.
A collection of components is useful. A system also needs decisions about how those components should be used.
How I decide where to start
When a client comes to us with a UI problem, I want to understand what they're trying to improve. Are developers spending too much time rebuilding similar elements? Are users struggling to find features? Are new screens becoming harder to fit into the existing product? The answers help us decide what to look at first.
A design system audit makes sense when components look or behave differently across screens, developers keep rebuilding the same elements, or the team lacks clear rules for using UI patterns.
An information architecture audit is worth considering when users struggle with navigation, related features are scattered across the product, similar pages have unclear purposes, or common tasks involve too many steps.
Sometimes, both are necessary. For example, inconsistent navigation labels might come from missing design standards. But they might also reflect a deeper problem with how the product groups its features. Standardizing the labels can help, but it won't solve the problem if the overall structure still confuses users.
I'd also look at what users are actually experiencing. Support tickets, onboarding questions, product analytics, and user interviews can help identify where people get stuck. A UX audit can bring these findings together and help the team decide which changes deserve attention first.
The idea is simple, understand the problem before choosing the solution.
Build a system that works for the whole product
At UITOP, we work with complex SaaS products, dashboards, CRM systems, and internal tools. These products often have multiple user roles, detailed workflows, and years of features behind them.
When working on these products, I look at how the interface is built, what users need to do, how the screens connect, and which parts of the structure make everyday tasks harder. Visual consistency matters, but so do component architecture, navigation, information hierarchy, and interaction patterns.
A good design system gives the team a shared foundation. It makes development more predictable and helps keep the UI consistent as the product grows. Good information architecture helps users find what they need and understand how to get things done. When both work well together, the team can add new features without making the product harder to use.
So, before deciding to rebuild your design system, take a closer look at the problems users are facing. If the issue is slow development and duplicated UI work, the design system may need attention. If people can't find features or keep getting lost in workflows, start by looking at the product structure. And if you're seeing both, it's worth addressing them together.
Your users experience the product as a whole. They want to find what they need, understand their options, and get their work done. Good product design should make that easier.
Top comments (0)