Design System
One system. 254 components. 10+ products.
One designer, fifteen developers.
Tight budget.
Mostly offshore team, multiple time zones.
Ten-plus legacy products on aging tech.
Build on open-source foundations to ship from day one.
The products were already live and I had to start producing immediately, under a tight budget with limited resources. A bespoke foundation built from scratch would have delayed the system by months the team didn't have. So I assembled the base layer from proven open-source building blocks and started iterating on day one: Lato, a versatile, enterprise-legible family with a full 100–900 weight range; Google's color library with defined accessibility keys; Unicons for iconography; Material Design surface levels for states; and unDraw for flexible, easily customized illustration. With the base defined, I layered on the harder pieces: Wijmo for data tables and visualization logic, and AngularJS for component behavior.
The tradeoff was deliberate: I gave up a bespoke, distinctive visual identity in exchange for speed and reliability. For an internal enterprise platform, that was the right call. Consistency and trust mattered far more than visual novelty, and the hours I saved on foundations went into the parts that were actually unique to iTrade's workflows. The payoff was pace. Because the foundation was proven, I could hand over implementable screens while the system itself was still taking shape, instead of finishing the system first and making the team wait.
Rename and govern the icon set instead of using Unicons as-is.
Unicons gave me a fast starting point, but it shipped with far more icons than we needed and names that didn't map to how our team actually worked. As other designers began applying the system to their own products, they were choosing different icons for the same action, creating a convoluted user experience and an unnecessary headache for developers. Left alone, that inconsistency would erode the visual affordances the whole system depended on. So I pared the library down to what our products needed and built a naming scheme around our use cases, not the library's defaults. Every icon is tied to a specific, agreed-upon meaning. Where the supply-chain products needed something the library didn't have, I designed custom icons in the Unicons style so the set stayed visually unified.
The tradeoff was ongoing discipline: a governed, renamed set meant the team couldn't just pull any icon that looked close. They had to use the right one for the defined use, and I had to maintain that convention as the system grew. It was worth it. Consistent iconography gave users reliable visual affordances across every product, and the intentional naming made the asset library actually searchable. Designers found the right icon in seconds instead of scrolling a bloated set and guessing.
Ship a live documentation repository, not just a component library.
A component library tells you what exists; it doesn't tell you how or when to use it. With one designer supporting fifteen developers across time zones, I couldn't be the bottleneck every team routed questions through. The system had to answer for itself. So I invested the extra time to build a living documentation repository the whole organization could reference: code snippets, usage philosophy, explicit implementation instructions, and live demos of each component in context.
The tradeoff was real: documentation is slow, unglamorous work, and every hour spent writing it was an hour not spent designing new components. I chose it anyway, because a design system that isn't documented doesn't scale; it just becomes one person's tribal knowledge. Making the system self-serve meant developers could implement correctly without waiting on me, which is the entire point of a system in a 15-to-1 environment.
254
150+
10+
1
Figma Prototype
Component Collection
System Library Demo
Product Navigation Demo
Screen Examples
Borrow the foundation, own the decisions.
An undocumented system is just memory.
Governance is what makes an icon set usable.
