DesignOps action plan
How to demonstrate the impact of DesignOps?
If you’re new to DesignOps (Design Operations), you might wonder first of all, what DesignOps is and why you should you care?
You could say DesignOps turns the sometimes fluffy and mysterious design practice into something more understandable, systematic, and integrated to the organization.
DesignOps includes tools, methods and practices to for example:
- Finding out how developers, designers and product management best work together
- Clarifying roles so that everyone knows what’s expected, and providing clear career paths for designers
- Turning usability and customer satisfaction data into process improvements
- Assessing the value of design and product creation investments
- Evaluating the company’s customer experience
- Enhancing employee wellbeing and motivation
- Fostering a more transparent, innovative and creative culture
Reflections as a Head of CX
I worked as a Head of Customer Experience (CX), leading a product design team in a large tech company, when I was still only learning about DesignOps.
Now, looking back, we did many things well. We started using a Figma design system in the product function and defined a product creation process. We enhanced developer & design communication, carried on design vision and principles throughout the touchpoints, communicated status, did usability testing, reacted to feedback, and created a well functioning design team.
However, if I were in that role again, there are some things I would do differently.
What I lacked was a systematic approach: a clear action plan and a vision for DesignOps, as well as metrics to follow up and evaluate our success.
DesignOps action plan
To be honest, it is sometimes the simplest things that are the most hard to do. In its simplest form, the DesignOps plan is like any plan:
- Find out the current status
- Plan & design together with stakeholders the desired changes
- Monitor progress and evaluate success
- Repeat
With DesignOps tools we can address both the organization and team needs, as well as the product and business needs. I'll examine how we could use the plan in these two contexts.
- A. People and teams
- B. Products and services.
A. People and teams
One thing that came up often in the company I worked in, was the worry if developers and designers work well enough together.
Reflecting on this, I've realized we could have addressed this issue better by taking it as an objective for the DesignOps plan.
1. Finding out the current status
First one need to understand if there indeed is a problem.
- We could send a survey to all the development and design team members, asking about key questions around a topic. Then we can find out some data, instead of for example just one vocal person dictating the discussion.
- Also, we could do interviews with different teams’ scrum masters, or hold a workshop together with the teams to identify what’s working, what’s not, and how collaboration can improve.
- Speaking directly with particularly unhappy individuals can also provide valuable insights, help to see the problem in their point of view, and make them feel heard.
2. Planning & designing together with stakeholders the desired changes
The research material should be collected, organized and anonymously presented. Action points for improvement should be discussed with the stakeholders.
Design tools can facilitate this process by converting issues into "How Might We" questions, enabling collaborative solution design. Once one or two solutions are chosen through a voting process, a commitment to implementing those changes is essential.
For instance, in the case of communication between designers and developers, a key issue was that developers desired a dedicated designer available to them for longer periods. Due to a shortage of designers, they had to split their time among multiple developer teams. One potential solution could involve hiring additional designers. Other options might include increasing designers' involvement in daily meetings with developers or improving the planning of design tasks.
3. Monitoring process and evaluate success
Perhaps the hardest part is to commit to the changes, and see if they had any effect.
What is often forgotten: We should follow up the plan after doing the changes. After half a year send that same survey again, do that same workshop again, to compare if the answers have changed, to verify if we succeeded with the change or not.
This is difficult, because by this point the organization has usually already forgotten about the topic at hand, and something else is the new hot potato. ;)
4. Repeating - with the same constraints
With the comparative data we can see how this same thing has changed over time, and get proof if the investment and actions we've taken has changed things to a better direction. By analyzing trends, we can identify improvements and potential new challenges. For example, in addressing the issue of design and development communication, we can see if the investment of hiring new designers has paid off.
Measuring with the same constraints; doing the same survey, same workshop repeatedly every year, is the key to get comparative data.
Comparative data is a simple but effective tool applicable in various contexts. As well as measuring DesignOps changes, you could use this same recipe for measuring impact of design, design maturity, or employee wellbeing.
It is a great tool to know if you have succeeded or not, and in what parts the investment worked and what could still be improved.
B. Products and services
The same comparative data tactic can be also used when measuring product ROI or customer satisfaction. Of course there are also other ways also to track how the products bring value to business (loyalty, NPS, onboarding funnels, time of tasks etc), and more about those in another blog post.
Comparative data to measure concept & final product
One way to use this comparative data technique, which could easily be done by the UX designers, is to repeatedly measure the usability of design concepts with SUS, CSUQ, or UMUX questions.
By asking in the end of the usability test the same questions, e.g. how easy was it to do the main tasks, we will know how well the design succeeded, and get comparative numbers of level of designs over time.
The same test could be done to the released product. Then we can also identify if there are gaps between the design and the developed product.
Systematic research & UX researcher
Another thing that I would do differently would be to systematically gather all interview results and all the research results into some Figma and Confluence, so that we could keep a big picture of what was tested and where, and what were the results and actions taken. Then we could learn from the past insights when similar issues rice again.
Back then I didn’t hire a UX researcher, because I thought that UX/Service designers themselves could do the research of their area while they also do the concepts and detailed design of that same area. However, I noticed that there was not enough time to do measuring and discovery, as the focus was too much on delivery. Thinking again, now I would hire a UX researcher.
Time
If DesignOps, research and measuring are so useful, why don’t companies do it more? Most common answer is time. It’s more important to focus on delivering the products and services, than to improve processes and employee wellbeing. Improving organization's processes and culture is beneficial for the business, as it translates to better products and services.
If there is a will, but no way for current personnel to be able to start a DesignOps project, then, you can call us in Alpha Design Partners. We'll gladly help you to set up DesignOps action plan, and systematically follow it long term so that you get actionable results on the topics you want to improve, for example the designer developer collaboration.
DesignOps training
If you want to study this topic more and connect with like-minded peers interested in DesignOps, welcome to our two-day DesignOps training in October.
Blog post photo by Nik on Unsplash
