Case Study: Building a design system for the Wix mobile app
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. In this case study we’ll examine how we conceptualized and created the robust design system that is used today by the Wix mobile app team.
Initially, our team had no design system in place and we relied on meetings, team-syncs and group decisions in order to maintain a cohesive UI an consistent UX patterns. While this is managable in a small team and a relatively simple product, we quickly realized that this wouldn’t be sustainable as more parts of the Wix ecosystem were being integrated into our app.
Although we were fully commited to developing using React Native, a framework designed to make such projects quicker and simpler to develop without the need for code duplication, our team was still maintaining two separate versions of the app for both iOS and Android. Every screen and flow had to be designed and QA’d for each platform which greatly hindered velocity for all teams involved.
For us designers, this meant that we had to learn and monitor all of the subtle differences in design, UX and behaviors specific for each platform. For example, we designed with San Francisco as the system font for iOS and Roboto for Android. In addition, the constant evolution of iOS’s Human Interface and Android’s Material Design demanded ongoing monitoring to make sure we were up to date with each of their design standards.
Besides the core team of 3 UX designers (at the time), we also needed to be capable of supporting ~12 other Wix verticals that were being integrated into the app in parallel - each with their own teams of designers, devoplers and PMs.
It became obvious that designing on this scale required drastic changes to be made, and luckily one of our our lead mobile developers took this monumental task head-on, with others quickly jumping on board and realizing its potential.
Research and planning
Researching how industry leading brands such as Airbnb and Spotify approached this dillemma strengthened our determination to turn our vision into a reality. We began by mapping out all of our components, from simplest to most complex, and decided on optimal guidelines for design and implementation.
From the start, I strongly believed that the key to our design system’s success was the unification of UX/UI across both platforms, allowing for a system that could be easily maintained on the design side but also the development side. To me, split designs seemed old fashioned and cumbersome, especially for apps that wish to have a more branded experience. Such a change obviously required a fair amount of convincing due to the fact that most people are very loyal to their platform of choice - believing one is superior to the other in terms of UX/UI.
Although most components would become unified, some were deliberately left “native” in order 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 Wix MadeFor font and custom icons.
Some components evolved into “hybrid” versions that mixed custom elements with platform-specific ones. For example, we made our bottom tab navigation adhere to iOS and Android dimensions and spacing, but we adapted the icon styles to fit our brand and removed the textual labels.
In addition to those considerations, I believed that the Wix brand should be the prominent driving force behind our designs. Having our designs aligned to Wix’s brand would mean that our users would be benefiting from a holistic experience across Wix’s desktop & mobile products.
A Generic System Architecture
Because the app was constantly evolving, our secondary criteria for the design system was to create a flexible architecture that could adapt to future changes easily and seamlessly. Together with the lead developer we defined a generic structure upon which we would build the sytem - essentially breaking down all elements into their most atomic form. Most importantly, the most common elements like typography styles, colors, inputs and buttons would be detached from any specific context.
For example, we defined our typography styles with generic names instead of specific ones (i.e. “title” instead of “card-title”).
This decision proved to be key in the success of our design system. Utilizing this centralized method of control makes communication between devs and designers much simpler and most importantly enables us to make cross-app changes very easily.
Similarly, our color palette was broken down to system colors spread across several tints. This proved to be flexible enough for use but also scalable if needed for future expandability.
If we ever want to change the main color of the app, we could do it in one place and instantly change it across all components.
Besides the system colors, we automatically generate these tints for any color chosen by our user - allowing for true customization while still staying within the design system’s logic.
A system within a system
Having defined a basic system for colors, typography and spacing, we then moved on to the most basic elements such as buttons, inputs and forms since these would be the building blocks that make up more complex components and flows.
Creating new components suddenly became was simple because of the basic rules that we previously laid out. Every component that was added came with its own guidelines, specs and behavior based on any previous components it was made up from.
Taking a button as an example, we used our typography styles for the text, our color system to define the colors for every state and spacing presets to make sure everything could scale to different texts.
As a testiment to its success, the design system has managed to support very large-scale changes such as updating the app’s font, adding support for tablets and even things such as accessibility for the visually impaired and RTL support - instantly applying these changes and updates app-wide.
We estimate that over 90% of the app is built using components from the design system, while the remainder are custom components that have not met the criteria for being added (one-of components that are not reused by any other teams). The system has proven its power to increase velocity and consistency for all teams.
Today, the mobile design system is maintained by a dedicated team of over 10 designers and developers that support the various internal teams working in the Wix App environment. Head over here to see more about the Wix App itself.
All projects, photos & images © Copyright 2021, Roy Sherizly