DesignOps action plan
How to demonstrate the impact of DesignOps?
If you’re new to DesignOps, you might wonder first of all, what DesignOps is and why you should you care?
DesignOps turns the fluffy, mysterious design practice into something understandable. DesignOps includes the tools, methods and practices to find out for example:
- How developers, designers and PM best work together efficiently
- Clarifying roles so that everyone knows what’s expected, and provide clear career paths for designers
- Get data on usability and customer satisfaction
- How to know if investing in certain design & product creation has been a success
- Find out if the company’s customer experience is good
- Unify different touchpoints and brand experience
- Enhance employees’ wellbeing and motivation at work
- Lead way to a more transparent, innovative and creative culture, to make the company more resilient to changes
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 dev & 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 was missing was a systematic approach. A clear action plan and a vision for DesignOps. And some rigorous measuring, how did we succeed?
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 help either the organization and the teams, or we can help the products and business. Thus the DesignOps question can be related either to the
- A. people and teams, or to
- 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.
What I’ve realized now afterwards: There would be a better way to find it out, and find out where the problem really is. We could have agreed to take this topic as an objective for the DesignOps plan and start to work with it.
1. Finding out the current status
First you need to understand if there really is a problem.
- We could send a simple survey to all the development team members, asking about key questions around a topic. Then we can find out some data, instead of for example just one noisy and unhappy person dictating the discussion.
- Also, we could do interviews with different teams’ scrum masters, or hold a workshop together with the teams, and ask what’s good, what’s bad and how we might improve the designer-developer collaboration. How would they best structure the teams so that they would feel happy and productive at work? We might get some action points for both of the teams.
- And of course if we have identified some individuals who are particularly unhappy, let’s talk more directly with them about what the problem really is, so that they feel heard. This might be also the way to start, before the worries of communication not working gets widespread.
2. Plan & design together with stakeholders the desired changes
The research material should be collected, organized and presented, and plan with the stakeholders the action points on how to improve.
This might be done also with design tools, we can turn the problems into How Might We - questions, and design solutions together. Once one or two solutions have been voted, we need to commit to on making that change really happen.
In the example of the designer dev communication, one of the underlying problems was that developers wanted to have a dedicated designer available for them for longer time period, and because there were not enough designers to dedicate for one developer team, designers had to split their time between two or even three developer teams. One solution could be e.g. hiring a new designer. Others could be for example to make designers attend more dailies with devs, or better planning of the design tasks.
3. Monitor 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, and after half a year send that same survey again, do that same workshop again, to compare if the answers have changed and how.
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. Repeat - 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 has changed things to a better direction. With comparative data we can start to see trends, we can see some things are better, and perhaps some new problems have arisen. For example, of the problem of design & dev communication, we could measure if the hiring new designers is paying off and has it made things better.
The measuring with the same constraints; doing the same survey, same workshop repeatedly every year, it’s a key to get comparative data.
Comparative data is a simple but effective tool that can be used in various other contexts as well. It is a key 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 designers in the UX circles, is to repeatedly measure the outcome of UX prototype tests (with SUS, CSUQ, or UMUX-related metrics).
By asking in the end of the test the same questions, how easy was it to do something (e.g. the main tasks) overall quality, visuals, etc, we will know how well the design succeeded, and get comparative numbers on how well the designs generally have been, and which area could need more focus in the future.
The same test could be done to the final product after it has been developed. Then we also get comparative data if things have stayed the same, after actually bringing the feature alive. How big are the gaps between concept and final product. If data is not looking the same, dwell more into the whys and open feedback, or take some actions to change, and then test again.
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 boards, or Confluence pages, so that we could keep a big picture of what was tested and where, what were the results and actions taken. On the day when the same topic would come to the design table again, we could see what didn’t work before. It could have been useful when new designers started working, and useful also to report in which ways research was paying off.
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 – a bit of the product team thinking there as well: one full-stack-designer in the product team. However, I noticed that as the focus is always on the delivery, not enough time is put to into research and measuring, and thus we cannot prove if we are doing things right, cannot get comparative data on how we are doing, and there is not enough time for discovery either. Thus, thinking again, now I would hire a UX researcher, and would identify plenty of work that they could do.
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 employees’ wellbeing. More important to bring something to market fast and fix it afterwards, than to test beforehand how it would be perceived, even if the cost of preventing it would be 10 times cheaper than fixing it afterwards. It would be great to find out actual numbers of how much preventing something saved the company money.
Honestly speaking, it might also be a question of trust. If business is good and the connections are good and the design leader is trusted in the top management, there is no need to prove everything. But especially in economic downtimes, if there is doubt of what design brings to the company; measuring the financial value that good design, products and customer satisfaction brings to the company might help to alleviate those doubts. Even if you feel there is enough trust, it won’t still hurt to get some more objective data to see in what scale your assumptions were correct.
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 will gladly help to find you the answers, and also keep up the long term measuring and follow up so that you’ll systematically get actionable results. The topics can include what you want to improve, for example maturity of design in the company, customer satisfaction and how to improve that, or some specific problem you have in mind, for example improving the designer-developer collaboration.
DesignOps training
Welcome to our two-day training of DesignOps in May or October: https://professio.fi/product/designops/
