A visual language for a digital product
(This post is part of a series on how to build a design system. Read the previous post on Typographic Scales, here)
It was 2020 and we had a better design environment than before the Typographic Scales were defined.
The branding team approached us to start a new journey. Pomelo was growing quite fast and we were no longer a single Brand seller but a Fashion Marketplace and our platforms urgently needed a brand update.
We (all creative teams) were aware of the complexity of the commission. We needed to create a consistent and cohesive language to be able to set up a scalable system.
During the project planning, we scoped the project with only a "few" changes. We were going to update the Pomelo brand, including the logo, typographic treatment, color palette, iconography, and the app's feed design. No more no less.
For the UXUI team, a second objective was only natural, we needed to increase design and engineering workflow efficiency.
Role: UXUI Design Team Lead
Platforms: Mobile Apps & Web
Disciplines: Design languages
Tools: InVision app, Sketch, Zeplin, Figma.
A design system is a set of connected patterns and shared practices, coherently organized to serve the purposes of a digital product. Alla Kholmatova
The UI audit was an initiative that started before we moved all our design material from Sketch to Figma. That is why we initially decided the inventory needed to be created in Invision as we considered it the best option for a repository that will allow us to create libraries in the near future.
We took screenshots of our platforms page by page so that our reference was the production's current status, rather than our mockups. And we categorized components in terms of usage.
As the inventory result, we were able to spot incongruent patterns and unnecessary components that could be updated or removed. Our main objectives at this point were to organize and economize but we didn't really know how to start.
Looking for help
The team was really excited about the project, we read tons of online articles about design systems, and our main references were Google Material Design, Carbon Design System, Airbnb Design Language System (DLS), and Polaris by Shopify.
But those were a north star, and the space where we were to where we wanted to be was intimidating. That’s when we decided to go out and do some networking; we decided to ask for help from the design community.
Talking to other local designers working for companies that have their own systems running, helped us understand how the system didn’t need to be perfect to be launched, it made us understand how the UI Kits are living libraries that are never going to be finished. And that was a big relief.
We were introduced to the Atomic Design Methodology by Brad Frost, which served us as a guide on how to organize our UI Kit. The methodology is “composed of five distinct stages working together to create interface design systems in a more deliberate and hierarchical manner”. (Atomic Design Methodology by Brad Frost)
Plan the solution
As a design team lead, my responsibility was to define a strategy and create a plan and a visual representation of both as a roadmap with clear design milestones.
Our first big task was to define the foundational structure in order to map all pages and platforms as hand-off deliverables. To set that structure we followed 3 main phases:
- Creation of building blocks or style guides of basic elements including, typographic treatment, color palette, and iconography.
- UI patterns library definition, to be able to take a step back and break the current Apps design into smaller, more manageable chunks
- Define and document component guidelines, such as usage (to explain the pattern and user intention when using the component), anatomy (to explain the structure of each component), and placement (to give the component a context), guidelines.
We needed allies for this challenge and to make sure other teams agreed on how building a Design system was going to facilitate the Brand redesign and open the possibility to regularly iterating we were using as an argument the design system efficiency curve, to justify the value of this methodology.
At this point in time, in mid-2020, a nice coincidence happen, one of our Sketch licenses was about to expire, And Zeplin renewal will happen in the following month. One of the designers who had previous experience working on Figma proposed we could switch to the popular design tool. I can’t say my managers were happy to see how from their perspective the project was becoming even bigger, but I did my best to pitch how we were going to save money by moving from two different applications’ licenses to only one that also included a version controller and prototyping system, which basically made it a time saver for the product team.
The budget was approved, and we were moving to Figma, but the fact that Zeplin was expiring soon only gave us one month to make it happen. We set a risky deadline for ourselves.
In 2019 we created the first version of our typographic style-guides or type scales.
So our first task this time was to simplify the number of text styles from 23 to 15 following Google material design as a reference.
We didn’t really know how to establish the number of styles we needed without defining a set of templates so we opted for following an expert as a reference and manually adapting to the new rules.
We also simplified the number of colors because the existing palette was huge. Fun fact, our website code included 16 shades of gray.
First, we organized the color palette provided by the branding team according to the expected usage eg. of primary, neutral, secondary, error, and success color codes. Followed by applying the necessary adjustments, to make sure all colors passed accessibility contrast standards to ensure legibility.
Grid, Spacing, and Layout
We defined the grid layout as 12 columns for web desktop view and 4 columns for mobile platforms. This was a critical point where we defined a column grid as our layout foundation and we missed the spacing definition. A small huge mistake was to consider Apps layout as if they could be understood as Bootstrap's grid system.
I didn’t realize how big the issue was, and we continued with the design of the components. This management decision caused big problems between the designers' and front-end developers' workflow later on.
From the most simple elements, we grew into complex components. We went from atoms to molecules, to organisms, to pages, skipping templates for two main reasons: We were expected to share our process through tangible design files as the check-in meetings needed to be visual and concrete.
The second reason was that a unified set of templates for our platforms was in reality a re-platforming process, and we knew our results were going to be outside the parameters of the design scope.
Repeating our own strategy to apply type scales in the past, we defined our pages’ hierarchy following two criteria:
- The time when the user reaches that page.
- The complexity of the page, including the number of interconnected organisms it might include. Creating the most complex pages would give us guidance when creating simple pages.
We divided our “to-do list” into primary and secondary pages. And by this point, we were able to define the project in relation to complexity and time.
A small sample of our recently created UI Kit Components
A small sample of our recently created UI technical guidelines
The project was planned for a total of 36 weeks including design and development. One of our main milestones was to design primary journeys including our most complex organisms, the product tiles. We reached that objective on time, on September 2020. But during our catch-up session with the branding team, we noticed how didn’t actually understand the assembling nature of the process we were going through, on our previous DS sharing sessions; the feedback sessions soon became design system evangelizing sessions, where we needed to explain over and over why increasing just one point of a block of text font size was not possible, and we rather needed to change the style, keeping a consistent use of that particular style across molecules, organisms, and pages.
It was challenging, the teams started to feel we were mutual blockers, and the action points execution was lengthy.
But as we started to get increasingly concrete, our stakeholders were finally able to see how the interface began to take shape.
It took us 9 months to finally be working from Figma with a DS set in place, and a long list of Business projects that were patiently waiting in our backlog.
Apps Feed redesign. Before & After.
Challenges and Pain Points
- Even if we initially paid attention to layouts and grids' general principles, we didn’t understand how to set a space scale, specifically within the context of a component (i.e. the space between a label and a text input). At a certain point, we found out our components and layouts were not actually unified and working together, so we had to go back and unify spacing page by page. We knew these errors could happen, as we were assembling a modular system but we really had to experience it the hard way.
- The Design System was an initiative that was possible thanks to the company rebranding process and some user experience improvements were evidently needed yet ignored, as they were not related to a rebrand. We had to move on and focus on creating UI kits of existing behavioral patterns without considering another approach.
- As a team leader, I missed to shape and share the visual direction the project was following, without having to build full compositions this situation generated lengthy feedback sessions where the execution part on our side was really time-consuming.
Learning & Achievements
- What we have done is only a UI kit which is one of the components of a design system. We still have a long way to achieve our objectives.
- The system doesn’t need to be perfect, because is naturally going to evolve and change, exactly the same as the organization, the design system is a living organism.
- Regular feedback sessions are one of the main foundations of the system adoption. The objective is to be able to build a system all the online teams are implementing in their regular activities.
- Maintenance is closely related to velocity. If our UI kits are well-maintained the product teams are able to achieve better outcomes faster as a result of having the design system at their disposal so that the teams can focus on UX processes.
Special thanks to the Pomelo team members for years of experimentation. Milestones are mirrors through which we can see the hard work of many. ขอบคุณค่ะ