role
Product Design Intern, Design Systems
team
3 Designers, 5 Engineers, 2 Product Managers
timeline
Jun 2025 - Present
skills
Product Design, Design Systems, Interface Design, Interaction Design, Accessible design
overview
Leading the full-scale redesign and documentation of SAP TripIt's design system
This past June, I had the exciting opportunity to join SAP as a Product Design Intern, with a focus on design systems on the TripIt team. TripIt, acquired by SAP Concur back in 2011 is an travel planner app typically used by enterprise travellers. TripIt can be found on the iOS app store, Google Play store, and web. Additionally, TripIt was recently featured on Apple's Accessibility favourites upon the iOS 26 release.
With TripIt's limited design staff, the design system was in need of a massive overhaul — giving me the chance to help streamline the design and development process at TripIt.
Curious what a day in the life looks like? Check it out here ❀
snapshot
Optimizing designer workflow on a system level
problem
TripIt's design system lacked consistent maintenance, causing friction in design and development processes
A well-structured design system leads to consistent designs and efficient workflows. Given TripIt's lean design team and lack of proper design system maintenance, TripIt's team had three key issues in their existing process.
The naming misalignment in components, colours, and typography from designers/engineers results in confusion in design-engineering discussions
Designers are misusing components and styles because they are unsure about usage guidelines and best practices
Designers are making new components and styles as they see fit, leading to a plethora of redundant components and styles
The naming misalignment in components, colours, and typography from designers/engineers results in confusion in design-engineering discussions
Designers are misusing components and styles because they are unsure about usage guidelines and best practices
Designers are making new components and styles as they see fit, leading to a plethora of redundant components and styles
The naming misalignment in components, colours, and typography from designers/engineers results in confusion in design-engineering discussions
Designers are misusing components and styles because they are unsure about usage guidelines and best practices
Designers are making new components and styles as they see fit, leading to a plethora of redundant components and styles
TripIt needs new design system solutions that reduce the number of components and styles and establish clear, shared language and guidelines for design elements.
the current space
Redundancy leads to more decisions to be made
The current colour styles are extensive, but there's a lot of overlap and redundancy in 1) the hex value of the colours, and 2) the semantic meaning or use case of the colours. Additionally, by using styles rather than variables, it makes the system hard to follow and challenging to scale. A prime example of this redundancy lies in the fact that there are 14 different shades of grey.
discovery
What makes TripIt's design system the way it is?
I conducted user interviews with designers, engineers, and PMs on TripIt, gathering more context as to why the system is the way it is and what they've found challenging in their experience with the design system. Additionally, I consulted with SAP's core design system team that works on SAP's parent design system (Fiori) for further context to guide this process.
From a couple weeks of extensive context-gathering, I gained a new perspective on the underlying problems of the way our team works and how the design system is used.
The system should be scalable, making it easy to add new components and styles without breaking our system
The design system should clearly outline usage guidelines; making a decision for whether which component or styles to use is time-consuming
This system should only show what is necessary
From there, it was time to decide our approach. Tasked to lead a full overhaul of TripIt's design system, I knew we needed to start with our foundations — our colours. Based on our interview insights, we prioritized our next steps from there.
ideation
What about Fiori?
For many years, SAP has asked TripIt to consider switching to Fiori, SAP's design system, to help SAP create a cohesive, cross-product design system. Despite TripIt turning it down the past few years, SAP has informed TripIt that they will have to adopt Fiori in the next few years.
With that in mind, I decided to dive deeper into Fiori and specifically looked into how adopting a well-maintained design system could benefit TripIt's design workflow. However, after an extensive audit and trial, there were some major problems with this approach.
The two systems had varying accessibility guidelines. TripIt's accessibility requirements were more rigid than Fiori's, resulting in many of Fiori's colours failing to pass contrast checks.
Finding direct semantic translations/mappings from Fiori to TripIt was incredibly challenging considering TripIt's unique use cases (consumer app) whereas Fiori is built for enterprise.
The result? The idea of adopting Fiori early was scrapped, but serves as a great resource to prepare for an inevitable switch.
design decisions
Removing colour redundancy
The old system had a plethora of colours that shared similar hex value or functionality, which was highly unnecessary and only leading to more confusion.
To tackle this, I consolidated colours that and ensured they still passed contrast like the previous system did.
An example shown is the consolidation of our 14 different shades of grey in our previous system, consolidated to 9.
*TripIt's design system naturally has an abundance of colours due to the various accessibility modes that TripIt designs for
1 Removing redundant styles
Primitive and semantic colour tokens
To ensure our design system can be more scalable going forward, I created two major collections of colour variables:
1. The core variable set (1) with all our primitives with numbers ordered from light to dark starting with 100 — making room for new colours if needed
2. The Colour Modes collection (2) acts as our semantic set, using primitives that link to semantic variables. This collection is set up for the four modes we design for (Light, Dark, HC Light, HC Dark)
This exact structure is taken from Fiori's variable collection structure, helping our design team prepare for the eventual switch.
2 Establishing variable framework
Reducing decisions with scopes and guidelines
As I mentioned earlier, designers aren't sure when and how to use styles… but what if I could help them?
With these tokens, I added scopes on each token to restrict when and how they are used, while supplementing that with clear guidelines to describe the use case of the token.
3 Scopes & usage guidelines
reflections
Designing for more than the user
Working in design systems meant I wasn't just designing for the final user, I was also designing for a team of designers, engineers, and product managers. With how lean our team is, I assumed big role in being the team's first line of defence when it comes to making sure our designs are accessible for our users. But managing that along with our team's needs, was a new challenge on its own. Not only did the system need to be accessible for TripIt's users, the design components also needed to be accessible for the design and development team. This valuable experience taught me how to empathize for more than just the user, being able to perform a balancing act between (sometimes) conflicting needs.
Systems thinking
At SAP TripIt, I developed a strong sense of systems thinking by working within a large, interconnected design system. I learned how even the smallest change — like adjusting a single color style — could ripple across countless components, screens, and platforms. Understanding these dependencies helped me think beyond isolated visuals and consider how each design decision impacts the overall ecosystem. It taught me to balance flexibility with consistency, ensuring updates worked seamlessly across TripIt’s mobile and web experiences.
Visual consistency vs product flexibility
It's good to thrive for consistency when it comes to design systems, and taking on this role, I've naturally advocated for that. Whether its working on colour styles or for when I do audits on our existing components, my philosophy is consistency and removing redundancy but I've learned I must make room for the flexibility of the product and that it's okay to be inconsistent for the right reasons.
