TravelPerk App Design system

Building experiences
at scales

Designing for large-scale and complex projects has inevitably led to Design Systems becoming common practice in today’s leading companies — many of them adopting different variations of the concept in order to maintain design integrity and scalability across their ever-evolving products and platforms, It can be easy to assume that everyone needs a design system, that you can pick one off the shelf or put one together pretty quickly, and your problems are over.

Like many things, a design system isn’t ever a finished thing — it’s a journey.

For the last two years, I’ve been leading the design of the TravelPerk mobile app.

With it, we have been exploring different visual directions of the app, coming up with new usability patterns while delivering features. The mobile design team at TravelPerk is still tiny and growing daily. There are around twenty people who contribute to our designs in some way. Whether they’re commenting on our latest iterations, fixing copy, or designing cross-platform features.

We’ve already been able to rely on our ongoing UiKit for some time now, but we’re still revising and modifying as we go. We expect this will always be the case as we encounter new reasons to add components to our library or modify what exists, but it reached a point where it was essential to define a shared system that would avoid fragmentation and make us more efficient.

Design conventions differ from platform to platform.Native apps aren’t the web, and we found it essential to consider this from the beginning of the app.

The web is an amazing medium, but it is not the only way our customers interact with our products

These differences in convention can affect the user’s ability to understand the UI or complete certain tasks.

Having an open design system is critical for a fast-growing company like ours. Moreover, building such a thing will bring various benefits like faster time-to-market, better internal communication, alignment between contributors, and consistency across our iOS and Android.

Our app runs on iOS and Android, and we want to be good platform citizens. Therefore, it should look like it belongs on the user’s device. While the lines between web and native apps continue to blur, they both have benefits and trade-offs. The users expect a different experience from native apps, a more seamlessly integrate with their device. By thinking carefully about each platform, we create a design system that feels just right for iOS and Android that brings alongside the TravelPerk feeling and aesthetics.

Designing a product for multiple platforms poses a variety of nuanced challenges. iOS, Android, and Web, contain their own unique guidelines, users, and devices.

The design should be subtly adapted to follow the conventions of each platform. We need to know the different types of UI that can be accomplished on each platform, the APIs that support it, and how they could affect performance.

From the start, I firmly believed that the key to our design system’s is the unification of UX/UI across both platforms allowing the system to be easily maintained on the design and development sides as we wish to have a more branded and coherent experience, not two different apps as we have users that use both OS.

Such an approach required a fair amount of convincing because most people are loyal to their platform of choice.

Although most components would become unified, some were deliberately left as “native” to keep the familiarity associated with each platform. Here is an example of our custom top navigation that conforms to native guidelines but uses the TravelPerk brand.

Some other components evolved into “hybrid” versions that mixed custom elements with platform-specific ones.

By thinking carefully about each platform we target, we can create a design system that feels just right for iOS and Android.

Key achievements

As I scaled up the design team and our product process matured, we gradually built out and strengthened our design system to allow us to work efficiently at scale. We needed a strong Design system for many reasons, mostly to prevent new designers and engineers unkowingly spending time redesigning and building out solutions to which we had already solved for.

93 Comments

Comments are closed.