Overview
While working for Growth Advisory company with two digital products I started noticing multiple recurrent issues within my agile team, all of them related on how we were conducting design processes, which we inherited from another contractors.
A solution was ideated, rather than keeping these design principles and processes I decided to start building a DesignOps solution that worked to serve the company and its members, with the idea that team members may come and go but the processes will be stablished.
Work Done: User interview, DesignOps, validation, strategy
The Problem
While working inside an agile team for a Growth Advisory company we faced a problem, we inherited a Design Operation we didn’t create and wasn’t created for the current demand in terms of production inside the company.
Some common issues we face range from issues with hand-offs to developers to stakeholders being unable to navigate through simple prototypes. All across the design processes, we faced different challenges with different members of the team and external stakeholders.
Since all our capacity as designers were committed to focusing on delivery rather than Operations itself, I ideated a Lean UX process that took two sprints (4 weeks in total) where I aimed to develop a test a new Design Operations that suited the whole process within the company.
Since all our capacity as designers were committed to focusing on delivery rather than Operations itself, I ideated a Lean UX process that took two sprints (4 weeks in total) where I aimed to develop a test a new Design Operations that suited the whole process within the company.
The process
I like to start always with laying down as granular as possible describing the steps I will undertake during the process, not to be constrained by it but rather find a guide to where to locate myself all along the way.
A few days before finishing a spring I started defining the steps and time it will probably involve to construct these solutions, during the first sprint I would dedicate myself to gathering as much information as possible (metrics, interviews, processes, etc) and constructing a possible solution (workflows, systems, files) these all will be put into test during the following sprint and from there they would be iterated.
*These solutions as always are susceptible to iteration at any point as needed so no solution is final.
Research
The first step was to take a look at the current operations model established inside the company where I was able to pinpoint the absence of a DesignOps strategy within the organization which resulted in a deeply uncoordinated and unsynchronized process that extended beyond the concern of design.
Right now it seemed as if the tools used within design tasks were meant to be used just by designers and their results only interpreted and used by them, rather than using the tools and processes to benefit the organization itself.
After conducting interviews with multiple team members and external stakeholders I also found out there were a couple of pain points that resonated with the previous findings, such as:
The main focus became to develop an Elevated Structure of Design Ops within the team, as we were working as contractors and wanted to develop a shared system that was documented and structured enough for teams to come and use it as they need.
Borrowing a page out of Systems Thinking we approach pain points as part of a systemic, sometimes complex, web of systemic issues that need to be addressed at different levels to find different impactful solutions.
With that in mind using the Iceberg theory we can see the composition of surfaced issues and deconstruct their root causes so we can better align on a whole array of solutions.
From there we used a matrix that allowed us to prioritize which tasks to do first and which to do later:
The first thing to tackle was to define an ideal workflow with the tools and processes we were conducting, starting with Figma and its usage and governance. For instance, rather than working on an individual design file where everyone has access to it, I decided to create layers or areas of work designated to different types of collaborators within Figma.
This is what the organization will look like, three different folders of a file, each one accessible to a different set of team members, each file will be constructed to contain flows, screens, and prototypes of one particular navigation section (since it is a pretty robust web/mobile app).
Within each folder, each type of file will have an extent of rules and pagination depending on the case (for example makes sense to have a page on design files to start sketching and multiple images for inspiration, rather than cleaning up and with fewer animations in files for external stakeholders)
Next, after identifying how we usually work during sprints within Tech Team I proposed this workflow to design new features or changes. A funnel that will dictate how to interact and identify at which stage each file or design is.
The idea is to move prototypes, flows, screens, and all design assets as they move through the design operations funnel and they will serve different purposes depending on where they live, this helped to serve the usage of tools and processes to improve the development process.
Validation
These ideas were materialized, all files were created, flows migrated, access managed and processes tested. During that week I was able to identify improvements all across solutions (for instance the Flow description cards weren’t that complete for Development files) and in general understand what stakeholders and team members thought and measure improvements in terms of time.
Some metrics I defined to measure the success of these solutions were:
1. Recurrent Requests to walk people over Figma prototypes (Reduced by 30 percent weekly)
2. Number of mistakes during design QA when new features were implemented (Reduced by 15 percent)
3. Overall size of design files (Overall files size went from almost a gb to 100 mbs )
1. Recurrent Requests to walk people over Figma prototypes (Reduced by 30 percent weekly)
2. Number of mistakes during design QA when new features were implemented (Reduced by 15 percent)
3. Overall size of design files (Overall files size went from almost a gb to 100 mbs )
Iteration and Final Results
With the needed feedback the next step was to implement it and last week was dedicated to that, final solutions looked like this:
Example of file organization and pagination.
Organization of Figma space
Description card intended to be used for interaction flows and prototypes.
Next steps
It is crucial moving forward to keep measuring the success of these solutions, plus I understand these are just a part of a big systemic issue, where teams lack knowledge on how a design team is supposed to operate within a company and its benefits.
Things like Design ceremonies, talks, and processes will be key moving forward to show the value of incorporating design processes within the company, plus moving forward it would be necessary to have a designated DesignOps specialist to ensure the maintenance and governance of all these processes
