My design process for this initiative was no different than designing an internal/external product. I utilized a traditional design thinking workflow to proceed through solving the DesignOps problem.
With my business & user/employee objectives in full view, I needed to design a research strategy to not only uncover roadblocks in Andela's DesignOps program, but to also uncover what problems each team were having in using Figma, using the design system, and when collaborating between business units.
To uncover these roadblocks and problems, I conducted employee interviews, business unit focus groups, surveys, & collaborative design thinking sessions.
The insights from user research were high-value; the data helped generate a firm understanding of the issues each team was consistently faced with. It also elucidated a set of 6 core problems that needed to be solved, in order to get each team on the same page, and moving in the right direction.
At the outset, I knew I needed to get Figma organized. I established a set of principles to A) set the stage for cross-business-unit collaboration, and B) set the direction for clear patterns of organization. To bring these principles into daily action, I set standards on how files should be organized, how projects should be structured, how figma projects should flow from beginning to end, and how teams should properly collaborate in Figma.
The Design System, our products, and our ability to collaborate are only as good as the documentation that supports them. File structures and project flows can't be part of a scalable process without documentation to ensure it's repeatable and replicable.
In order to achieve velocity, scalability, and strong team collaboration, I needed to make sure everything was documented, and documented properly. I developed a clear understanding of how to document the design and product specs within Figma.
After going through several iterations of team structures in Figma, I arrived at an excellent final solution. Instead of structuring teams by business unit, district, or physical team, I found that organizing Figma teams by product was the clearest, simplest way to do it. This helped set the stage for the first working governance model.
Through my research, I found out just how bad the confusion was, surrounding roles and permissions in Figma. Employees needed access to teams, projects, and files that they couldn't find, couldn't join, or couldn't access. This meant sometimes Product Owners couldn't collaborate with Designers, Designers couldn't hand-off to Engineers, and Engineers didn't have access to comments from Product Owners & Designers. Further, sharing files to stakeholders and C-level leadership was a complete nightmare.
As an integral part of the ever-evolving Epic Design system, I established a governance model, with a clear overarching hierarchy for roles, along with clear guidance on how to gain the proper permission for each level of need.
My research showed hand-off was the single most frustrating aspect of employee experience. Quantitatively speaking, it was also the biggest bottleneck in our Product Development process. Now that we had structure and organization in Figma, a clear definition & process for specs, a logical team structure, and a strong governance process, hand-off could now be perfected.
I worked with my peers in Development to create comprehensive hand-off documentation and tutorials, which detailed the proper way it should be executed. We housed the documentation in our Zenkit documentation wiki, and within our standard documentation in Figma, itself.
I uncovered in the research that the team members often didn't have the right plugins installed, and didn't know which ones they needed to begin with. I included, in the documentation, a list of all the plugins, their links, and a brief how-to for each plugin.
Additionally, I made sure the team had access to all the Figma help resources, compiled a list of internal help contacts for Figma, and started building an Andela help repository for the most common Figma issues.