Case Study / Mobile Design System / Setel
My role
Product designer
Mobile Design System owner
Documentation
Design QA
Platform
iOS
Android
Product
Setel Mobile Design System
Year
2021
Setel is Malaysia’s first-ever fuel e-payment app which allows motorists to purchase fuel, manage their fuel payments, purchase items from the station convenience store, earn and redeem reward points and many more. Currently, Setel mobile design team consists of 10 product designers. At Setel, I am working as a Product Designer as well as the owner of the Mobile Design System.
Within a year and a half, we have been able to improve the mobile design system significantly. Currently, it’s in a good stable setting. But still, we noticed a problem with the deliverables. The UI quality of the app was not up to our expected standards. We realised that the Mobile Design System needed expertise apart from designers, thus we decided to team up with engineers to build our design system components in their iOS and Android codebase as Modular UI Components.
Despite having a stable design system, the quality of some of the deliverables were dissatisfying.
There was lack of consistency and some common issues with the UI.
How might we improve the quality of the deliverables?
1
Build Modular UI Components → Our plan was to select the highly reusable components and get them built as components on iOS and Android codebase. We, the Mobile Design System team, are in control of the quality of those modular components so we will do Design QA and approve the built components. Once done, the feature team engineers can reuse those modular components.
2
Writing thorough design system documents → These documents are for engineers and product designers to understand the usage and the guidelines of the components. Also, these act as the design handoff documents for the engineers who build Modular UI Components.
3
Creating a UIKit to improve the quality of the handoff documents → At Setel, the product designers write design specification documents for developer handoffs. But the documents had a few conflicts such as missing out on important details or the visuals they used to portray the designs being different from each designer. This is problematic when engineers work with multiple designers. In those scenarios, they have to understand each designer’s structure and style of documentation. By improving the standards of the handoff documents, we could improve the standards of the deliverables.
Limited time → Including myself, there are only 2 product designers in the mobile design system team and we were designers on separate feature teams as well. Managing time for this modularisation project was a challenge for us. The engineering team faced the same problem since we did not have a dedicated design system engineering team. All engineers had duly duties on their own feature teams. So time management was a challenge for all of us.
Selecting components → Since the engineers had tight schedules, we could only pick a fixed number of components to convert as Modular UI Components. We had to choose only the most reusable components for this first round.
The first step of the plan was to decide which components to build. Our goal was to pick the most reusable components in our design system. But it could have other constraints from the engineers because some of the components might not be even possible to build as Modular Components. We had a preliminary list of components in our mind, so we organised a meeting with the engineers to decide the final list. For this round, we picked the following:
1
Navigation header
2
Notice banner
3
Tooltip
4
Inputs
5
Toast
6
Buttons
7
Popover
8
Calendar
9
Bottom sheet
10
Dialog
11
Typography
12
Colours
Design team: 2 members
Engineering team: 4 members (2 engineers for each platform, iOS and Android).
We decided on a 3 months plan to build and release the Modular UI Components library.
The next step of the process was to write thorough documents for components. We already had a few documents drafted in the design system for the product designers. But this time, we wanted these documents to benefit both product designers and engineers. Other than writing new component documents, we had to update those existing documents as well.
While working on the documents, I had regular discussions with engineers on feasibility and limitations on their end. As a result of the discussions, I realised that sometimes what can be modularised could be different from one OS to another or there could be an easier way to implement what we planned. Therefore, I amended the documents based on their feedback.
We made sure the documents are clear-cut, thorough yet brief.
While drafting, we didn’t only focus on Modular UI Components. We wrote the documents focusing on designers as well, to deliver a better understanding of the usage and rules of the components.
We made sure to use visual representations in every possible space instead of a text-heavy document.
As the documents were all set, we handed them over to the engineers. They created two testing environments for us to do a design QA.
While they develop, they occasionally come across limitations. (e.g. iOS Navigation header’s scroll behaviour is not possible to modularise). In such situations, I discussed workarounds with the engineers and iterate based on those.
Once the components were built, we deep-dived into design QA and made sure everything followed the guidelines we set in the design system.
Design QA example: Used the design as an overlay to compare the implementation – on Android, the layout bound feature was very useful
MAD Kit, was an initiative I took to improve the standards of the design specification documents.
While I was drafting documents for the design components, I realised that we were reusing most of the visual styles.
Also, when I reviewed other design specification documents from other product designers, I noticed the visuals they have used differ from one designer to another. Sometimes they have not highlighted key important elements for the engineers.
So, as the design system owner, I saw an opportunity to improve the quality of these documents. I created a child design system (a UIKit) and included all the assets that a designer needs to create visuals in their design specification documents. I named it “MAD Kit”. MAD stands for Measurement and Documentation.
In the MAD Kit, I have included the following,
Annotations
Measurements (Size and the distance)
Corner radius
Device frames
Equations
Design system specs (Typography, UI Components, Shadows and Colours)
Animations
Other elements: Lines, Shapes, Skeleton loaders
All these are Figma components and the designers can easily customise and reuse them in their documents.
The MAD Kit is one of my favourite projects. It was so satisfying to see the success.
Informative documents → Apart from making the documents look nicer and easy to digest, my other intention was to make sure the documents contained all the necessary details. With the support of MAD Kit, with all the necessary visual elements, the documents transformed informatively.
Supporting Modular UI Components → MAD Kit’s Design system specs allow designers to define which Component, Colour or Typography style can be reused as a Modular Component. So the engineer is aware that building those from scratch is unnecessary, whereas they can reuse the modular components instead.
Consistency → Sometimes engineers get to co-operate with designers from other teams. With the help of MAD Kit, all the documents look similar across all teams and it is easy for the engineers to digest the documents.
Time-saving → The designers really appreciate the MAD Kit because it made their documents pretty, structured and well informed. Also, it helped them save their time significantly.
↑ Feedback received from fellow designers
1
By building Modular UI Components and also from the MAD Kit initiative, we managed to gain significant improvements in the deliverable quality. We have carefully validated all the components before releasing them. Now, whenever we use Modular Components, designers do not have to review those sections of the design in depth.
2
After releasing Modular UI Components, we saw immediate results. The number of UI bugs went down drastically. So, the quality of the deliverables increased.
3
Thorough component documents were very helpful for the designers. Now they are familiar with the limitations and guidelines of components. Because of the success in the mobile design system, the other design systems also started adapting to our modularisation and documentation methods.
4
My original plan with the MAD kit was to make documents better for the mobile team. But now the MAD Kit is being used by designers on other platforms as well.
↑ Quality of the deliverables
This project was quite challenging yet very exciting for me. I spent a significant amount of time reading about existing modular component libraries, such as Google Material Design. I studied how the documentation was done on those platforms. With modularisation, I managed to brush up my knowledge on the technical aspects of iOS and Android, how components work on each platform and as a designer, how much I can contribute to finding methods to fix technical issues along with engineers.
The MAD Kit is one of my favourite projects. It was an initiative I took after seeing the need. Now the MAD Kit is used on every single design document we write at Setel, by every designer. It’s very satisfying to see how successful and effective the MAD Kit is as well as the Modular Components.
