Two years of the DesignOps journey from scratch at Trend Micro
It has been almost two years since we started the Design Operation (DesignOps) discussion. Back at the time, Trend Micro had just started to adopt DevOps practice. The whole company’s R&D teams are transforming to fit into the new working mindset. As they sped up the work pace, the design team’s transformation to keep up with the process was close at hand.
Design Team, the bottleneck?
Before the transformation, there were rumours that we, the design team, were the bottleneck of a project. The time-consuming design review process held them back. More and more development teams decided to skip the design team, to release their feature based on their previous experience.
Well, we have to admit they somehow had a point.
To support a feature release, there are usually members of 3 functions that support a development team: a UX designer (UXD), a visual designer (VD), and a technical writer. Back when the online co-editing design tools were not popular, each function had its best practice on different tools.
- A UXD created the wireframes and UX spec on Axure. After uploading the wireframes to the file server, the UXD created a Jira ticket to the corresponding visual designer and technical writer with the wireframe URL attached.
- The VD recreated the UI on Photoshop and Sketch, marked the visual spec on it and then exported the mockups.
- The technical writer replicated the mockups to a Wiki page and noted down the refined UI wording next to the screenshots.
- The UXD passed the wireframe URL, the exported mockups, and the Wiki URL, to the development team.
The process worked in the waterfall development practice. However, it might not support the DevOps practice in sprints. The process was inefficient, needless to say, it is common to have back and forth adjustments before the design is finalised. The awareness triggered the DesignOps transformation journey.
Transformation step by step
DesignOps is a huge topic. It covers the collaboration within the design team and between stakeholders, design consistency, design practice sustainability, design impacts, and more (see DesignOps 101 from NN/g). Under the limited resources, the design team members had to continuously deliver the projects while building up the DesignOps practice. It was important for us to break down the scope, and organise our goals.
Enhance the original design process
The pain points were clear in the original design process, and our initial goals were simple.
- To provide a single source of design delivery to the stakeholders.
- To reduce duplicated works within the design team.
To achieve that, we had to find a tool that meets the requirements of all functions to get their job done:
- A tool allows UXDs, VDs, and technical writers to co-edit in the same file with good performance.
- A tool supports the design component library so that designers won’t need to create the same components all the time.
- A tool allows front-end developers (FEDs) to view the design spec explicitly.
The team studied different tools and validated each tool for around 3 months. We used them for design delivery, tested out the functions and collected feedback from the stakeholders. Finally, we chose Figma as the base of our DesignOps practice.
Let’s build a design system!
Collaborating on the same tool was a good start, but not enough. With more people co-editing on the same product, it was important to maintain design consistency. And the consistency was not only in the design deliveries across different designers but also in the implementation. The overall look and feel of the customer-facing interface. We therefore aimed at building a design system that benefits VDs, UXDs, and FEDs. It contains two subsystems:
- An asset library on Figma, defined and built by VDs, where the UXDs get the design components from.
- A component library on Github, a centralised repository for FEDs.
To us, the main challenge was not about what should be defined in a design system. Supporting a rapidly growing product means the requirements come in time. Sustainability was what we concern about the most: How to keep the component library and the changes in the Figma asset library in sync?
We first focused on tokenising the fundamental factors, such as colour, shadow, typography, etc. A token is like a reusable building block, a variant, the unit of a factor. VDs and FEDs co-maintain the token-value mapping table, which is applied to all components/assets that leverage the tokens. Once the correlation was built, the FEDs just need to ensure the new components were built with the token, the outcome would then follow VD’s design.
A company-wide impact
As mentioned at the beginning, the transformation was to support the DevOps practice. Well, instead of support, it was more of a collaboration. The system does not run by the design team. Without the FEDs implementation, and their help of contributing the components following our practice, none of it would work in a company with the FEDs across at least five sites.
We were lucky enough to work with the team running the pilot of the DevOps practice. With their feedback, we revised the workflow and share it with the entire company. To communicate with all development teams, we sent out emails explaining the values, played videos demonstrating the working models in the open area, and had face-to-face meetings sharing the experience. By the end of the first year, almost 80% of the teams were on board.
Scale up the Design Team
Not long after we achieved the first milestone, another transformation occurred: the reorganisation. The reorganisation brought up a brand new process in the company: from strategy discussion to feature validation. To support each phase, the design team had to scale.
Scaling up the team means the members have to provide higher value in the deliveries. The focus is no longer only on the design details, but also to reflect the business strategy in our design. To achieve that, the team identified two of the main topics as the next stage.
- Build up design standards, such as pattern guidelines and templates, to reduce design effort and enhance design consistency. Moreover, systemise the design and product document format, so that all information is in sync across the team.
- Create a project shifting practice that allows members to broaden the domain knowledge of their interests.
The design standards
Due to the resource constraints, we prioritised the most critical elements of the guideline that can best resolve our concerns at the moment. Taking one hour per week, the team discussed the patterns or user flows that had been brought up the most issues by the developers. We collected the use cases of the patterns that have been used across our product platform and turned them into guidelines.
Another critical factor for us is the documents that meet information transparency. With all the designers working on different projects built on the same platform, we need to know what is going on outside the pages each of us is responsible for since all workflows are all connected. We tried out multiple ways to sync up the information, such as a weekly stand-up meeting and Jira tasks visibility board, which turned out the most effective way is to manage a board for project updates, and create a template for each designer to fill out the most essential information as the cover of the design file.
WE as a shared resource
To scale up a team, one of our goals is that all UX designers can support each other, especially when our projects are all related. Starting from this tiny idea, we built up the project shifting practice from three dimensions: company projects knowledge map, personal skill chart, and the project shifting guideline. That is, everyone can decide which skill they would like to achieve, as the knowledge map is a reference showing the relations between each project.
This is our latest progress, and we are going to trial and see if it works in the following weeks. But as with all the stages above, we will constantly review it and adjust it when necessary.
Change is the only constant
DesignOps is a continuous process and we have worked so hard to come to a steady state. What occurs to me during the process (and still ongoing), is that no matter how the environment changes, embrace it as it’s one of the expected. The environmental changes can be external, that it’s due to company strategy. Or, it can be internal, with new members joining the discussion without an agreement. Regarding the entire project as an organism, it grows unexpectedly under the stimulus. The transformation never ends, but as long as you keep reviewing your goals and adjust the priority, it will always be transforming in a good way!