Every hour I spent had to multiply across the whole team — there was no room for open-ended exploration.
Building bespoke foundations from scratch wasn't an option; I had to be resourceful about what I built versus what I adopted.
Handoffs had to be unambiguous — anything open to interpretation would break across the distance.
The system had to unify what already existed, not assume a clean slate.
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 for a variable enterprise-legible font; 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 Angular JS 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 immediate: I had wireframes implemented within two weeks of launch, and the borrowed foundation measurably increased how fast I could iterate each sprint.
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. Designers were using 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.
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.
Early and consistent documentation, standardized wireframe organization, and thoughtful communication patterns significantly reduce friction, improve team alignment, and accelerate adoption across cross-functional teams.
Tailoring workflows, especially developer handoff and team conventions, to real human behaviors and preferences leads to stronger collaboration, fewer misunderstandings, and more efficient execution.
While rapid iteration is critical, maintaining guardrails, such as controlled access, standardized assets (like icons), and simplified communication, prevents chaos and ensures the system remains sustainable as it grows.
