Should an Enterprise Product Build a Design System Before a Redesign?
— QUESTIONS & ANSWERS
Should an Enterprise Product
Build a Design System
Before a Redesign?
SaaS + Enterprise
Usually, no. For many enterprise products, it is better to redesign a representative set of real workflows first and let the design system emerge from proven interface patterns. Building a large design system before the product direction is validated can produce a library of components that later needs to be reworked.
A design system should capture the patterns a product has proven it needs, not force the product into a component library created in isolation. In our SaaS and enterprise UI/UX design work, we typically solve representative product workflows first, then formalize the reusable patterns into a scalable system. Our Custom Design System Services page shows how those systems support consistency, efficiency, scalability, collaboration, and long-term product growth.
A Design System Should Reflect the Product
Design systems are most useful when they document patterns the product actually needs. If a team begins by designing dozens of abstract components before solving real workflows, it can optimize for completeness instead of usefulness.
Complex products reveal requirements that a generic component inventory cannot predict. Tables may need specific density controls. Forms may require unusual validation. Permissions can affect controls and actions. Dashboards may need specialized data states. Those requirements become much clearer when the team is redesigning actual screens.
Start With Representative Workflows
Choose a group of screens that exposes the product's major patterns: navigation, forms, tables, filters, data visualization, modals, alerts, empty states, status states, and high-value actions. Redesign those workflows until the interaction and visual direction are working.
The components created during that process can then be formalized into a design system with much greater confidence. The system grows from evidence rather than speculation, and the team gains reusable patterns that have already survived real product constraints.
There Are Exceptions
If an organization already has a mature product family and a strong system that simply needs extension, a redesign may begin inside that established framework. A company building several products in parallel may also need system-level decisions earlier so teams do not create incompatible foundations.
Even then, the system should be tested against real use cases. A component that looks complete in a library can still fail when it is placed inside a dense enterprise workflow, a different platform, or an interaction state the original system never anticipated.
Treat the Design System as a Living Product
A design system is not a one-time deliverable that becomes frozen after launch. Products evolve, new states appear, accessibility requirements improve, teams add features, and better interaction patterns emerge through continued product work.
The strongest systems provide enough consistency to speed design and development while remaining flexible enough to support the product as it changes. That balance is what allows a design system to reduce design debt without becoming another source of constraint.
ACI Worldwide Biller Web + Mobile App
The ACI Worldwide Biller redesign is a strong example of designing the product and the system together. The Skins Factory redesigned the payment experience across web and mobile while building the supporting UI kit and style guide for typography, color, spacing, navigation, forms, tables, notifications, dialogs, status states, and reusable components. The system was developed for both themes so the same visual and interaction language could scale across the complete product. View the ACI Worldwide Biller Design System in Dark Mode and the ACI Worldwide Biller Design System in Light Mode.
Common Questions
Frequently Asked Questions
Can a Redesign and Design System Be Created at the Same Time?
Yes. For many SaaS and enterprise products, that is the most practical approach. The redesign exposes the real navigation, forms, tables, filters, states, permissions, alerts, data density, and interaction patterns the product actually needs. As those patterns are solved and validated in real workflows, they can be formalized into reusable components and documented rules.
This keeps the design system grounded in the product rather than in an abstract component inventory. By the time the redesign expands into additional modules, the team has both an approved product direction and a reusable system that can accelerate propagation without forcing every future screen to be designed from scratch.
Why Not Build the Full Design System Before the Redesign?
Because a component library can look complete while still failing inside the product it is supposed to support. Enterprise applications often contain dense tables, unusual validation, role-based permissions, complex forms, long workflows, exceptions, empty states, error states, and data conditions that are difficult to predict from a generic list of components.
Starting with representative workflows gives the team evidence. It reveals which components are genuinely reusable, how much flexibility they need, and where the product requires specialized patterns. The design system can then document proven solutions instead of creating dozens of components that may need to be redesigned once real product work begins.
Does Every SaaS Product Need a Large Design System?
No. The system should be proportional to the product, the number of platforms, the number of contributors, and how quickly the application is expected to grow. A smaller SaaS product may only need a focused UI kit, typography and color rules, spacing guidance, core form controls, navigation patterns, and the states used repeatedly across the experience.
Larger enterprise platforms usually benefit from deeper documentation because more teams, modules, user roles, and interaction states create more opportunities for inconsistency. The goal is not to build the biggest possible design system. It is to create enough structure that the product can scale without repeatedly solving the same interface problems or drifting away from its established design language.
Continue Exploring
Explore More
Custom Design System Services
Explore bespoke UI kits, style guides, component libraries, states, spacing rules, typography, color systems, and scalable interface standards built around the product.
→ From the PortfolioACI Worldwide Biller Web + Mobile App
See how the product redesign and its supporting light and dark design system were developed as one connected payment experience.
→ ExpertiseSaaS & Enterprise UI/UX Design
Explore our work across complex SaaS products, enterprise platforms, dashboards, portals, workflows, modernization, and design systems.
→Building or redesigning an enterprise product?
We can help you establish the product direction first, then turn the patterns that work into a custom design system your designers and developers can reuse as the application grows.
Need a Design System? Let's chat.
Thank you for reaching out.
We will be in touch within one business day.