Scaling design system
for multi-platform experiences
T-Mobile has over 50 apps available to customers in the app stores.
The app ecosystem was disconnected, unregulated, and oversaturated which led to a subpar experience for our users.
• Not using native app components and experiences lead to customer
dissatisfaction and poor accessibility
• Different brand messaging undermines the vision and value perception by customers.
Our goal was to create a holistic approach to the app portfolio, establish governance and rationalization for existing applications.
Create consistency of app UX and UI to ensure apps are following best practices of mobile application design.
The first step was to create a set of patterns, guidance and best practices. At the time when I joined the company we had a Design system with T-Mobile web patterns, the goal was to extend the existing design system for the native apps.
- 1. Create an App Playbook - is an extensive UI resource for internal and external cross-functional teams to create, update and reference mobile applications and to promote harmony across our T-Mobile app portfolio.
- 2. Create a UI kit for the main T-Mobile app - a tool that makes creating a T-Mobile app (the main app) fast and easy by providing pre-made, reusable components.
I was responsible for building a visual design, best practices in UX, and accessibility App Playbook sections.
Since T-Mobile portfolio has a variety of different apps I started by analyzing what elements should be consistent across all T-Mobile apps and what will differentiate those apps from each other.
Sections included typography principles, color schemes, platform difference guidance, accessibility instructions for apps, and guidance around shadows and motions.
app UI kit
I’ve built a UI kit library in Adobe XD. A company used Adobe Create Cloud tools. Building a components library in Adobe XD allowed stakeholders to use components easily across all Adobe CC tools.
Exploration and building process of the UI kit in XD along with documentation of usage took me a couple of months. Below I describe my process, how I organized the kit, and some challenges I encountered along the way.
Step 1: Platform differences challenge
The T-Mobile app is a hybrid app. That means that some screens of the app are native and some of them are web wrapped. The challenges I’ve met at that step were how to create components following the OS (iOS and Android) native patterns as close as possible while keeping visual and user experience consistent with the web-wrapped pages.
Closely following the Material design guidance and Apple human interface guidance, I’ve created a list with all main components and prioritized components that should be native and components that should stay consistent with the web patterns.
Step 2: Building in parity
After decisions on the components and pattern differences were made, I started to work with designers who were responsible for web patterns to align the naming of the components. Our final goal is to have one design system that could be used across all platforms - building the system in parity is one of the crucial parts of that process.
Most of the time component parity naming was easy because many of our component’s features are system agnostic like buttons, cards, carousels, etc. However, sometimes this is difficult because there are components whose features need to visibly replicate their platform in order to match expected behaviors. For example, on the web, we use the "dropdown", on the iOS native "action sheet" and on the Android "bottom sheet". All of those components represent the same feature.
Step 3: Building responsive components and documentation
I’ve structured and built components following the atomic-level structure. Atoms, Molecules, Organisms, and Pages (I intentionally skipped Patterns, because for mobile app screens it would be more helpful to show patterns within the whole page). The main XD file is taking a function of the documentation as well. The right section of every artboard is dedicated to iOS and the left section contains documentation of usage for Android.
Every component is responsive and available in a different state, so designers can easily switch between states using the XD right tools panel.
working with developers
After the UI kit in Adobe XD was ready, I’ve started to work closely with developers.
At the time our team worked on the waterfall project structure. The accessibility coach worked closely with the design while including developers early in the process was challenging. Working with developers after all components were built in the Adobe XD slowed down the process, some of them needed to be adjusted based on the developers' feedback.
But having the token system of the foundation elements helped us a lot while working with the native developers and made the collaboration much easier.
adopting design system
At the time Adobe XD tool was a new tool for our company, designers weren’t familiar with the library features, so we (the design system team) hosted a set of workshops with other UX design teams making sure they have a good understanding of the tool and a most important - use UI kit components correctly.
One of the governance challenges we were facing is designers, who have historically designed for the web, have been put on new projects for an app. We needed to make sure their work reflects UX principles of app-specific design.
I was trying to add as detailed documentation as possible of the behavior of the native components to help designers understand the platform differences. I have run weekly office hours (with app devs and accessibility coach included) where we guided designers on the platform-specific components and their usage.
• Integrated experience: creating a consistent, cohesive UI look and feel led to less consumer frustration by standardizing processes, brand usage, tools, collaboration efforts, and overall alignment.
• Increased satisfaction: good experiences means consumers are more willing to consider additional purchases.