Defining DesignOps — my first 6 months as a DesignOps Manager
DesignOps is an emerging role, it’s still unclear to many what it entails. I began my journey into DesignOps at Co-op Digital in June 2019. Here is how I approached it, what I did, and what I learned along the way in my first 6 months on the job.
A week before my new venture into the mysterious new world of DesignOps. I sat Googling “What is DesignOps?”. I stumbled across talks from the DesignOps Summit and InVision’s DesignOps handbook.
The more I read (and I read a lot), the increasingly confused I became. Is DesignOps a design managers role? The efficiency of design? Perhaps evangelising design? Or recruitment and teams skills? Career progression? On boarding and people stuff? Software and tools? Or was it all of these things or something else?
I announced on Twitter I was to become a DesignOps manager.
And then the dreaded question was asked of me, “what is DesignOps?” I went with Andy Budd’s description of:
Design Ops is essentially the practice of reducing operational inefficiencies in the design workflow through process and technological advancements. — Andy Budd
Thanks Andy.
My first day on the job
Walking into the Co-op Digital studio there is a buzz in the air. Our Funeral care team are kicking off a disruption sprint, there is a real positive creative energy. Walls are laden with post-its and design mock ups, design principles proudly displayed. Design is happening, I love it already.
I’d be shadowing our Head of Design, Katherine Wastell for the majority of my first week. Katherine wrote the proposal to make DesignOps a thing at the Co-op, she has put a lot of time and faith into this role so I hope I can help her make it work.
Onboarding
I could see a lot of thought had been put into on boarding. I was given access to a handy Trello boards of key things I needed to know and do during my first day, week and month. And importantly to pace myself and take breaks.
Spending time with a product team
I wanted to learn how design worked in teams. So I took some time to sit with one of our product teams who were very much in delivery mode. They had a tight deadline, I tried to be as nosey as I could, without disrupting.
Despite the usual challenges of stakeholder management, this was a well oiled team. Excellent communication and agile rituals religiously practised. Designers and developers pairing with enough urgency and pragmatism to deliver.
I wanted to get a more holistic view of a project from the designers in the team. So we mapped out what a project looked like from the time our designers first heard of the project until it went live.
We could see that designers came into the project at different stages, and could be a little unsure of the strategy, I’d come back to this point later on.
Talk to the users
The most effective tool for solving any problem starts with listening. We have 50+ designers at the Co-op. They are the people I’m here to help, they are my user.
So I kicked off a project “Getting to know you…” I’d spend 45mins with each designer around the topic of “how can you do your best work?” we also chatted about our design system and tools they use to get the job done.
I was inspired to hear people’s journeys into their designer roles. Everybody was open and honest. People mainly talked about their current projects, politics and workflows in teams. I learned a lot and would highly recommend starting there.
What I did next was completely ill judged
I themed the findings from the interviews, anonymised them, removed a few comments, and then printed them out and stuck them on the wall. I was really nervous about doing this, but wanted to be as open as possible. However the words weren’t mine to be open with.
Lesson learned, this isn’t like theming a usability test, its looking at a department holistically, good, bad and indifferently. Words on a wall have no context, emotion and are faceless.
We removed the print outs and I apologised to the people involved. Not the best of starts.
Communicating my initial focus
From the interviews with our designers, I formed 5 pillars of focus:
- Design process: The alignment of process of design across disciplines and products. Mission: To make design frictionless.
- Design tools: Systems and services that enhance speed and quality of execution. Mission: To remove doubt in design.
- Design knowledge: The retainment, find-ability and sharing of knowledge and work. Mission: To make research accessible to everyone.
- Design strategy: Support for amplification & implementation of new and existing strategies. Mission: To provide momentum and measurement.
- Design culture: Design skills pairing, mentoring, and education opportunities. On boarding in teams and into digital. Mission: To be as experimental as standard
I made some posters to help give people an idea of what I thought DesignOps was.
We have 4 principal designers at the Co-op who look after business areas. They each have a specialist area of design too and run weekly community of practises.
I assigned a principal to each area:
- Content design - design culture
- Front end - design tools
- Interaction - design process
- Research - design knowledge
Design strategy I’d discuss with our head of design in our fortnightly catch up.
I’d formed a DesignOps org chart.
What to focus on?
Design seemed to be working better in some teams than others. This could be a good place to focus. I arranged to map out the lifecycle of a project with three more teams.
I blocked out time, booked rooms, but time and again my sessions would be cancelled. This wasn’t anyones fault, people have a responsibility to their team and product. Most teams were stretched as it was, without another thing to do.
Momentum lost
Up until this point I felt I had a bit of momentum. However the reality of working across multiple products and being an entity that people can’t yet see the value in, really hit home. Being a team of one in a role that few had heard of was going to require a lot of patience and resilience, this was going to be hard.
Working on multiple missions
Although I would have liked to focus on the design process this was going to take time. I changed my approach, I’d kicked off multiple projects so I could switch to where there was momentum.
My ultimate mission is to “Support designers to do their best work” I needed to find the right wave and ride it.
Mission: To make research accessible to everyone
Our weekly community of practises are a great way to discuss our missions with the team. I ran an activity around our mission “To make research accessible to everyone” in our research CoP. Along with lots of ideas on what to do three key themes came out:
- How we store and share research
- Where we talk about research and its impact
- How we include more people in research
How we store research. I spoke to our researchers about atomic research a method I’d brought to my previous role at the BBC. People were keen to try it, so we got a trial version of the software up and running. However at the time it was still very much in alpha so wasn’t quite ready for us yet.
I should have known better being from a design background. I decided to a step back and kicked off a project “Research the researcher” where we’d look to clearly define the problem. This risk of committing to the wrong system could waste a lot of time, and annoy already very busy people.
Where we talk about research and its impact. As the adage goes get your content to where your audience are. The wider business used Yammer so the team volunteered to share more there.
How we include more people in research. Other than in people’s personal outlook calendar we didn’t have a holistic view of when and where research sessions happening. Inspired by Sarah Rose Stokes I set up an observation schedule.
Researchers very rarely filled this in unless prompted. Unless there is an event to trigger somebody looking at this on a regular basis it could easily be forgotten.
The design brain
Our teams share a lot of good resources and links on Slack, so in a bid to try and be more inclusive with our knowledge I set up the Design Brain.
The design brain has views for Service design, Accessibility, User research, DesignOps, Analytics and data.
Mission: To remove doubt in design.
The Co-op design system was always going to be part of my job. We don’t currently have a team who looks after our design system, its mainly Matt as a side of the desk project. He’s done a fantastic job, of getting it up and running and keeping it up to date as possible.
Having spoken to Matt and our designers we could safely say that the design system was out of date and didn’t have enough information, so most people only used it when they started at the Co-op. And for the odd visit to see if anything had changed. Looking at the stats people were mostly looking for guidance on colours.
Our core components are documented, but there are a lot of components that are not, and are in use.
We asked designers to audit the product they were working on. We supplied a list of all the components we could think of and designers marked which ones they had in their product. We then assigned ownership to components, based on which was the most up to date. Designers took on ownership of up to 8 components each.
The matrix acknowledged that it wouldn’t be possible to keep our documentation up to date in the short term. Designers often asked on Slack if anybody had worked on a particular component. The grid gave an answer and an ownership. It also gave us something to work from whilst updating the design system.
A few months after creating the matrix I asked our designers how they used the matrix. Nobody was using it, people still asked on Slack. This was becoming a bit of a pattern.
Colour audit
Colours was one of the most visited pages in the design system. Our designers told us they struggled with the guidance on colours.
I formed a team of people who, had worked on colours, wanted to help and had time to help. We audited the colours across products and found we had 150+ colours in the wild, 50 of those colours were shades of grey. Our design system had just 27 colours.
I worked with a researcher, we talked to people who used colours, about how they used them and the problems they faced. We determined:
- Designers look for colours on Co-op websites
- Brand guideline colours don’t work on social media
- People wanted to know, where and why do we use the colours we do?
Again getting people together was tough and time passed. Products evolved and the business was working with an external agency on our colour palette. We shared our work with the agency and paused our work on colours.
Trying to keep the momentum
We kicked off weekly hacks to help rebuild trust in the design system. And keep the momentum going. A lot of re-platforming work is going on at the moment, so we’ve had to pause this too. As part of the re-platforming work, there will be new shared components built.
Mission: To provide momentum and measurement
I finally managed to map out the journey of a project with 3 teams.
I then retrospectively mapped them to the double diamond. I could see that even though our designers were following similar processes the results differed. One project changed direction, another evolved and one got ditched.
I knew that teams change, stakeholders come and go, the shapes of the problems change. It got me thinking how can we introduce a constant to this process? Can we measure the value of the design process.
The outcome of this was DIET (Design Impact Evaluation Tactic). DIET asks key questions and 3 common stages of a design project (Strategy, Problem & Solution)
A score is generated and recorded and over time we have data to measure from. Whether that be against expected product metric outcomes or team attrition.
DIET is a tool which is very experimental at the minute. I’ve had lots of great feedback and its opened doors for me being a team of one to speak to others around the world doing DesignOps. I also had the opportunity to do a talk about it. We’ll be doing an updated version of the talk at DesignOps conference 2020.
Mission: To be as experimental as standard
Our designers at the Co-op are the best I’ve worked with. New methods and tactics are often used as part of their work. Designers will bring techniques like “Wardley Mapping”, “Top tasks” and “Impact mapping” to community of practises in the morning. I’ve seen designers having seen the technique in the morning, implementing the technique in the afternoon.
Our principal designers run the CoPs so my role is here very much supportive.
The operations side of things
A lot of the operational side of things like, software licensing, keeping track of people, training budgets. Had been handled by Katherine (Head of Design) and our Principals designers.
When things get busy this side of the business is easy to push down the to-do list. So my role here has really been to audit things like software, how much are we paying? When does the license expire? Who is using it? Is everyone still actively using it? Is it providing value? Is there something better out there?
If things are left in a large org, a lot of money can be wasted. Designers will often get contacted by representatives from the companies too, so operations can deal with that side of things too.
Aligning with other Ops role
At the Co-op we have many Ops teams such as: Digital Operations, Tech Operations and Digital Skills. All of whom are doing what at some companies could be under the DesignOps umbrella.
I started to look at on boarding into design, I kicked off a journey mapping session going from the moment somebody decides to leave a job, right through to completing their first year.
On boarding stretches across 4 areas of the business. HR, Recruitment, DigitalOps and Design. Mapping it out, making a Trello board is great. But if I wanted to affect change or to not be doing the same thing as another Ops team. I needed to be aligned in my objectives with those other Ops teams.
Measuring the value of DesignOps
I spent a chunk of time trying to figure out how to measure my impact. I started by writing down a list of all the things that could be measured.
I listed about 40 things, I could look to measure here as an example of a few:
- Cost of meetings
- Cost of decision lag
- Track insights thru to deployment and further to impact/outcome.
- Design debt
- Design team health
- Project health
- + a load more…
It was going to take time and a varying amounts of effort to measure anything. I didn’t want to be using time that could have been spent on doing things. Especially in the early stages.
Design ultimately is to serve the audience who use our products. Therefore it makes sense to have a North Star of “User value & experience” with all measurement linking back to that.
Here is my work in progress version on measuring DesignOps impact:
North star = User value & experience
- Design impact - added value to outcomes and user knowledge
- Service standards - design quality, design efficiency & design principals
- Risk reduction - Digital accessibility, content meaning
You’ll notice all of these are very much focused around design. Team health which from my reading is often considered to be part of DesignOps I have omitted. Team health and culture are a massive part of design functioning well. However at the Co-op we have delivery managers and design leaders managing those areas extremely well. As you can see in this BBC video which features Co-op Digital.
The large and frustrating feedback loop
Towards the end of the year, I was getting a little frustrated by DesignOps. I had tried to introduce systems based on people’s needs but they weren’t getting used as I’d hoped.
I posted a on Twitter to let out my frustrations a little:
Teams own their processes and adapt and change when they need too. Our teams are agile, many lean, they want to be fluid in their processes and they work in a way that works for them now.
I often try to apply BJ Fogg’s behaviour model to my work.
The desired behaviour occurs when we have the motivation, ability and trigger. If I’m going to set up a system is there a trigger? Is there a motivation to make it the system self sustainable? Does it need to be?
The feedback loop on many of my projects will be a lot longer than just a few months, it could be a year before we see the benefits. A lot of resilience to keep going and pushing is necessary. What to keep pushing and how hard is going to be my biggest challenge.
My final thoughts on DesignOps in 2019
Ops isn’t anything new to anybody, managing software, recruitment, on boarding etc.. is something that has to be done, no matter the company. The larger the company the more it will cost, if its not done well. Often these tasks can be left to design leaders, rather than operations people.
Every business is going to be different in some way. DesignOps has to fit into whats there and then find its home. Do the small things well, choose the bigger things carefully. Be prepared to be resilient, flexible and patient. DesignOps is a challenging role, in a good way.
Be careful how you work, consider the psychological safety of others. Especially if your default is to work in the open, which many of us from design backgrounds it will be.
My focus area for the start of 2020
For design operations:
- Measuring the impact of design
- Digital accessibility
- How we store research
- Design system rethink project
For operations
- Aligning objectives with DigitalOps around on boarding and career frameworks
- Support with designer interviews and recruitment
- Quarterly software audits
- Team budgets for training and monthly subscriptions
Hopefully my post has shed some light on DesignOps. I’d love to chat, slack, email (dave.cunningham@coop.co.uk), Twitter, or whatever way you’re happy to contact me. Especially if you have any questions, or would like to share your experiences. It can be lonely being the only DesignOps person, get in touch, everybody has something to learn and teach.
