Scaling product design teams is challenging. It’s not just about people; it’s also about the structures, processes and frameworks that support your people.
DesignOps aims to address those challenges by applying the same design thinking we use to create powerful products to the practice of design itself. In this online panel event, we’ll be chatting with design and product leaders about the theory vs. the reality of DesignOps, how they are implementing this practice in their organisations, and any lessons they’ve learned along the way.
Recently, I chatted with design and product leaders from Themis, Monzo and Truelayer about the challenges and opportunities DesignOps present. Whether you already have an established DesignOps practice, are just getting started, or want to understand if it’s right for your team, watch the 45m replay video below for some helpful insights, or scroll to read the full transcript.
Meet the panellists
Victoria Olanipekun, UI Developer, Themis
Victoria Olanipekun is a UI Developer at Themis, an award winning platform helps clients identify and manage their specific financial crime risks. Her background is in product design (UI/UX), and her experience in the tech industry spans from product conceptualisation to product launch and post-launch. She is a diversity, equity and inclusion advocate, and part of the pioneering team of a female's initiative within her current organisation. When she is not coding or designing, Victoria can be found helping other people easily get into tech through educational and informative videos on YouTube @TheCodeChamp.
Patrizia Bertini , Head of Experience Design Operations, TrueLayer
Patrizia Bertini is the Head of Experience Design Operations at TrueLayer where she is responsible for both research and design operations. She has developed her approach to design and designops through 20+ years of international experience in usability, accessibility, web design, design management and user research. With a background in academic and industrial research leading international teams, Patrizia has been known for her pioneering work in web accessibility, design facilitation with LEGO Serious Play, and co-creation.
Saskia Liebenberg, ResearchOps Lead, Monzo
Saskia Liebenberg heads up ResearchOps at Monzo bank, where she supports not only a first-class research team but also all of product and tech to do effective research at scale. Her past experience includes roles in DesignOps and ResearchOps roles at Anaplan and Deliveroo, and she is an active member of the global ResearchOps community.
Karl Randay, Head of Design, 383 Project
Karl Randay is a specialist in Human Centred Design and creative strategy, with over 20 years of experience in interaction design, design psychology, creative direction and typography. As Head of Design at 383, he leads the team in creating engaging, user-centred experiences through strategic planning & creative thinking across a broad range of different areas from service and product design to digital applications, print & physical installations.
Transcript
Karl Randay
Good morning. Welcome to Byte, the latest in our series of events diving into digital products. I'm Karl, Head of Design at 383 and I will be your host this morning.
We're going to talk a little bit about scaling product teams because as we all know, it can be quite challenging. It's not just about the people, it's also about the structures, processes and frameworks that support them and everything that contributes to that. For today's topic, we're going to be discussing DesignOps. Now, DesignOps aims to address those challenges by applying the same kind of design thinking that we use to create some of the powerful products that we're building every day to the practice of design itself. Today I'm really thrilled to be joined by three wonderful experts to try and help me demystify the subject of DesignOps, find out how they're implementing this practice in their organisations and discuss any lessons they've learned along the way. Because if they're anything like us, we're kind of winging it and making it up as we go, so it'll be really interesting to learn some of the stuff that have cropped up in these very different businesses.
Please join me giving a very warm welcome to our panellists. First up, we have Victoria, who is a UI developer at Themis, an award winning platform that helps identify and manage financial crime risks. Her background is in product design and she's also a diversity, equity and inclusion advocate helping people get into tech. Good morning, Victoria. Thanks for joining us today.
Victoria Olanipekun
Morning Karl. It's really nice to be here. Can you hear me?
Karl Randay
Yeah, we can hear you okay! All good. We also have Patrizia with us who is Head of Experience Design Operations at TrueLayer, which is a financial API platform where she's responsible for both research and design operations. A passionate DesignOps advocate, Patrizia is also known for pioneering work in web accessibility and design facilitation. So I'll be looking for you to take over when I start mucking this up! Good morning, Patrizia, how are you today?
Patrizia Bertini
Good morning. Hi Karl. Thank you for having me today. I'm really excited.
Karl Randay
Awesome. Okay, and our next panellist is Saskia, who currently heads up ResearchOps at Monzo Bank. Her past experience includes roles in DesignOps and ResearchOps at Anaplan and Deliveroo. Thank you for joining us today, Saskia. How are you?
Saskia Liebenberg
I'm very well, thanks. And yeah, really excited to be here. It's my favourite topic to talk about.
Karl Randay
Awesome. I mean, we only have a limited time this morning. This is something you could probably spend all day talking about. If anybody would be interested in that, then do let us know!
Before we kick things off, we'd love our audience to get involved in the discussion today. You should all be able to see a questions tab to the right of your screen. Please drop in anything that you would like to ask myself and our guests and we'll pick these up as we go. You can also upvote questions if you see anything you really like the look of and we'll get to those at the end of the session.
If you're joining us live, this event is also being recorded, so you'll have the replay in your inbox later today if you'd like to relive any of the action or share the event with some of your colleagues. So, with the housekeeping bit, let's get started and jump right in.
DesignOps is a relatively new function. The kind of stuff that we do in DesignOps has been around for a while, but I think it's been discussed a lot more lately, in the last couple of years or so. And we're getting a lot of traction, especially in the digital product world, both agency-side and client-side.
I think one of the challenges with a subject like DesignOps is it can mean a lot of different things to different people, different teams, and different organisations. First of all, we really want to tackle that and dig into a little bit more about what it actually means to provide the function of DesignOps.
Patrizia, we're going to come to you first. How would you define DesignOps and the job it needs to do?
Patrizia Bertini
Well, first of all, DesignOps is a transformational discipline. It's not project management, it's nothing like that. My background is also linguistic, so when I started looking into the definition, I mean, the word is made by design - let's not get into what design means! - and operations, which means transforming the existing data context to deliver value to the users and the customers. If you look at that, what actually DesignOps is is a transformational discipline that tries and aims to create value for three types of main users.
The first one is the designer and the design team. The second one is the design leader, and the third one is the business. When we talk about value and the value that design operations can create, that goes into a lot of different nuances. It goes into giving back time to designers, increasing time-to-market, increasing time to innovation. It's about creating life-work balance for the team. It's about creating spending efficiencies, reducing the waste. I mean, do you know how much waste do we have in the design process? Because we don't have automations, the engagement models with the cross-functional teams are not optimised, or because we don't have a clear briefing or planning or resourcing type of process.
It's all about creating those efficiencies, both for agencies, because one of the things that is often overlooked is the opportunity to create margins and profits by increasing the efficiency of the process. But it's also about creating value for the business and proving the strategic and the business value of the design practice. So it's all about creating the right behaviours; creating the right infrastructure and the right platform for the design team to operate and enable cross-functional engagement; embedding best practices in everyday processes, and creating all the optimisation - spending, automation, reduction of waste, application of work, you name it.
I'll stop here because I'm pretty sure Saskia and Victoria have their view. But in short, it's a transformational, cross-function discipline that brings value to the business.
Karl Randay
Awesome. Thank you, Patrizia. Saskia, does that definition also ring true for you? What does the overlap with ResearchOps look like?
Saskia Liebenberg
I think ResearchOps is exactly the same, just in a slightly different context, and that's the mantra I always have with my research team. There's a little bit of a tendency sometimes that people think managing the research logistics, because there's a lot of logistics involved in running research and setting up research, that that is operations. It's not; that's the admin and the logistics involved in running research. Operations is exactly that; it's transforming how we do all of that at scale and enabling it for scale.
That's a little mantra I always have with my team is, you could just transfer all the pain that we're all experiencing and put it on one person, give them a nice bucket of pain to deal with. Great for them! Or we could transform how we do this to reduce the amount of pain overall for everyone. And that's what's really going to enable that transformation and scale and make it just a lot better all around. I think that's very much the same approach as DesignOps. It's just focusing on the research team specifically, or people who do research, because that's the other layer that you have with research operations; it's usually not just the research team that you're enabling, it's everyone who does research as well.
And then the leadership. I love that you mentioned, you called that out specifically, Pat, but it's leadership, the business, and the design team. I think there's a little bit of a tendency to think it's just for the design team and it's just to make the designers happy, and that's a very limited point of view, I think. One of the huge benefits I've seen and huge transformations that you can achieve is enabling effective design leadership and helping them to have the right role in the business so that they can have the right influence at the right points and manage their team really well, which then has that massive knock-on effect as well.
Karl Randay
Awesome. Thank you, Saskia. Victoria, I'm really interested in your perspective, especially as you come at this with a bit of an engineering lens. As a UI developer, what does DesignOpps mean to you?
Victoria Olanipekun
They've all said a lot, and I'm like, oh my god, what else is left to say?! But really, as an engineer, I'll start with, I used to be a full-time designer at some point in my career journey. I've shared this story before. I have sold the engineers on my team. I'm like, the button is not exactly what I designed and I needed to look exactly like that...! The good story is that this also led me to start picking up coding and trying to see exactly what the issue was - my inquisitiveness. I ended up loving that aspect of things and then moved on to that.
I'd say, in my experience, design operations has to do with not losing the very essence of the design up until the engineering aspect of things. And how do you ensure this? Imagine Saskia has done her due diligence, Patrizia has done her own thing. However, there's this thin line whereby the engineers can just miss it, because the information is not properly distributed to the right set of people, and the importance behind that, the importance behind the reasoning.
For instance, the business has done the research, they've done the reason, the UX, and we know the reason why - let me stick on the button - a button needs to be curved. Because probably you've done usability and you realise product users love when the button is in a certain way and there's a reasoning behind that. The designer gets the reason, draws out the button, hands it over to the engineer without the reasoning behind it. Now the engineer just does the code and then something get lost in the process.
So I'm saying, for design operations, I ensure that, I guess, the reasoning behind every design; there is a reason to this button, there is a reason to this header, this image has to be clearer than this because of this. So when there's data backing that up, it helps the entire process of development. For me, that is it. It all comes together at the end of the day on the UI development.
Karl Randay
I love the idea that while we call it DesignOps it's so much broader and deeper than that, in that it collaborates every, I think it collaborates every single team in every aspect of the business to make sure that we're on the same page and we're all kind of pulling the same direction. That's fascinating. Thank you, Victoria.
I want to talk a little bit about setting up this kind of function within an organisation. There's a tendency to think of it as something that's really big and quite unwieldy. We've all heard about the Spotify model and how businesses like Netflix use it at scale, and I think that can be a little bit of a barrier to especially small businesses and like a couple-of-man teams, stopping themselves thinking about what the benefit might be, and it's just for large established organisations. Saskia, in your experience, how true is that? Do you think you need dedicated DesignOps managers? Are there simple, flexible ways that you can get started with it?
Saskia Liebenberg
So I think you can - obviously, before you have a DesignOps person leading the function, a lot of the activities that fall under the remit of DesignOps will be taken care of by various leaders in the team or by individuals in the team, design leads who aren't like an official manager or leader, but quite senior and take on some of those bits and pieces. So, things will be happening for sure. It's not like there's a vacuum, that a DesignOps person comes and suddenly does all of this from scratch that was never done.
But I think that the magic comes from having it as a consolidated function and a consolidated role where you can take that end-to-end view and you've got that holistic view across the whole design process. And you're a bit of a neutral entity as well, right? Because none of these designers are reporting into you. The design managers, you're not reporting to all of them, necessarily. You're probably reporting to the VP of Design or whoever's in charge. So you are able to take a very neutral, objective point-of-view on what's happening and spot those opportunities and see where you can level the playing field a little bit to make sure that everyone has the same access and the same toolkit to draw from and the same kind of frameworks to use. And it's not just, oh, they happen to have a really good manager, and therefore they've set up for success. You were able to take the bits and pieces from everywhere.
I think that's one of the really key superpowers of having a DesignOps function in a team, even a small team. I think in ResearchOps, we often talk about when you reach the point of having five full-time researchers, you've reached the tipping point, and you need someone to think about the operations if you're going to continue to grow.
That's the other point, I think. You might benefit from having someone come in and do a short-term project or a short-term consolidation if it's a small team and it's going to stay at that size. Then you may not need someone on an ongoing basis, necessarily. But if, especially if you are growing, if there's more opportunities, or if there is the need to do more with what you have - you're not necessarily growing in teams of team size, but in terms of business opportunity, the impact you need to have - that's where this role becomes really, really important and becomes a force multiplier. And you get so much more out of it than by hiring additional designers, because you free up all that capacity and optimise how people work.
Karl Randay
Interesting. That's cool. Thank you very much. Victoria, what about you? How does being in a smaller team change the way that you approach DesignOps?
Victoria Olanipekun
I would say ensuring that you have the strategic product goal at the forefront of everybody's mind. The advantage and the disadvantage of working in a small team is the flexibility around it. Sometimes you don't have a set-out goal, or a set-out process, or a set-out 'this is what I do and I don't do more than that'. You have to do this and do that just to ensure the product goal is being achieved. So I'd say the main point of design operations as a small team is ensuring that the systems are built around that goal, around that feature that you're building, around that new goal. I don't want to just say a figurative goal; for instance, you want to get in 500 new users. The research team have done their job, their due diligence, the market research has been done, and we know exactly what we need to build. So how do we move from what is to be done and what is to be achieved? Putting this all down in a place like a Trello board or a Notion board, or just getting everybody in a workshop and getting everybody to get in their ideas.
It's more like a very fast, agile development process, but it is always there, guiding everybody through the process. So every day individual teams, individual people, can go on to remind themselves, okay, this is what we are working towards, this is where we are at, this is where we are going. Accountability, ability to document things, I would say this is very important in the design operations of things, for a small team.
Karl Randay
Brilliant, thank you. You're touching there again on the broader functions within a business and this is what I want to talk to you about, Patrizia. How do you think DesignOps can move beyond just design as a function and start to benefit those cross-functional teams and other departments within a business? Not just client-side, but maybe agency-side as well?
Patrizia Bertini
Well, you know, design operations and the design team is cross-functional by definition. You can't have design if you don't have the PMs, if you don't have the marketing, if you don't have engineers. Design operations is not just design thinking; it's system thinking. Because every change, every improvement in the process you bring by, for instance, embedding best practices in the workflow, will necessarily have an impact on the other teams. If you change the planning process, if you change the briefing process, if you change the tool ecosystem, that will cascade down in a way or in another to all the cross-functional partners we work with.
It's not so much thinking about design operations as project management on steroids, or project management with design thinking; it's pretty much change management. It's about looking at the design organisation and looking at the way it's operating to generate those efficiencies and to generate those improvements that have an impact on everyone. This means that when you think about design operations, design operations needs to act as a glue that brings together everyone that works for the product, and ultimately for the user and the business, to understand how we can empower ambidexterity, which means making sure we take care of the business as usual, which is 90% of the work, in a way that we free up time for the teams to do innovation, to do what actually brings value.
And to do that, you would, of course, need to make sure you work with the whole organisation. The biggest differentiator between a project manager and the design operations leader or lead is the fact that they operate at a strategic and leadership altitude with all the organisation. Because design operations, if you start doing a stakeholder-mapping, involves legal, procurement, beyond the classic PMs and marketing and engineering, and it works with HR and the talent team for recruitment. So it's really 100% cross-functional, because change management needs to be systemic and managed at a cross-functional level to ensure that we are all aligned and we are bringing in that value and the value that design brings. It's literally elevating design thinking with system thinking across the organisation. You can't have design operations if you don't work with the whole organisation together.
Karl Randay
I like that. I like that sense of partisanship also being quite protective to ensure the rest of the business can just get on and do the work that needs to be done.
We've discussed the role and the scope of DesignOpps and what it can mean to different sizes of team and how we can start to establish a practice. Once all that is in place, the question is, how do we know it's being effective? How can we tell that it's helping improve how we - and I don't want to continue using the word design, because I think we've all established that it's much broader than that - but how can we understand it's helping to improve the things we're trying to create for the real people out there in the universe? I'm going to come again to you, Victoria. How do you approach measuring success in the things that you're making and the idea of operations? Are there core metrics or KPIs that you use?
Victoria Olanipekun
Yes, I would categorise it all into three; time, result and culture. How well have you been able to meet up with the timeline? So, normally, on our end of the game, we operate in sprints. At the end of the sprint, what have we been able to achieve? What is the result we are really lacking? How can we achieve more or less in a better time? We have a reflection as to how far we've got and how far we want to go. That is the timeline you're working with. I would say the result, in the sense that, okay, so the goal that was set, how well is it working? How well is the user adapting to this new feature? Should we do a rollback or is this working well? These are all the KPIs that has been set before and how we've been able to achieve that.
And then I'd like to touch on the legal aspect of things, like Patrizia has said - I hope nobody is suing you, I hope nobody has an issue with you...! I saw a movie over the weekend about, I don't want to say the title of the movie, it's about Pepsi and how they got sued by this guy because of an advert. They just said, oh, you could get a million - is it a million, or seven million? - bottles of Pepsi, whoever can drink that. And he set out to actually do that. That was because in the design of that advert, there was no caveat. It was just there. And he felt like, oh, okay. And then he went through a process of suing them, dragging the brand.
These are all part of the design process and operations. You don't want somebody knocking on your door and say you're being sued. So, the result, is this working well or there's a problem at the back of the door? And finally, I would say the culture. We measure the culture in the sense that, do we have a lot of burnout? Is this healthy? How are we doing better? Does somebody need to go on a break? Culture is really important. I really like to make sure everybody on the team, including myself, understand that when it's time to take a break, it's really important to take a break. Thankfully, I also have a CTO that's always knocking on your door like, you've not taken enough days, when do you want to go on break?!
I find the culture of unlimited holidays to be quite tricky. You need to really be sure that, even if it's unlimited, you have at the back of your mind that the level is 30 days and you take those 30 days to rest. For me, it's all three, time, results and culture, that I maintain.
Karl Randay
Awesome. Thank you so much, Victoria, for your answer. Patrizia, in your experience, can you sign up to help product teams communicate better with senior stakeholders?
Patrizia Bertini
Well, it's critical and it's also design operations needs to work with product / product operations if they have, because the biggest problem we can see today is this ambiguity. You know, we have the discovery phase when we have design thinking thriving. We need to go broad, go narrow, get empathy, understand the problem space. And then we get to a point where we have all the hypotheses, and this is where Lean Startup should kick in. But Lean Startup is not owned and shouldn't be owned by design; it should be co-owned with product to make sure the experimentation and everything is done in a way that actually delivers results and combines the user-centricity, the design thinking, that the design team brings to the table with the need to find the market-fit and find a product, a feature, that actually distinguish and takes the product out and delivers maximum value to the user and to the market. This ambiguity, and then we get to the final stage where we have the agile helping to deliver value at speed, fast, with engineering.
Design operations, it's not here to orchestrate everything; it's here to bring order and to clarify who owns what. Bring that trigger that actually helps organisations to maximise the quality of the product and the results they can achieve on the business side. When you say, does the design support product, it's part of it; it's the DNA, it's the source of good product, it's a source of innovation. And design operations enables this by making sure that the teams can grow, that they can develop, they have streamlined processes, that they have the tools, and the tools are in an ecosystem and they are right. It's about making sure the team have the skills to grow, and bring all that to the table and work together, creating those synergies with the product organisation to make sure that we work together. It's part of being cross-functional by nature and being user-focused with a business lens and a business view of what we do.
Karl Randay
I think one of the key themes that's coming out of this session is that collaboration and removing departmental bias and just getting rid of those black and white lines that can sit between teams. I think that's crucial, right? It should be lots of grey areas and, you know, lots of us just being nosey with each other, I think, to break these things down. Awesome, thank you Patrizia.
Patrizia Bertini
Absolutely. If I can just add, design operations, it's about facilitating processes, removing bottlenecks, and making sure everyone is aligned for the greater good. And we enable designers and product teams to be the best they can.
Karl Randay
Okay, excellent. Thank you, Patrizia. And then finally, Saskia, to you. One of my favourite questions at the end of this panel discussion is this one; what are some of the major challenges or common pitfalls that you see with DesignOps and are there any lessons that you've learned along the way?
Saskia Liebenberg
Yes, I mean, it's really hard to condense this into a couple of themes!
Karl Randay
How long have we got left...?
Saskia Liebenberg
Yeah, exactly. This is the rest of the hour! I think there's a couple of key things that I see, kind of touching, actually, on what Pat and Victoria just said. So, to Victoria's point, I think if you don't take that holistic view of the metrics and what you're trying to achieve and how you're going to know that you're heading in the right direction and that DesignOps is having the right impact, you limit yourself massively and you get very stuck.
I see a little bit of a tendency in some design organisations to think they're going to have a DesignOps person come in, they will own culture. They will be responsible for culture, all the fuzzy things, all the team meetings, team rituals. Making people happy is going to sit with the DesignOps. It's impossible. You cannot make people happy. As Tess Nixon said, unless you're a kitten or a puppy, you cannot make someone happy. That's just not an achievable thing.
I think actually that culture bit and the happiness at work and the feeling comfortable at work and being able to excel without burnout, that's almost a by-product. It's almost an outcome of having that effective infrastructure that enables you to work effectively. And that shouldn't be the only thing you are thinking about, because that's not a holistic approach, right? And you're going to get very stuck, very quickly. Also, just the burden on a DesignOps person of trying to be responsible for the happiness of a whole team who have things happening in their private lives, who have things happening elsewhere that you cannot control. The world is very messy right now! That's going to have an impact, we can't deny that. I think that's one major pitfall that I see a lot.
The second major pitfall that I also see often, and this is where I'm very choosy about which role I take - I do a lot of questioning and digging before I agree to work somewhere. Is the level that this role is coming in at, are we viewing this as something really tactical or is this actually a strategic role and am I going to be able to have that strategic impact? Working with leadership in a transformational enterprise, essentially, across all the different stakeholders to try and see how we can make everything work better and make everyone work more effectively and be a bit more streamlined and aligned in how we work.
I think those are the key pitfalls that I see. Someone, you see this more explicitly in research operations, where they want someone to take one piece; they want someone to just look after recruitment, or they want someone to just do the admin for this, and they don't have that strategic point of view around what you can actually do across the entire workflow and how you can lift it all up. Also because it is all connected, right? Just identifying one particular pain point and saying you're going to solve that particular pain point, in tackling that properly, you will actually touch on the entire experience and the entire process. Those are the major ones that I see is not having the right level or the right understanding of the impact the role can have.
Karl Randay
The influence.
Saskia Liebenberg
Yeah, the influence it can have, and then limiting it to culture, and just thinking that's what it is and it's not. Or, actually, on the flip side of that, limiting it to we're going to get someone to look after the tools. We're going to get someone to look after the design process and the tools. That's a very limiting view as well, I think, and you're not going to get that step change that you can get from the role.
Karl Randay
Awesome. Thank you so much. Some incredible responses so far. We've got some strong questions to dig through. We've probably got about ten or twelve minutes to kind of go through these. There's a couple that we've already warmed up with internally and some awesome ones from the audience. Some of these we've already been able to answer as we've been through the panel. I'm just going to rattle through these and if anyone wants to kind of dig in and shout out the answers as you can think of something, then please feel free.
The first one is onboarding new people in your team. How do you onboard new designers and ensure that they hit the ground running? Especially when a new organisation can feel quite complex. Who wants to tackle this?
Victoria Olanipekun
I could go?
Karl Randay
Go on then, Victoria.
Victoria Olanipekun
Yes. This is where documentation is very important. Whenever a designer is leaving or getting onboarded, the most important part of it is documentation. Nobody reads the mind, nobody knows why or what's the reason behind any of your design decisions. Having that documented, so that whenever a new designer comes on board, they have something to read, something to understand, and something to see, clearly stated. It's not unmet expectations or undefined KPIs. If all the documentation has been released to you, that's the first step of onboarding for me. Then you can now begin to set your own pace and the process through which you would achieve all the other KPIs that is set. So, yeah, onboarding is very important or else I don't know what I'm doing.
Karl Randay
Good response! Saskia, you mentioned DesignOps isn't just about the tools and the processes there, but when we're considering things that we use to get our jobs done, how does DesignOps influence that, the things that you're using and even adopting new things? There's a new tool coming out every day. Let's not just talk about people being bought out by Adobe and all that sort of stuff. But you find a new tool and you think there's a place for it. What does that look like? What's that as a process, especially in a business at the scale of Monzo?
Saskia Liebenberg
Yeah, I think that's where you've got to understand the strategy behind the design team and the business strategy and the opportunity. Where are we heading, where are we going, what do we currently have, where are the gaps? If it ain't broke, don't fix it! I think there's a little bit of, it's a shiny new toy, we must try it out and play with it. And this is where it's actually a real advantage working in a regulated bank, right? Because we have to go through quite a lot of due diligence before we can onboard any new tooling. So we've got to be really sure that this is actually worth the effort of going through onboarding. I think that's great because it slows everyone down a little bit and it makes sure that we are actually joined-up and we're thinking things through strategically and not just trying to pivot to the latest new thing, but that we know that it's going to last.
I think that's the other thing; you've got to think about the cost of onboarding and offboarding with any tooling, right? There's a huge cost there if something turns out not to be the right thing - not in terms of the money you spend, but in terms of the knowledge that's gone into it, the documentation, and the knowledge you have to get back out. Most of these tools are locked silos. You're not going to get your content back out easily, if at all.
That's something people don't think about enough at the beginning. You've always got to have in mind, if this went bust tomorrow, if it got acquired by a company we can't work with, how am I going to react? What am I going to do? I think that's the really nice thing about working in a bank is you have to think about that upfront, which I love, because that's what I, always in my past, I was always the one asking those questions and people were like, Saskia, you're so pessimistic, it's going to be fine! No-one's going to think about this!
I think that's the big, again, that strategic lens of what are we trying to do, why can't we do that with what we have, and what are the opportunities that it's going to unlock, and how are we going to get out if it doesn't work out?
Karl Randay
Okay, awesome. Thank you. There's a common theme coming out of the questions at the moment that I want to come to you about, Patrizia, and that's the relationship between DesignOps and other functions in the business. There's a couple of questions here; one is around about what relationships do you see optimal for DesignOps throughout the business, but ultimately I think it comes down to really understanding does a business need to have like other ops? So, is there an interface between DesigOps and DevOps and ResearchOps and all these things? And what do you think that looks like to really optimise that influential relationship that Saskia mentioned before?
Patrizia Bertini
Absolutely. I find it funny, the question about what is the relationship if we are in a company, no matter what our role is, we should be all rolling up to company OKRs and goals. The role of operations is to facilitate how teams contribute to the overall achievement of those goals. MarketingOps does it from their point of view, DesignOps does it from their point of view, DevOps does from their angle. Each of us has a very specific lens, and the beauty of having multiple Ops is that you can work together and get all the inside work on processes and be focused on how we can align the largest number of teams to deliver the highest value, reducing the inefficiencies, creating a culture, creating collaboration, creating engagement models that actually have an impact on people and business. It's really a friendly relationship, in clarifying why we are in this company? Why not a different one? What are the company goals? What are the company values? And how we can embed those in the way design works, product works, engineering works, marketing works, finance works, et cetera.
Now all these Ops, it's still something new because organisations have been growing in complexity. They have been growing in the way they operate. If you think, we mentioned briefly at the beginning, design operations is nothing new. Before, it was kind of distributed and seen as a task, as something that, oh, someone needs to fix and onboard a tool, oh someone needs to take care of the Christmas party and the team events and offsite, oh, someone needs to do, whatever, the research playbook. It was always someone within the team that spared their time to do it, rather than focusing on what they've been hired to do. I mean, a researcher has been hired to do research, a designer to do design, not to manage tools. The complexity that has grown out led to the need for someone not only to have the tactical view, but the strategic view to decrease inefficiencies, and there are enormous efficiencies.
But to go back to the relationship that we need to have, it is really the relationship where we work together to bring value. Otherwise, what do we do in this company? Why are we here? There's a lot of strategic thinking, alliances, partnership that goes into that, but it's absolute, and it goes way beyond the ops teams and everyone. It's having a purpose. Designops is a purpose-driven function.
Karl Randay
I want to add a little extra question to that, Patrizia, and if anybody else wants to jump in as well, we talked a little bit about measuring that, what it looks like when it's in flight. What about before the big bang, before you have DesignOps? How do you justify and plan for the ROI on that, to take that to the rest of the business to say, please, can we have a DesignOps function? What does that look like and how do you tackle it?
Patrizia Bertini
So, inefficiencies are endemic. When you start looking at the design process end-to-end, you will find that people are using tools that are kind of in a trial mode. So, you start talking about risk, reputational risk, because if you use a free tool, chances are it's password protected and maybe you're using it for the latest innovative mockup and you get a layoff and someone suddenly goes out in the market. So, you have reputational risk. Or you start simply looking at how much designers are spending doing rework. I define rework as a designer working on the same project, not on iterations - so, learn, test, learning loop, test, learn and improve - but because, well, the stakeholder changes their mind, the stakeholder disappears, the brief is not clear, the goal, what we do, is not clear. I mean, I've been in companies where the rate of rework was 55-60%.
We also know, by a lot of researchers, not the research just that I did, but a knowledge worker generally spend 60% of their time doing something else. Which means they spend 40% of their time doing what they've been hired for. Now, I did experiences where I measured how much time designers were spending doing non-design work and it came out in an astronomical cost. So you just bring, you do the math. Hey, designers are spending this amount of time doing non-design work, which means that to deliver something, we have an extra cost of 60% because they need to work longer. Now, this also comes with other costs, which is life-work balance, because if you expect designer to do something that is not design, plus the work that design needs to do, and the deadlines are strict, you will realise that life-work balance goes down. And if it goes down, quality goes down, and if the quality goes down, it goes into, oh, we need to work more because, hey, the quality is not there. So, it's a cycle and this is how you can prove. And it's a fun game!
Karl Randay
Awesome. Thank you. Thank you for that, Patrizia. Now, we're almost out of time, so I want to close out with one last topic I want each of you to answer. If people want to learn more about DesignOps and how it could benefit their business, how should they get started? Are there any resources, communities or events that you think that they should look up? I'm going to come to you first, Saskia, have you got any thoughts?
Saskia Liebenberg
Yeah, so many! I think, actually, Patrizia, who's on this call, has a lot of really excellent writing on the value of DesignOps. So, just look her up on Medium. There's a lot of really good articles about DesignOps and the value DesignOps has by Pat.
I think Rosenfeld Media has a really lovely DesignOps community. They run monthly calls, but also there's a lot of resources and a lot of writing in Rosenfeld Media, and they run the annual DesignOps conference as well, which is like gold, with a lot of really excellent talks. A lot of the past conferences talks are actually on YouTube or other channels where you can see them and look at them and there's some really lovely talks in there about this is DesignOps 101, this is how you can get started, this is the value it can bring. Including, to your earlier point, as well as looking at the optimisation and the efficiencies you can have, there's often like a menu of things that just no one is getting to that needs to happen in the design team and there just no one is able to do. And you can work out, okay, if we had a DesignOps person come in, they could start some of this and look after it you know. To Victoria's point on the documentation, it's often the last on the list or it's there but it's not up to date and it's not maintained or it's there but it's really dry and it's pretty difficult to actually get to grips with. What are the other ways that we can do that documentation and onboarding. There's a wealth of resources there.
I think the other point that I would make is, DesignOps is really contextual. It's got to fit with your organisation, with your team, with your business strategy and your objectives, and so there isn't a one-size-fits-all, this is what it is and we're really rigid about it. There's a whole menu of stuff you can be looking after, there's a whole range of metrics and frameworks you can use. But the ultimate goal is transforming how we work so that it's better, really, for everyone.
Karl Randay
Awesome. Thank you. Victoria, is there anything that you would like to add?
Victoria Olanipekun
Yeah, I was really particular about Rosenfeld, I don't know, and when she mentioned it I'm like, yes! They have over 4,000 people in that community and you could join. Also I think people should be willing to reach out to industry leaders, and industry leaders should also be open to responding to people. I know time is something that is very much of value but at the same time the knowledge needs to be passed on. That is why I love what Patrizia is doing, so you could also read up, like they said, everything she's written.
Another thing is that in an organisation you could bring in consultants or just other industry leaders that have done something, a skill, just to come in and give their own insight into how you can put all these things in process. Because at the end of the day it's a cycle that doesn't let you grow when you don't put the right process in place. You see the importance and going out of your way to make it work. I also think most organisations have the Chief Operating Officer and I also feel the person should be pushing also for different departments to have their operations person or lead, like DesignOps, and that is very important to me. So yeah, read up, get more certifications and all - there are so many resources on Google, you just need to find it.
Karl Randay
Awesome. Thank you Victoria. And to finish off Patrizia, anything that you would like to add?
Patrizia Bertini
Probably the only one that hasn't been called out is the DesignOps Assembly. That's a really good resource. They have trainings, they have a very active community. There's also DesignOps LOL, which is an Australian community. They do and they run a lot of interviews with people in different companies and you can learn a lot. They collect a lot of resources.
And finally, just as Victoria said, go on Google, go on Medium. There's a lot of content, especially because - I wil be unpopular, but the best content you can read are not necessarily books, because a book is probably two years old, and DesignOps is a very fluid and dynamic discipline. Go and read articles, go and read, join communities, because the conversation is happening now, the discipline is forming now, and now is the time to be part of those conversations.
Karl Randay
That's fantastic. Thank you so much. That brings us to the end of our panel today. All that's left to say is a massive thank you to Victoria, Patrizia and Saskia for taking time out of their day to chat to me this morning and fueling my imposter syndrome! It's been incredible. We could do this all day long, and we probably will.
Also to our audience for joining us and submitting your questions - I know we couldn't get to them all. I hope you've enjoyed watching it as much as I've enjoyed taking part and talking to our panel. Look out for the replay in your inbox later today. Our next Byte event will be coming up in February, so follow 383 Project on LinkedIn to hear more about that. Finally, you can also catch up on past Byte events and lots more digital product thinking on the 383 blog at 383project.com. All that's left to say is enjoy the rest of your day. See you at the next Byte. Thanks for coming, everyone. See you soon.
Victoria Olanipekun
Thank you.
Saskia Liebenberg
Thank you.
Karl Randay
Bye.
Patrizia Bertini
Thank you.
