Design Operations initatives at GoBear (part 2)
ROLE
Product Design Lead
WHAT I DID
Operations Processes, Design Systems
YEAR
2019 – 2020

Initiatives

GoBear was a financial product aggregator that provided customers with a place to search and compare insurance, credit cards and lending products.
Market: Singapore, Hong Kong, Vietnam, the Philippines, Thailand, Malaysia and Indonesia.

Apart from tooling, I also worked on initiatives that aimed to improve our workflow as well as collaboration processes.

Workflow

  • File Organisation Template and Guideline
  • Design Kit Documentation Guideline and process

Governance & People

  • Pair design & resources allocation
Above
File Organisation Guideline

File Organisation Guideline

Challenges

With the migration to Figma and some fundamental changes in the way we worked e.g. sharing links our source files vs. uploading only "final" screens onto an inspection tool like Invision or Zeplin, we needed a process in place to help designers organise and communicate their design artifacts.

Figma has an infinite canvas which means there's no starting point when you first create a file. This also means every designer will have a different way of organising their user flows, wireframes, UI, specs and design & implementation status. Naturally some methods are better than others.

From our initial review of all working files and from speaking to our partners in engineering and product, we found:

  • It was difficult to navigate some working files since there was no inherent structure when landing into the file
  • It was difficult for someone to pick up work from others since there was no way to know which design was done / in production / in development
  • It was difficult to know who was in charge of what since one file could be shared by multiple designers working on the same vertical

Gathering insights

I decided to interview all our designers and walked through their ways of working and organising their files, keeping in mind the feedback on which files our partners enjoyed working in and which files presented challenges.

We identified the some clear needs from our team members:

Our designers

✺ Needed space to explore and experiment in the file
✺ Needed to hand over work in different stages e.g. wireframes for review, different versions for review, locked-in design for implementation, improvements etc...

Our engineers

✺ Needed to access and navigate to the correct file/page/version for review and implementation
✺ Needed to access and inspect specs

Our product managers

✺ Needed to access and navigate to the correct file/page/version for review
✺ Needed to keep track of progress, which design is currently in development, in production

Both PMs and engineers

Had preference for:
✺ Files that had clear statuses and versions
✺ Files that had a clear orientation (left to right, top to bottom) and way-finding

Decisions

We decided to:

  • Create a template for file organisation based off of what our partners and other designers chose to be the best method amongst ourselves (A file from our Senior Product Designer, Suling Wong↩︎)
  • Add improvements based on feedback from our teams like clear owner to pages on Figma
  • Create a guideline to refer to
  • Leave room for individual improvements

To help aid higher level navigation, we provided a structure that's loose enough to give each designers space to think and create their own workflow but also enough organisation to help our partners easily navigate within their given team space and even other team's spaces.

Above
Team, project and page on Figma

Team

Each designer was already assigned to a team which belonged to a business unit (i.e. Brokerage or Lending). We assigned each "Figma team" to a business unit.

Project

Project was used to segment the units further into verticals. Designers were assigned into their vertical (Travel Insurance, Car Insurance, Banking) and would have their own corresponding project space.

File

File was used for features or products within the vertical. Some designers preferred to have everything in one file, some preferred to break a complex project or product into multiple files. We left this to the designers to decide since they knew the project's complexity best.

Page

Upon entering the file, we decided to use pages to:

  • Manage status of features (in development, in design)
  • Manage stages (exploration, wireframe, UI, prototype, owner review etc...)
  • Manage themes & features (onboarding, happy flow, unhappy flow)
Above
Canvas template

Canvas

The most important part though is the Canvas. We defined a clear hierarchy and flow to the Canvas.

From top to bottom:

  • Last updated date and owner of the page (since multiple designers could be working in one file)
  • Title of flow
  • Device (desktop/mobile)
  • Status (In Design/Owner Review/Approved or PROD/UAT/DEV/Backlog)
  • Frames (screens)

From left to right:

  • Steps in the user flow
  • Additional specs

Utilities

We also created utilities components to aid with marking statuses on the canvas and adding feedback.

We introduced Page Automator plugin↩︎ to help folks create new project using the pre-defined structure.

Above
Utilities to go with the template

Workflow

A workflow was defined to help designers update their statuses and communicate the new workflow to our partners in product and engineering.

Above
Workflow to update screen status

Reality and improvements

After the initial workflow and file template was rolled out we continuously tested and improved it along the way. Some parts of the original plan was cumbersome and naturally abandoned in place of better practices.

Instead of moving screens around to show statuses:

  • We relied on updating statuses of the page as well as the flow
  • We only duplicated the screens and moved them to the final stage of implementation i.e. in Production

Instead of updating the statuses of individual screens:

  • We update statuses of the individual flows instead

Results

The File Organisation Guideline helped the design team introduce more organised screens and flows that helped aid our partners and other designers in navigation. We received positive signals from our partners through direct feedback and retrospective sessions in individual teams.

However, 50% of our design team still struggled with adopting the workflow which prompted us to follow up frequently with task specific feedback and checked in 1-1 with each designer on how to help get them onboard.

Above
The improved template in action

Design Kit Documentation Guideline and process

Riding on the initial success of our File Organisation Guideline, we also worked on improving our Design Kit documentation.

Challenges

The transition from Sketch to Figma↩︎ was meant to encourage the non-core members of the design system "team" to contribute to the Design Kit. However, we later received feedback that our designers still found it daunting and more than half of the team was hesitant or lack confidence in contributing to the Design Kit.

  • This was due to varying levels of skill in tooling (using Figma) and in creating and updating components.
  • Some team members also lacked opportunities due to the nature of the projects they were working on (using legacy designs).
  • A lack of documentation of the Design Kit also meant designers weren't able to identify opportunities for reuse or improvement to the existing components.

Amongst other efforts such as pair design/review and assigning components tasks for designers to get hands-on experience. These challenges also presented a need for a Design Kit Documentation Guideline.

Above
Design Kit Documentation Guideline

Anatomy

To tackle unfamiliarity with tooling, and creating and updating components. We decided to start from the fundamental with a guide on how components work in Figma, as well as applying it to our context i.e. how components work in our Design Kit.

Above
Design system anatomy in Figma

Structure

A detailed guideline of how our Design Kit was structured, was also included and updated to the latest version based on our design system refresh plan.

We also took the opportunities to further document best practices so this knowledge didn't get lost amongst designers of different skill levels for example:

  • How to organise components on the canvas
  • Naming convention for ease of component swapping
  • Numbering to organise most used components on top of the dropdown list

Guideline for guideline

To set the right expectation going in, we also drafted a documentation "guideline for our guideline" 😄 loosely based on Material Design.

However in order to further provide context for our designers as well as help new designers level up in tooling, we also added:

  • Applications/examples
    Give examples of where the components have been used
  • Figma notes
    Document how to use this component in Figma. e.g. list out layers that can be toggled hidden
Above
Guideline for our guideline

Reality and improvements

In reality, as the design system refresh plan was on-going at the same time as other high priority features/projects, we needed to quickly add documentation to our existing components while working in parallel on the refresh. Though we could rely on the guideline, some other information was not useful at this juncture e.g. Page organisation.

Guideline and documentation did play a crucial role in implementing processes, however, what's even more important was to identify how each designer learned and adopted processes to cater to their needs. Adoption and maintenance was also difficult and continuous work. A single template or guideline did not do this work of advocating for adoption.

This could be tackled through personalised feedback and pair design. Setting the right expectation and giving feedback through formal (Design Review) and informal (1-1) sessions proved to be effective for folks who needed a little more support in their learning. Having a pair designer could also feel like "a guardian" that boosted designers' confidence in contributing to the Design Kit.

Pair design & resources allocation

Challenges

Similar to any other designers who work in cross functional teams, each of our designer needed to embrace simultaneously 2 team cultures:

  • Product team culture: outcome oriented
  • Design team culture: quality oriented

Despite having processes for Team Updates and Design Review in place, we started facing new challenges as we transitioned into this squad model late 2018 and early 2019:

  • Product teams and designers often ended up working in silos from other product teams and designers → no visibility into the end-to-end system.
  • Duplicate work occurred across the different verticals that used the same system e.g. Travel Insurance, Car Insurance using the same purchase funnel and infrastructure.
  • Separate teams working in the same vertical (e.g. Growth vs. Purchase) implemented oolutions that may affect the experience later down the customer journey or designers weren't able to make changes to different parts of the customer journey despite it being a system.
"While all of these smaller teams (e.g. squads) mostly operate independently, it’s important that they remain in contact." – Org Design for Design Orgs, Peter Merholz, Kristin Skinner

To continue supporting the outcome oriented goals of the product team, improving efficiency for our designers, and raising the quality of our wor, we looked into pair designing as a way to tackle the new challenges.

Desk research↩︎ showed that pair designing is often used to encourage more in-depth discussion and feedback amongst designers when a large setting (like our Design Review) doesn't afford it. Designers in a pair design relationship also act as partners instead of enacting just a "feedback" relationship.

We worked to adapt this process into our team.

Responsibility mapping

The first step in structuring our pair design process was establishing clarity in team structure and responsibility mapping.

Above
What do designers work on?

In order to decide where designers should be allocated we outlined criteria for consideration:

  • Designers will be allocated to projects with the highest priority
  • Designers will be allocated to projects where they have the most relevant domain expertise (this could be in regards to their familiarity with the vertical or the part of the user journey)
  • Designers will be allocated based on the workload they have or the projects require
    e.g. a designer with a big project on hands vs. someone who can take on more
  • Only one lead designer per project (vs. 2 per project) but they can and should pair with others
  • Depending on the situation at hands, we need to allow for flexibility
    e.g. all-hands on a big feature → allow for more than 1 designer per project
Above
How to assign responsibility

Pair design

With clarity in responsibility mapping, we could clearly see the relationship between designers and how they could start pair designing vertically and horizontally (illustration below).

  • Designer (1) and (2) and designer (3) and (4) could pair design to support and keep each other informed on the holistic experience for their respective verticals.
  • Designer (1) and (4) could pair design to support and keep each other informed on the infrastructure underlying the purchase experience across verticals.
  • Designer (2) and (3) could pair design in anticipation for future resource re-allocation.
Above
Pairing designer off vertically, horizontally and even diagonally

Process

We formalized this into different sessions that designers could take initiative to conduct and outlined the topic of discussion for each session to make the best out of the relationship:

  • Pairing between designers working on the same part of the journey but different verticals:
    ✺Requirements for context
    ✺User experience alignment to highlight areas of both verticals that can be applied/reused or will be affected by changes made in another vertical
    ✺Review and feedback
  • Pairing between designers working on different parts of the same vertical:
    ✺ User experience alignment to highlight changes to the journey that could affect other parts of the funnel and discussion to resolve

Priority

We went a step further to set up regular alignments between the Design Lead of the Brokerage team and the PMs of the business unit to ensure we were aware of upcoming work to prepare for resources allocation. This was also an opportunity for me to exchange feedback with PMs on future resources need.

The Brokerage Design Bi-weekly Catchup followed the Priority alignment meeting to keep designers informed. This was also where allocation of designers was discussed, and designers could be encouraged or themselves proposed to pair design when needed.

Results and room for improvements

After a while we realised parts of the process wasn't working. Since we also had our larger Design Team Weekly Update and Design Review, the Brokerage Bi-Weekly Catchup became repetitive and time-wasting so we scrapped the meeting altogether.

Upon implementing this process we went through a re-org back into the service model i.e. 1 design team providing service to the product, marketing teams. The structure proved to continue working to weather even larger organisational changes.

With frequent pairing, we reduced the number of double work/projects to 0. We were kept in sync of the different changes happening to the infrastructure, vertical and user journey we were working on.

Next