Revamping Design Operations @ CARSOME for 12 Million+ Active Users
Summary
CARSOME is Southeast Asia’s largest integrated car e-commerce platform, and Malaysia’s first unicorn startup. My role involved working on a few products - namely, Internal Tool products including CARtracker, CARinspect and Business Finance Admin Dashboards, and the Consumer Facing Website & App.
However, towards the end of my role, I predominantly found myself working on improving DesignOps for our team of 24+ product designers.
Duration
12 Months, December 2021 - December 2022
Tools Used
Figma, Figjam, Lokalise, Notion, Jira, Trello, Gitlab
📍 Malaysia, Singapore, Indonesia, Thailand
A case study TLDR.
1. Learning how to deal with complex & ambiguous problems that don’t really have a defined or clear path on how to do things. I really learnt how to tackle problems that don’t have a clean roadmap.
2. The importance of collaboration between teams & stakeholders as a designer. The fact that designers do not exist in a vaccum, and the quality of our work depends on how well we can collaborate.
3. The potential financial value (both in ROI from great design & in preventing future costs by reducing design debt for teams) of embedding DesignOps in an organisation. Good design is good for the business.
CONTEXT
A few months into working at Carsome, I realised we had a problem at our hands. With 24 designers in our team, almost 100 engineers, 13 products amounting to 100+ Figma files in 4 language translations, we were struggling with establishing a consistent and thorough process for how we do things - as it goes when a design team is scaling rapidly.
This came after my own experience of working in the team and conversations with fellow designers. We were spending way too long at the start of a PRD to find the latest design screens, double-checking handover details depending on the engineers we worked with, and struggling with maintaining the hygiene of our Figma files.
It was clear we had quite a DesignOps nightmare to deal with. This was a great oppurtunity to change how we operate and put DesignOps at the center of our work for a team serving 12+ million active users.
1. Exploration
MY GOALS WITH THIS INITIATIVE
After sitting with this problem for a while, I decided my main aims with this undertaking were as follows:
- Make DesignOps a priority within CARSOME as an organization.
- Empower designers in the team to produce the best quality of work.
- Find ways to ensure consistency across all CARSOME products (over 13+ products)
- Reduce designers’ time spent on redudant tasks that can instead be spent on other things (ie: research).
- Improve collaboration between PMs, engineers & designers.
- Help improve the experience of new designers when they are onboarding into the team.
DESIGNOPS PAIN POINT WORKSHOP
I chose to explore the extent and nuances of this problem over a couple of months, using a variety of sprints, workshops, visualisation methods & internal team research.
Firstly, I found it imperative to sketch out & plot our current workflow before we began working on building a new one. This workflow aimed to understand
- What each of the steps are from the beginning of getting started on a requirement, all the way to when it is in a live environment.
- Who the key stakeholders are in each of these steps. (pro tip: emojis are your best friend for this!)
- What files, guidance or components we currently have in the DesignOps ecosystem for each of these steps. (eg: design systems, naming guidance)
With a clear idea of how things currently look, the next step was to explore what our current pain points were in our design process. There were two major sources that informed these pain points. Particularly:
1. Conversations (formal & informal) with designers, design leads, engineers & PMs.
2. A workshop held specifically to address concerns with the internal use of Figma Files.
During the workshop, it was clear that there are three overarching areas where most of our team’s problems lie. Using an affinity map - I sorted these into the following categories of pain points:
- Communication - between teams, but also in the way we communicate our designs, from the way use cases are written, to the breakpoints needed for each requirement, to designer notes.
- Figma File Structure - there was a particular concern with duplication of screen variants across files, and designer time spent on finding them. Additionally, there was the concern that the way each requirement/figma file is arranged differed based on the designer in charge.
- Design System - Finally, there was a consistent issue with not having key screens documented as components in the design system. This also included commonly used screens such as the homepage, ‘About us’ page etc.
We were essentially targetting three overall problems: Inconsistent Inter-Team Processes, Inconsistent Internal Processes, and Unnecessary Time Wastage.
2. Solutions
As part of the pain points workshop, the team brainstormed solutions to the highlighted issues. The goal at this stage was to brainstorm as many solutions without thinking about things like viability and effort.
Using the structure of the affinity map above, I then sorted these solutions across the same categories as the pain points. To me, this was the most imperative part of my initiative, and helped me tackle both the problem statements I had highlighted earlier in my work - ensuring I was on track to meet our goals.
Marrying all my work so far, and bringing the pain points workshop to an end, I mapped the pain points against the workflow, to understand the breadth and extent of how DesignOps (or a lack of) might affect the design team.
PRIORITISING MY SOLUTIONS
So I had a pretty clear idea of what we can do to improve and optimise DesignOps within CARSOME, however an essential part of the process was to prioritise these solutions. This was done based on a prioritisation value, which used the Impact Effort Prioritisation Matrix as its basis. This was a tweaked version of a formula derived by my colleague, Kah Yee Chiang. Particularly, there were 4 key values used to determine the score:
1. Internal Team Impact - How much does it impact the consistency, efficiency & quality of the design team?
2. Inter-Team Impact - How much does it impact collaboration between PMs + Engineers & the design team, which in turn directly affects us?
3. Initial Effort Required - How many people + hours will this solution take to set up?
4. Maintenance Effort Required - How many people + hours will this solution take to be updated & functioning?
I then documented 16 of our DesignOps initiatives using Notion. This gave me a clear picture on what to tackle first. Below is the template I used.
BUILDING THE CARSOME ‘WAYS OF WORKING’ DOCUMENT
From the prioritised initiatives list - it was clear that one of the key deliverables that will help us to solve some of the pain points affecting the design team would be building a ‘Ways of Working’ document that would serve as the ultimate source of truth for all things related to the CARSOME Design Team process - for designers, and also for other stakeholders.
This was intended to host all the information & material anyone could need about our end to end process, including internal guidance on all things including file structure, Lokalise (since most designs at CARSOME have to be translated for the Indonesia & Thailand markets), breakpoints, and developer handover to name a few. It was also designed to host ‘Project Material’ that each requirement would use regardless of what it is, including Use Case Templates, File Covers, Translation & Breakpoint Ribbons etc.
