Thomson Reuters Saffron Design System
Blueprints: A single source of truth for components
Role: Lead UX Designer, design system team
Duration: 2024–2025
Focus Area: Cross-functional collaboration, documentation systems
The challenge
The design system team had a solid process for building and maintaining components — but no consistent way to capture what they learned along the way. Specs lived in scattered locations and decisions went unrecorded. When a component shipped with gaps, the team had to trace back through individual files, messages, and meetings just to understand what had been decided and why.
Critical component knowledge was siloed across disciplines, causing quality gaps, slower development cycles, and preventable bugs — with no shared record of the decisions that shaped each component.
Key pain points
For the design system team: Each discipline kept its own documentation, making it nearly impossible to get a complete, accurate picture of any component. Developers were sometimes assigned mid-project with no clear hand-off resource. When someone left or was unavailable, work stalled.
For design system consumers: Documentation was fragmented across Storybook, Figma, and GitHub. Many users didn't know spec docs existed, or found them too overwhelming to navigate. Consumers sometimes built their own component variants because they couldn't find existing ones.
For the organization: Incomplete specs led to accessibility gaps, missed use cases, and rework after release. Floating components (like File Upload and Adaptive SideNav) had stalled for over a year due to missing requirements and no clear point of reference.
"I have struggled with [these components] because there were no expectations, specifications, or other information to build them and it has slowed development down significantly... I ended up missing accessibility requirements and design requirements because those parties were not involved." — Engineer on the design system team
Success metrics
Reduction in post-release bugs and community support tickets
Faster testing cycles due to centralized component documentation
Decreased onboarding time for new team members
Less time spent on repeat conversations and context-switching between disciplines
The approach
Research & discovery
The team ran a cross-disciplinary research effort to understand how each discipline interacted with component documentation — both internally and externally.
`**Visual suggestion:** A grid or diagram mapping pain points by discipline (UX, UXE, Engineering, Accessibility, Content) and audience type (internal team vs. consumers).`
Key findings:
Across all disciplines, the top pain points were discoverability, inconsistency between platforms, and the absence of a single source of truth
External consumers weren't aware spec docs existed, and when they found them, they were too dense for quick reference
Engineers needed more detailed keyboard navigation and interaction specs upfront — their absence caused significant delays and rework
Accessibility specialists were involved early but lacked a formal space to capture requirements in shared documentation
Naming inconsistencies between Figma and code caused confusion at every handoff point
`**Visual suggestion:** A before/after diagram showing the documentation landscape — scattered files in step 1, centralized Blueprint in step 2.`
Strategy & vision
Rather than building a new process from scratch, the initiative recognized that the team was already gathering all the right information — it just wasn't being recorded consistently or stored anywhere shared.
The strategy: meet the team where they already were. Introduce a standardized template (Blueprints) that could be completed as a natural part of the existing component creation and maintenance workflow — not as additional overhead.
Key principles driving the approach:
Start lean; capture what's known and revisit what isn't
Blueprints are a living document, not written in stone
Cross-disciplinary ownership from the start
Prioritize the information most likely to reduce rework (interactions, states, edge cases, accessibility requirements)
Key initiatives
Blueprint template (Markdown + Figma)
A standardized spec template designed to capture everything a team member needs to build, test, or maintain a component — including component behavior, accessibility requirements, content guidelines, interaction states, and design decisions. Available in both Markdown (for GitHub) and Figma to match how different disciplines work.
Rollout: Introduced in Roundtable meetings; integrated into the existing component creation and enhancement workflow so adoption required minimal behavior change.
Cross-disciplinary working group
A focused group of representatives from UX, UXE, Architecture, Accessibility, and Content met regularly to co-develop the template, pressure-test it against real components, and identify gaps in how each discipline currently defined its own standards.
Journey mapping sessions
Structured sessions to map out the current documentation experience across disciplines — surfacing where information was lost, duplicated, or never captured in the first place. These sessions became a key input for template design and workflow redesign.
Component creation workflow redesign
In parallel with Blueprints, the team redesigned the end-to-end workflow for new and enhanced components — with clearer stage gates, defined roles, and explicit moments for cross-disciplinary review. The redesign addressed a recurring pattern of scope creep, mid-development design changes, and unclear decision authority.
Key addition: A low-fidelity prototype step early in the process to align engineering and design on behavior and interactions before detailed spec work begins — reducing costly back-and-forth later.
The solution in action
`**Visual suggestion:** Annotated screenshot or mockup of a completed Blueprint template showing sections: component overview, interaction states, accessibility requirements, content guidelines, design decisions log.`
`**Visual suggestion:** Side-by-side comparison of the old process (scattered docs, siloed disciplines) vs. the new process (centralized Blueprint, cross-discipline touchpoints mapped to workflow stages).`
A Blueprint for a component like a complex date picker, for example, would consolidate:
All interaction states, including combinations with other components
Keyboard navigation specs (previously missing from initial docs, causing rework)
Accessibility requirements per WCAG, with actionable implementation notes
Content guidelines including character limits, wrapping behavior, and label expectations
A decision log explaining why specific choices were made — reducing repeat conversations in future sprints
Results & impact
What went well
The smaller, focused working group moved quickly and generated new documentation standards the broader team found genuinely useful
Journey mapping revealed existing gaps that individual disciplines hadn't seen in isolation — creating shared understanding across the team
Regular working sessions created momentum and kept direction clear
The cross-disciplinary format surfaced competing definitions (e.g., what counts as a "bug" vs. an "accessibility violation") that had been causing quiet friction for years
Areas still in progress
Defining a clear, quantitative measure of impact (e.g., bug reduction rate, ticket volume)
Establishing consistent ownership and decision-making authority within the Blueprint process
Coordinating with content and usage guidelines to eliminate overlap
Determining which components qualify for a full Blueprint vs. a lighter-touch approach
Business impact
The Blueprints initiative directly addresses the conditions that allowed components to stall for over a year without resolution. With a shared record of decisions, accessibility requirements, and interaction specs, teams can onboard faster, test more efficiently, and ship with fewer gaps — reducing the cost of post-release support and rework.
Learnings & evolution
What worked well
A small, consistent working group with cross-disciplinary representation was the highest-leverage structural choice. It created trust, generated momentum, and surfaced insights that siloed meetings never would. The journey mapping sessions in particular produced a level of shared understanding that individual interviews couldn't replicate.
Challenges & how they were addressed
The initiative struggled early with vague deliverables and unclear ownership — common risks in exploratory systems work. Clarifying ownership, naming a single initiative lead, and breaking the work into smaller defined stages helped re-focus the group and reduce competing interpretations of the goal.
There was also honest tension around priority: Blueprints was classified as lower priority, yet the problems it addressed were actively slowing high-priority work. Making that connection explicit — and tying it to concrete examples like stalled components — helped build the case for sustained investment.
What I'd do differently
Define the success metrics earlier and more concretely. The initiative would have been easier to scope, communicate, and sustain with a quantitative target (e.g., "reduce post-release bugs by X%") from the start. Starting with a single pilot component and measuring outcomes before scaling also would have built a stronger proof of concept.
Future opportunities
Phase 2 — Testing documentation: Extend Blueprints to include testing plans and QA checklists as a second layer built on the initial spec foundation
Consumer-facing Blueprints: A lightweight version of the template could improve discoverability and transparency for design system consumers — surfacing the "why" behind component decisions
Automated spec generation: As tooling matures, explore ways to auto-generate baseline Blueprint content from existing component code or Figma files, reducing the manual lift of documentation
Community voting integration: Use the redesigned workflow's upvoting mechanism to help prioritize which components get full Blueprints first
Reflection
Design systems are only as good as the trust teams place in them. When documentation is fragmented, inconsistent, or simply missing, that trust erodes — slowly at first, and then all at once when a complex component ships with critical gaps. Blueprints is a bet that a small investment in structured knowledge-sharing compounds into significantly better work over time. The most meaningful outcome isn't the template itself — it's the shift toward a team culture where capturing decisions is a natural part of shipping, not an afterthought.