Apart from tooling, I also worked on initiatives that aimed to improve our workflow as well as collaboration processes.
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:
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
We decided to:
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.
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 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 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.
Upon entering the file, we decided to use pages to:
The most important part though is the Canvas. We defined a clear hierarchy and flow to the Canvas.
From top to bottom:
From left to right:
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.
A workflow was defined to help designers update their statuses and communicate the new workflow to our partners in product and engineering.
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:
Instead of updating the statuses of individual screens:
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.
Riding on the initial success of our File Organisation Guideline, we also worked on improving our Design Kit documentation.
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.
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.
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.
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:
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:
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.
Similar to any other designers who work in cross functional teams, each of our designer needed to embrace simultaneously 2 team cultures:
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:
"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.
The first step in structuring our pair design process was establishing clarity in team structure and responsibility mapping.
We looked at 2 core verticals: Travel and Car Insurance under the Brokerage Product & Design Team.
These 2 verticals shared similar steps in the user journey.
Design owners were assigned first to the vertical, then to the part of the user journey.
In reality this mapping looked more like this, and would change depending on priority and no. of designers we had.
In order to decide where designers should be allocated we outlined criteria for consideration:
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).
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:
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.
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.
