BTT Design System
I initiated and developed a cross-product design system to reduce UI fragmentation across a growing ecosystem of desktop applications and web properties. What began as a professional development initiative quickly became a shared foundation referenced across approximately five products.
As the sole designer, I defined semantic design tokens, light/dark theming, reusable components, and WCAG AA accessibility standards. While governance remained informal and engineering implementation varied by tech stack, the system measurably improved visual consistency, design velocity, and cross-team alignment.
overview
The Problem
As Wycliffe Associates’ product ecosystem expanded, UI patterns began to diverge:
Inconsistent color and typography usage
Fragmented component styling
Branding drift
Developer-built controls without standardized guidance.
Design was often applied after features were developed, leading to reactive fixes and compounding design debt. It became clear that ad hoc decisions would not scale.
The design system was introduced to address cross-product inconsistency, support light and dark themes, reduce redundant design work, and formalize a more scalable systems approach. A UI audit across existing products identified pattern drift and foundational gaps prior to system definition.
Goal
The BTT design system was created to accelerate design workflows, reduce design debt, and empower the development team to make stronger design decisions independently, without relying on constant design consultation.
Constraints
The BTT design system began as a form of professional development that gradually scaled to encompass several projects. It was not formally mandated or versioned, and adoption relied more on shared reference and team influence than enforcement. Implementation varied across projects due to differences in front-end technologies and the overall design maturity of the organization.
Key Factors
Evolving design maturity within the organization shaped how consistently the system was applied.
Front-end technology constraints limited systemic UI updates (e.g., global token changes did not always propagate cleanly)
No formal mandate, governance model, or version control process
Mixed engineering implementation depending on tech stack
System Architecture
Foundations
The system was heavily influenced by atomic design principles and the Material Design standard, which helped establish a shared baseline across applications
Semantic color tokens (structured for theme flexibility)
Light and dark mode support
Typography hierarchy
Defined interaction states
WCAG AA contrast targets (minimum)
I intentionally stopped at the semantic token tier rather than introducing component-level tokens. Given the scale and technical limitations of our ecosystem, this provided sufficient flexibility without unnecessary architectural complexity.
Primitive tokens make up the base for the colors in the design system
Semantic tokens simplify design choices.
Spacing
Spacing was partially standardized, though not fully formalized at the time due to tooling and technical constraints. I loosely based everything on a 16 point grid. If rebuilt today, I would implement a clearer spacing scale and breakpoint strategy to improve cross-platform consistency.
Icons
Iconography was also standardized, as icons frequently represent key concepts such as “target language” and “source audio.” While some individual selections could be refined, establishing a consistent set strengthened meaning across contexts and reduced ambiguity. Clear naming conventions and component descriptions helped communicate intended usage to the development team.
Semantic tokens simplify design choices.
Components
The system defined a small set of core components—buttons, dropdowns, and primary form inputs. Although it did not scale to cover every pattern in the growing ecosystem, standardizing these foundational elements created alignment across products. More complex UI patterns, such as modals, were built from these shared building blocks, leading to more consistent results with less effort.
Component Characteristics
Atomic Structure: Components were built from smaller atoms to allow flexible updates and improve consistency. For example, adjusting an icon position at the atomic level updates every related button instance.
Defined States & Variations: Components include common interaction states and documented variations (e.g., with or without icons, helper text, and other permutations) to reduce ambiguity.
Accessibility by Default: All components meet WCAG AA standards at minimum, with larger touch targets and improved text sizing. This supports users with limited dexterity and improves readability when interfaces are projected or viewed on larger displays.
Common design system components with clues indicating each atom's purpose.
Impact and Evolution
Even without formal enforcement, the system meaningfully influenced how products were designed and built across the ecosystem.
Observable Impact
The system improved day-to-day execution for both design and development and became a de facto reference point across projects.
Increased visual consistency across ~5 products
Reduced redundant component design work
Faster iteration using shared foundations
Broader accessibility alignment
Faster onboarding for additional design support
Key Learnings
Building the system clarified how architecture, governance, and technical constraints interact in real-world environments.
Governance is as important as architecture
Platform and front-end constraints must shape system decisions
Designing for light and dark themes requires eliminating edge cases early
Systems thinking improves long-term maintainability
Future Iteration
If implemented within a more formally supported structure, the system would benefit from clearer governance and deeper architectural rigor.
Formal versioning
Defined contribution model
Standardized spacing scale
Clear responsive breakpoint strategy
Stronger alignment between tokens and front-end implementation
More Projects
Dovetail: A mobile lexicon and translation resource tool. Read Case Study
Orature: An audio translation tool for oral communities. Read Case Study
Spotlight: A mobile lexicon and translation resource tool. Read Case Study