Product depth
Years inside distinct travel products exposed different users, devices, operating environments, commercial models, and technical realities.
01
Sabre · 2007–2023
I learned the enterprise one product at a time. Then helped build the system that could connect it.
Sixteen years across consumer travel, corporate booking, airline, and hospitality led to a founding role on Sabre Spark—and a design practice built to scale through shared tools, direct support, and trust.
- Role
- Principal Designer
Founding Spark designer - Range
- Product UX · Systems
Enterprise enablement - Leadership
- Mentored 15+ designers
Cross-team partnership
02
The case in 30 seconds
Different products. Repeated problems. One opportunity to multiply better decisions.
System responsibility
As a founding Spark designer, I helped translate recurring product needs into three generations of shared foundations, patterns, documentation, and resources.
Participatory adoption
I mentored designers, supported teams directly, and helped create the Spark Showcase so implementation quality became visible, coached, and celebrated.
Three completed Spark generations
40+ coded UI elements documented in V3
Responsive product guidance
Mentored 15+ designers
03
Product range became research
Before I helped shape the system, I had to understand the realities it would serve.
04
The multiplication problem
Improving one interface at a time could not create an enterprise experience.
Independent product work could improve local experiences while the broader portfolio continued to diverge. The opportunity was not to erase product differences—it was to make strong shared decisions available wherever they genuinely applied.
Different work had to stay different.
- Booking
- Operations
- Analytics
- Traveler tools
- Hospitality
The same questions kept returning.
- Hierarchy
- Navigation
- Status
- Data density
- Responsiveness
- Accessibility
Teams repeatedly solved related problems with uneven outcomes.
Local progress could not compound without shared infrastructure.
Enterprise consistency cannot be imposed abstractly. It has to earn its place inside real product constraints.
05
Founding Sabre Spark
We were not building a style guide. We were building shared product judgment.
As one of Spark’s founding designers, I worked with another founding designer and a broader network of partners to turn recurring product lessons into a shared design language for Sabre’s targeted top-tier products.
Foundations
Color · type · spacing · grids · accessibility
Interaction language
Navigation · controls · feedback · hierarchy · responsive behavior
Product guidance
Templates · data visualization · forms · operational patterns
Enablement
Libraries · documentation · training · roadmap · intake · direct support
Scope: Founding designer and system contributor—not sole creator.
06
Three generations of maturity
Each generation expanded what the system had to solve.
The progression was not simply more components. Spark grew from a recognizable language into deeper product guidance—and then into a service teams could more easily understand, access, and apply.
Establish the language.
Create a coherent visual and interaction foundation teams could recognize and begin using.
RecognitionBroaden the system.
Add component depth, responsive behavior, operational patterns, and clearer application across products.
ReachMake the system easier to use.
Strengthen documentation, accessibility evidence, data visualization, templates, resources, and support.
EnablementThis case study covers the three completed Spark generations. Later Sabre rebranding and subsequent refinements occurred after my involvement.
07
Rigor inside complexity
Shared patterns only mattered if they held up inside dense, consequential work.
Spark documented more than appearance. The system had to address state, hierarchy, semantic meaning, responsive behavior, product context, and implementation guidance.
Accessible color
Contrast was documented, not assumed.
Tonal scales paired exact values with white and black contrast evidence.
Data visualization
Guidance connected principles to product structure.
Chart selection, palettes, hierarchy, controls, legends, and layouts were treated as one system.
Reusable behavior
Components carried meaning across contexts.
Gauge, KPI, status, and density variants supported operational products—not isolated demos.
StateHierarchyMeaningResponsivenessImplementation
08
Guidance returned to product
The system became credible when teams could recognize it inside their own products.
The goal was not visual sameness. Teams needed enough shared structure to improve hierarchy, behavior, accessibility, and implementation while preserving the needs of their product and users.
09
Enablement was designed
Publishing components was only the beginning.
Spark gave teams multiple ways to enter the system, understand it, request change, and apply it. Supporting both Sketch and Figma during the transition reduced adoption cost for teams moving at different speeds.
Libraries + files
Figma · Sketch · fonts · icons · templates
Guidance + support
Documentation · training · newsletters · contact · direct help
Operating feedback
Roadmap · changelog · Jira intake · implementation examples
Evidence boundary: The archive verifies that dual-tool enablement existed. My precise ownership within the Sketch-to-Figma transition is discussed conversationally rather than overstated here.
10
Adoption became a program
We made adoption visible, participatory, and worth celebrating.
Governance showed teams what good looked like. The Spark Showcase gave them a reason to make the system their own—and made strong implementation visible across the enterprise.
My role crossed the full loop
Conceive
Place
Recognize
Evaluate
Support
Mentor
Helped shape the Showcase concept and its role in adoption.
Defined how and where the program lived within the Spark site.
Designed the tiered stickers and visible reward system.
Reviewed and judged product-team submissions.
Worked hands-on with teams improving implementation quality.
Used critique and partnership to build trust around the system.
Governance told teams what good looked like. Participation helped them make it their own.
11
Leadership stayed close to the work
My influence grew, but I never stopped working alongside the people applying the system.
I led through a feedback loop: listen to product reality, improve the implementation, then carry the learning back into Spark so the next team started stronger.
teams
leadership15+ designers mentored
system
ResearchUsabilityBrandProductEngineeringLeadership
Product learning improved the system. The stronger system returned to product.
Critique + mentorship
Help designers sharpen decisions, not merely conform to a library.
Implementation support
Work directly with teams when product constraints challenged the system.
Submission evaluation
Recognize strong adoption while making quality expectations tangible.
Pattern development
Turn repeated product needs into foundations and reusable guidance.
Feedback return
Bring edge cases and implementation learning back into Spark.
Resource creation
Make system judgment easier to find, understand, and apply.
12
What scaled
I did not leave product design behind. I helped good product decisions travel farther.
Sixteen years of product depth became a leadership practice grounded in credibility, practical guidance, direct support, and trust.
What the system carried
Shared foundations · components · patterns · responsive resources · product guidance
What made it sustainable
Implementation support · feedback loops · mentorship · visible participation · trust
I do my best work where product complexity, design quality, and organizational scale meet.
I’m happy to go deeper into the system craft, adoption strategy, or how I worked with individual teams.