I worked with five distinct design systems on real client projects this year — three established commercial systems, one custom client system, and one I built from scratch for a client. The experiences varied dramatically in ways I hadn't expected. Some systems accelerated my work substantially; others added more friction than they removed. Here's the honest breakdown of what worked, what didn't, and what makes a design system actually useful versus performatively complete.
The five systems tested
- Material Design 3 — Google's system, used on a project building tools for technical users
- Apple Human Interface Guidelines — used on a native iOS project
- Tailwind UI — used on a marketing site project
- Custom enterprise system — a Fortune-500 client's in-house system used on their product work
- From-scratch system — built for a client without an existing system
Each of these consumed weeks to months of focused work. The differences between them were instructive.
What worked across systems
The systems that accelerated my work shared specific features:
1. Clear primitives, well-documented
Color tokens, typography scales, spacing units, border radii — the foundational primitives need to be clearly defined and easy to reference. The systems that did this well saved time on every component decision.
Material Design 3 and Tailwind UI both excel here. Apple's HIG is documented but the documentation is dense. The custom enterprise system had primitives but they were poorly documented; finding the canonical version of each token took effort.
2. Component composition that's actually predictable
Components should compose in ways that produce expected results. The systems that get this right let you predict what a button-inside-a-card-inside-a-modal will look like without testing. The systems that get this wrong require testing every combination.
Tailwind UI is strong here because the composition is explicit. Material Design 3 has gotten better but still has surprising interactions in some component combinations. Apple's HIG is generally predictable; the from-scratch system was as predictable as I built it to be.
3. Real-world examples beyond component documentation
Component libraries that show only individual components in isolation are less useful than libraries that show real-world layouts and patterns. The latter teaches application, not just inventory.
Tailwind UI is exceptional here — most of its value is the layouts and patterns, not the individual components. Material has improved but is still component-heavy. Apple's HIG is mostly conceptual rather than pattern-focused.
4. Thoughtful constraint, not maximum flexibility
The systems that work best constrain choices in deliberate ways. "Here's the right way to do X" is more useful than "here are 17 ways to do X, choose freely."
This is counterintuitive for designers who value flexibility. In practice, the constraint accelerates work because most decisions don't need to be made; the system has already made them.
What didn't work across systems
1. Comprehensive coverage that doesn't match real product needs
Some systems have hundreds of components for situations that almost never arise in real products. The cognitive overhead of navigating the system exceeds the value of the obscure components.
Material Design has this problem; the system is comprehensive in ways that often slow down work on simpler products. Tailwind UI is more focused on actually-common patterns and is more useful for that reason.
2. Theming systems that promise more than they deliver
Several of the systems promised "easy theming" that, in practice, required significant configuration to make work for specific brand contexts. The promised flexibility was real but expensive to access.
This was particularly painful with Material Design 3, where the theming system is sophisticated but requires learning curve. Tailwind's theming is simpler and more predictable in execution.
3. Documentation written for system maintainers, not system users
Some systems have documentation aimed at the people building the system rather than the people using it. The documentation is technically complete but practically useless for daily work.
The custom enterprise system suffered most from this. The from-scratch system I built I could optimize for users from the start; the established systems had legacy documentation patterns that didn't prioritize user experience.
The from-scratch system
Building a design system from scratch for a client gave me appreciation for what the established systems do well. The work involved:
- Defining color tokens and naming conventions
- Establishing typography scale
- Building primary component library (40-50 components)
- Documenting patterns and applications
- Building Figma library and code starter
Total time: approximately 200 hours of focused work over three months. The result was a system specific to the client's brand and product — more focused than the general-purpose systems, less battle-tested.
Six months later, the client team is using the system actively. Some components needed revision based on actual product use; the system has evolved as the product has matured. The investment was justified for a client at this scale; for a smaller client, the cost-benefit math wouldn't have worked.
When to use which kind of system
The decision framework that emerged from the testing:
Use established commercial systems (Material, Tailwind UI, Mantine, etc.) when:
- The project doesn't need distinctive brand expression
- Speed to market matters more than uniqueness
- Team will be small and consistent
- Budget is modest
Use platform-native systems (Apple HIG, Material for Android) when:
- Building native applications for that platform
- Users' expectations match the platform conventions
- Team has expertise in that platform
Use custom systems when:
- Brand is a primary differentiator
- Product complexity requires patterns not in established systems
- Team is large enough to absorb the maintenance cost
- Budget supports the investment
Use no system when:
- Project is small enough that the system overhead exceeds the savings
- Project is one-off without ongoing iteration
The pattern that surprised me
The most-surprising finding was that the systems' theoretical comprehensiveness mattered less than their practical usability. Material Design has more components than Tailwind UI; for actual project work, Tailwind UI was more useful in most cases because the components were the right ones for common needs and the patterns showed real applications.
Designers evaluating systems often weight comprehensiveness too highly. The system you'll actually use is the one that fits your project, not the one that covers the most theoretical use cases.
What I'd tell designers choosing a system
Three pieces of advice based on the testing:
- Test the system on a real project before committing to it. The marketing pages don't reveal what working in the system actually feels like.
- Weight pattern documentation higher than component count. Real-world examples are more useful than exhaustive component inventories.
- Plan for the learning curve. Even good systems take a few weeks to internalize. The productivity benefit comes after the curve, not during it.
The takeaway
Design systems vary more than the discourse suggests. The best ones accelerate work substantially; the worst ones add friction without proportionate benefit. Choose based on what fits your specific projects, not on which system has the most-comprehensive marketing.
The system that's right for you is the one you'll actually use, not the one that looks best in evaluation. Testing on real work is the only reliable way to find this out.
