Design Ops Initiatives in Practice

I am Peter. Uh I am Dutch. I am old. Um I am married to a woman that I met at this conference 14 years ago. So um I've got two sons. I sort of say I can sort of say I'm a designer. I've been a manager of designer. I've been a manager of managers of designers. Um but uh nowadays I'm a a design operations consultant which means I try to raise the majority of design in my clients organizations. I've worked at Miro uh most recently as a full-time design operations manager. Before that, at Service Now, a large workflow provider. Before that, at the craft, one of these uh regional UX companies. Um uh and like I said, I'm a design ops consultant. Uh I tell my people uh they should I tell my my client that they need to work on design ops things. Um and I'm I'm not the only one. Um here's a prediction uh about design ops by uh Adrien Alnot uh who was a director of design or is a director of design uh uh design ops at service now uh and she says in a couple of years and she made this prediction in 2020 so sort of now we will see that the responsibilities of design managers move back to their core what of what design managers should be focusing on which is uh uh giving creative direction uh you can read this creating innovative designs storytelling, developing designers and stuff like that and other design responsibilities that have sort of accumulated on design managers will be dedicated to specialists that are called design operators. Um so to to confirm that to see if if you agree, do you think that these responsibilities are responsibilities of a design manager uh defining the design process, keeping track of all of the work that's happening? uh making sure that your designers are trained well. Uh making sure that there's a design culture in your in definitely in your design team, but maybe in the in the in the entire organization. Um picking the next uh Figma uh or moving from Sketch to Figma. Um and then uh making sure that that happens uh smoothly. Um running all hands for all designers. So your either your weekly all hands meetings or your offsite or stuff like that. Is that the responsibility of your manager? That's a lot of work. Um and a manager would probably rather uh uh work on design strategy and uh checking the work. So um nowadays these responsibilities are often seen as the responsibility of design operators, design operations specialists. Um this is my definition of design operations. Yeah, I'll be focusing on different words of this definition throughout the rest of the talk. Um, let's read it out loud. We design ops continuously and structurally improve the circumstances for designers in the design organization to increase the chances of good design happening. That's what we all want, right? Good design happening. Okay, let's start in the middle. Designers and the design at work. That's you. Yeah, we're doing this for you. Um we want designers in general and their organizational their business unit to thrive. Um who are the wei then? Um we can be anyone with the mindset that a good design ops person has. I often I mentioned this in the workshop. I often call it like a gene that says I want to do this. I want to every now and then take a step back look at the circumstances of this of design. How are we doing things? Why are we doing this this way? Is there a way one way that we can make it a little bit better? If you have that mindset, you're a good candidate to start executing design ops initiatives, to start thinking of new ones, to start putting them in the right order, to start influencing the the circumstances for designers. Um, it could be that your organization is ready to have someone with the role of a design operator that you can make it a part-time responsibility, a full-time responsibility, even for larger design organizations, a a team of design ops people, specialists, even a manager, tool person, culture person, uh, process person, specialists within the design ops team. If the team is large, if your design organization is large enough, it starts making sense to set up a team with specialists for design ops. Um, so there doesn't have to be someone who has the title. It's okay if there are multiple people with the role. It's actually lovely if there are more multiple people with the role because then you can work together uh and uh distribute the responsibilities and distribute the load. Um, so that's the Wii part. Um, let's talk about the continuous improvement. Why do you want to continuously improve? Um, and Brad and like I was tweaking my slides earlier. I put in a photo of Brad that says if you stand still, you die. Like if you're if you if you're how did you phrase it, Brad? >> When you're finished changing, you're finished. Don't stop. Don't stop. Continue. continue improving. Um there's this sort of statistical rule. If you do 1% improvement every single day in a year, 365 times, uh then in total you improve 38 times, forget about 10x engineers. We can 38x design. If we make one improvement every day, including Saturdays and Sundays, maybe we need to settle for 10x. Um so that's why we want to continuously improve. It makes all of us better in total in aggregate. Um and what do we do? We improve the circumstances for designers. What does that look like? It's it means we execute design ops initiatives that make one of those 1% improvements or maybe 5% improvements or 2% improvements. We execute design ops initiatives. And in this talk I want to show you some design ops initiatives. That's what it said in the in the abstract. So, I better do that. And for that, I need my my mouse cursor. So, I'm going to move over there. But, um, I'm going to let you choose. You have a hand over there. Hi. Which one would you like to see? >> Thank you very much. That's the one that has sound. Um, and I want to challenge the people in the back to to uh to do the sound. Let's pick that one. Design review service. It's one um from uh service now where um we had when I joined 275 designers, researchers and uh writers 275 people we were supported by a design operations team of 25 people uh that had specialists on uh uh balancing designers over business lines that had uh uh design system uh team that had uh this review team, the design experience review team, the dirt team um and they would perform reviews um uh at set stages in the product development life cycle. So in in in during projects, design projects um they would do one uh sort of early conception where they would talk about are you following our general guidelines for how applications general design work uh general service now work. um do they would have do one where they would review whether you're using the right design system components or whether you were using them at all uh um and whether you were using the right ones. So the short version of this is this and whoop the sound of the police. Um they are the design police basically uh which sounds bad but they can send you back. They can say stop you cannot go any further. you need to turn around, do something over and do it better and come to come come back to us. You would not be allowed to proceed to the next stage of design without their approval on u multiple stages of your design process. So they we had a defined design process and since we were a workflow tool, we were using our own uh our own tool to manage our workflow of of design projects. So we knew how it worked and we all knew we respected this uh this process. Uh so we respected the police. Um the goal of this initiative was um to support designers in the concept phase in detailed design phase in usage of the design system. They even had an accessibility specialist on the team to do reviews regarding accessibility of your proposed solutions. Um the team that uh was working on this was um this design experience research u a review team that was part of our designs organization and it took a little while to set up this service like define when do we want to uh do these reviews how do we make it happen uh how do we make sure that designers come to us. So setting up office hours for all teams in the agenda. So this part of the business unit could could go come on Tuesday morning this part of the of the company could come on Wednesday afternoon. Setting up those kinds of systems took a while, but then it was running and it worked. Um, let's go back to the overview. Let's do another one. The first one, design process definition. Okay. Um, that was a Miro thing. Um, Miro's design process definition, the large overview looked like this. You can focus on the the bit at the top first. Um the discover, define, design/ress research, build and ship was our product development life cycle that was agreed upon with product management, engineering, design, uh product marketing and data analytics team. We all followed these same steps in uh in the development of new products. So the design process was a natural part of this. Um so for every phase in our product development life cycle we could define and this is where I click we could define what are the goals for the product design team in this stage what are typical deliverables in this stage what are typical activities by designers in this stage and not unimportant who do they collaborate with and the word amp means that's an acronym for our product organization and in this overview of proposed deliverables activities there were uh research related activities, accessibility related, design system related. They were all marked in in a color. Um, this was a like a large diagram and then there were chunks of this that would uh describe in more detail on the wiki and people would hopefully follow this. We didn't have a design review police team. Um, but this is what uh what Mir's design process looked like. And the goal of of documenting your design process is to support designers uh uh in doing things in the right way and mostly the right way. Um uh and actually promoting this way of working also to member other members of project teams. So to the engineers so they would know what what they could expect from designers. Researchers knew how they could contribute uh product managers knew what what they could expect. So it's not just for designers. on the team was me as a design manager. I was responsible for for maintaining this design process and all all of his documentation. Um but I had the help of several fellow process freaks uh fellow designers who liked to think about the way they were doing work and about and enjoyed standardizing that this for themselves and their teams. Um it took several months and then to document this for the first time in a uh uh in enough detail and all of its details around this big diagram. Um and every now and then there was follow-up necessary for example because we started developing a growth team that was responsible for product hacking or a growth hacking getting more people into into our product through sort of marketing and sometimes a little dark pattern here and there. um uh and while they were in the product to get them to explore more of it and use the new features. That was our growth team. They were they were doing a lot of um uh sort of hypothesis-based quick AB testing uh experiments instead of the longer month-long projects. Uh so their design process was different, their timing was different, their activities were different. They were often based on uh data and analytics uh uh input and output. Um so they had a variation of this large process uh just for them. So that was the tweak or followup that we developed after we developed the the overall standard. We developed a specific variation for the uh uh for the growth team. Let's try one more. Try let's do >> IKEA. >> The IKEA one. Okay. Uh the IKEA one. Um that's good. I can introduce a little bit of terminology. So let's we'll get back to this. Um there is this thing of horizontal and vertical design ops work. Horizontal design ops work is work for that's meant to benefit everyone. Everyone everyone. Uh an example is career letters for designers. Career letters for designers are uh uh are created so that everyone in a design organization knows this is what it takes for me to move to the next level to get to get a promotion or at least contribute to getting a promotion. Um these are the things that are expected from me in terms of skills and behaviors and and typical deliverables in in this role. Uh scope of work stuff like that. Career ladders are a horizontal activity that should developing those career letters is a horizontal activity should benefit everyone. uh an example of the other one the vertical uh work is when uh the example I just gave where we helped the growth team develop a variant of the design process. It was only beneficial for the growth team. Uh just them they benefit from it. Uh it was initiated by their design leader the the the director of design for the growth team. They benefited from it vertical activity. um at IKEA uh when I joined them almost all of the work was horizontal. So IKEA has uh like 300 digital designers to not just not create new flatp pack furniture but create all of the digital work that IKEA needs including the kiosks in the shops, employee applications and the websites and apps and stuff like that. Uh so they have 375 300 designers, a design ops team of 10 people. Uh I joined them for a while and all of their activities, all of their initiatives were horizontal initiatives. Um but there was beginning to be a need for more vertical more vertical work. So I helped them specify this role that one that every member of the design ops team could take on for a while sort of wearing a hat uh of being the design operations partner for one specific team of designers or cluster of designers. Um and their manager, the XD manager could request such a partner and on this wiki page, it was a wiki page. Um they could uh uh they could find out about the existence of this service uh realize that they could design uh or request such a design ops partner, read the whole role description, um and then uh say if you want one, click here. So they could request a design ops person wearing this hat of vertical uh support uh request that for four months, eight months, 12 months. This is how IKEA counts. Um, so the goal of this uh uh of this new service, this this hat that design ops people could wear to benefit uh design uh leaders was to optimize the implementation of the most of the existing design op services that were meant to be horizontal but then tweak tweak those services to make them fit for this vertical team and maybe even develop new services that were fit for this individual team. um the the team to that worked on this initiative was me. Um I did research on what other companies call these roles. Uh there there's a a typical design program manager role or job description in in the world of design ops that sort of is like this. You temporarily help a group of people get a program in place. Um we had someone who who played this role for a couple of months for one team. So, I asked him all kinds of questions. When I suggested this job description, he said, "Yeah, let's tweak it a little bit." Um, and a couple of the design managers who were supposed to push this button when they needed support uh were also involved in the review of this uh wiki page basically. Um, it took a couple of weeks of research. It took a couple of week or a week of writing and reviewing um and and tweaking. And then I had to wait three weeks for approval from somebody high up in the design organization. Here are more examples. These are not just the ones I I can show you more details of, but these are known examples of more design potential design obsitives that you and your team could develop. Um, and there's more more. Uh, then the last one is tool research. Like are we really going to go for the enterprise version of Figma or not? If so, who's going to do the quarterly true ups of supposedly uh active users versus that you need to pay for for real active users. So these kinds of things are all potentially in the scope of a design ops person or team or people with the mindset. Um so this is how you improve the circumstances for design. You do that by executing these types of design ops initiatives. Um, and even though it sounds it looks like we haven't touched most of it, we're we're getting there. Um, the the part of the doing it in a structural way means you need to well add some organization to the potential uh of this long list of uh of design ops initiatives. Uh, you want to do it in a slightly more structural way. And I have a five-step program for for it that we went through in the in the workshop on Wednesday. Um, and I I won't go through everything. I'm just going to show you quickly what the uh sort of the output of each of these steps looks like in the in the workshop. Step one, an inventory of initiatives is just a really long list of post-it notes uh uh that have have been given a little bit of structure. Ideas, you know, post-it notes on a piece of paper. Um, step two is where you try to prioritize this list. Which ones are urgent? which ones are important, which one are urgent and important and which ones support the goals that we have as a design organization or as a larger organization in general. If you have like an OKR system or KPIs and you can show how your design ops initiatives contribute to reaching the goals uh or getting you closer to the to the key performance indicator, closer to the number that that you're supposed to hit, then um your design option initiative rise to the top. if they check all the boxes, they're they're at the top. Um, if the ones that don't really contribute to the goals that you've agreed on or as an organization go down on the list until they become more important and urgent or until you've tweaked the OKR system that came up in the uh in the workshop. Um, this is one type of pri prioritization. There's also the do we have the resources and capability available right now or do we need need to wait a little bit? Uh one example was when at Nero we wanted to change some some attributes in Jira uh so that we could track design work better in Jira. Um we wanted to do that and then the IT people said ah wait we're going to migrate Jira from on premise to the cloud. Jira is frozen for a couple of months. You cannot change anything. You can still add tickets and and stuff like that but you cannot change the uh the uh the instructions or the the implementation. Okay, that mean meant that initiative had to wait. So now next later there is another format for for road maps that I that I prefer. It has this now next later uh circles with uh room for bands of work uh that you can do like in the now in the next and later based on certain themes that you may have identified in your inventory like themes like uh people work u on skills and on boarding and happiness surveys and stuff like that. Uh another theme could be process stuff, process documentation, tracking work, tracking whether projects follow the process, stuff like that. And it could be a theme on tools and licensing and stuff like that. Um, the themes are your themes, the initiatives are your initiatives, the goals are your initiatives. You need to tweak this. I'm not going to I won't tell you what should be on here. That's up to you. Um, this is what my road map at Miro looked like. My design operations road map looked like this. I'm not kidding you. It looked like this. Well, actually, I am kidding you. I'll show you in a in a in a second why. Um it had like references to OKRs for each of the design ops initiatives. Uh uh so we could show how design- ops work would contribute to goals of the organization. Um uh there's another step in the five or two steps in the five-step program that is about distributing the work because you can never do it alone and then coordinating it again making sure that progress is measured and stuff like that. A good way to kick off that is to write briefs briefings for uh for your design ops initiatives. And this is an example of a briefing for one of the examples that we didn't show. But it a briefing has a title, a goal for the team, uh a goal for the initiative, uh the expected outcome, uh who would be the stakeholders for that are relevant for this initiative, who should be uh who could be good team members, uh and how we how do they report on progress, which could be every Wednesday morning they have a meeting and you just listen in. Um step five is about metrics, measuring the impact of such an initiative. What is the current state? What is the state that we want to reach when the initiative is running when it's or when it's done? What what kind of behavior change do we see? What kind of change in percentages, numbers, whatever do do we see? Um there are many potential metrics and I can say it depends only so many times a day but it depends on your organization which metrics are good for you. But here are some examples and the it starts with the typical product project management triad of uh quality, speed and budget and you can pick two and uh and the other the other one will suffer. Um but it could be like the number of designers if you're growing how many designers do we have? How many people do we count as as designers? Because there may be some people in the front end uh uh engineering world that you want to count as designers. Do researchers count as big D designers? Do they count? Are they part of of our team? I was once in an innovation unit and my designers were not counted as as designers. They were not sent the newsletter. They were not uh supported by by the design ops team. They were sort of the kids in a garage that didn't count. Uh and I I made them count. I made that change and suddenly the number of designers went up. That's good. Um then there are some some design ops metrics that as a design person you want to care about and designer happiness. are designers happy with the circumstances that uh that are currently in place u is a big one but for example and I'll go fast the last one the time to first review was one uh at Mero when Mero was growing fast and we were adding more designers we wanted to track whether they were uh productive fast enough like you want you you start hiring people you start paying them you want them to be productive members of the design community and uh uh one uh um sign that they were productive members was that they contributed to uh what we called product review meetings where they were presenting their work in a product review meeting. If that was the case, we c we we use that as a as a place or as a as a sign that they were productive members. So the time from when they got hired to the moment that they were productive members of the of the of the community was uh uh something that we wanted to measure and we wanted to make short. We wanted a time to make sure so they became effective fast which meant uh if this number wasn't going down then we we weren't do doing onboarding well or they it took too long before they got known and assigned to teams. So onboarding and assignment of designers were uh were investigated if this number if this number would be would stay low we would start fixing the onboarding and the assignment process. So this is where I said I lied. This is what the actual Miro design ops work uh road map looked like. It had metrics as well for each of the for for the initiatives. So we had uh an initiative linked to a goal and uh with metrics uh associated to it. That's my five-step program. Um I think you should have a design ops road map uh to make sure that the right design ops initiatives so the ones you inventoried uh are organized in the executed in the right order with the right people with the biggest possible impact and that impact is um increasing the chances of good design happening right and good design means it's good for business and Gartner the the big business analyst they've already predicted that teams that have a design support from design ops are uh uh more effective. They increase the revenue of the company at twice the rate of competitors who don't have a design ops team. Design ops is good for business. If you need to convince your boss that they need to give you time to spend on design ops, use this quote. Um so again we do all this we execute these initiatives with the intent of uh um making designers happier and those designers are you. So um thank you