Design Ops: How do you Scale

Nadia Udalova: Hi everyone. I'm extremely honored and super happy to be here today with you all. Actually, for the last three years, I have been following and participating in the UXDX events and they always have been super informative. So, I'm super happy to be facilitating this nice discussion around the scaling design today with you all. So, starting from yesterday you have been able to view the great talks of Patricia, Haley, GM and Miriam. I Hope many of you have done that. And I would like to encourage you if you have any questions or comments, please drop them into Slack. I would love your activity. So, we have collected all of the speakers today to talk together about design ops and try to figure out how they scale design at their organizations today. How do they orchestrate and optimize people around that? How do they work with the processes? How do they craft their work in order to amplify that design's value and impact the scale of the design of the organization? So, I still want to encourage everyone to drop any question, maybe any challenge that you have around scaling design in your work today. Drop that into the Slack and maybe our panelists will be able to give you some useful tips. I think that would be really really cool. So, what's exciting today is that we not only have the representative of the design departments like Miriam, Haley, Patrycja but we also have GM to represent the engineering and DevOps background in this conversation. So, it's supposed to be really exciting. Right. Let's dive into the topic a little bit. And during the last couple of years in our industry, I believe that the term design ops or design operations have gained this crazy popularity and the interest among people. However, I think between different professionals, between different organizations, it seems that the design operations or design ops have been getting different understanding or different feelings. So, to kick this panel off, I would like to throw this question at our panelists and ask them the following. So, how is your organization today understanding the design operation? How is it defined actually? And know GM we had an interesting conversation with you previously. How does Accenture see and define the design operation? What does it actually mean? Is it the process and methodology? Anything else?
Guillermo Martinez (GM): Well, I would say, of course it depends who you're asking in Accenture. We are half a million people at the end. So, each one has their own opinion. There is not a formal definition that we have for design ops. But in my view, when I mentioned something that maybe some people don't like or maybe some people laugh at that or even some of them they might like it. I'm the head of DevOps department. The only capability (inaudible) the Netherlands. And I hate the term dev ops. I don't like it at all. I think it leads to misconception of what it really means. DevOps in general, is not only putting developers and operational guys together. There is change in the philosophy on how we work and the delivery and so on same with design ops. I have the feeling there's a buzzword becoming a buzzword. Well, at the end, you want to brand it with some aria. Some type of something ending with ops because it became popular. And that's all for me. The philosophy behind of design ops or call it whatever, UXDX or call it anything. It's steady off of working together, of collaborating, working together. What we sometimes consider the product team. But the product team itself, by themselves cannot do that much. They need the attention. Their organization in their approach. How do they effort things? How do they move things forward? So, for me, that's the thing at the end. It's a way of working. It's a modern way of working that focuses on giving the customer what they want and give it as soon as possible. So, there's an early detection on their new experiences, an early delivery of the new experiences in a continuous manner. So, for me, that's what will be called design ops.
Nadia Udalova: For sure. That makes a lot of sense to me actually. Thanks for the perspective, Guillermo. Hailey, curious about your answer on that. As a UX manager, I know you have lots of experience at Shopify, but also before that at some other exciting companies. How would you define design integration?
Hayley Hughes: I think one thing that's important for word in defining design ops, is first to define design. So, my perspective on design is that it isn't just about craft. It's actually about the intent behind our outcomes. And I think that the ops part has to do with how do we operationalize that? How do we scale intent? And that's intended to be something that anyone can have on a team. It's not just about designers. So, enabling teams to have a human centered process, to embrace a culture of that intentional thinking is where I think design ops really thrives. So, for me, I would start always wouldn't talking about design ops with culture. And that for us at Shopify means the rituals that the teams have together. It means that the people that we invest in and hire and grow, it means the symbols in the culture. The things that represent teams and organization. The organization as a whole. And it also includes again, just different ways of working and the values that we stand for. So, those are some things that we think about when we talk about design ops.
Nadia Udalova: Love that. So, we talked about the workflow. We're talking right now about the culture and the people. I actually truly agree with that. I think this is what design ops would be really meaning to me as well. And of course, like when we are talking about maybe changing the cultures like it, or working to enable the people or creating new rituals. I guess an interesting question would be here to answer. Next one, it would be talking about some patterns or processes that your organizations, or maybe you have helped your organization to implement in order to scale the impact of the design practices. But which I know that you talked about, you gave actually a nice timeline. In a timely manner and your presentation about work. How was the design growing and design system implementation growing at Brandy? Would you mind giving us some highlighting some interesting patterns and processes that Brainy happens to implement in order to make design bigger or scale it as practice?
Patrycja Rozmus: So, first of all, I think design system as a thing that allows not only designers work better and faster, but also developers. And also in our case, other departments, so community managers that are doing designs for social media. HR who is doing some presentation for new joiners or every single member of Brainy that is designing something. So, I think the design system was a key factor that improved the quality of the design and design awareness across Brainy, inside Brainy. But when it comes to processes and as Hayley mentioned, the culture and how we for example, making sure that we are heading in the same direction. We introduced the cards with design principles, like first of all, design principles then the cards that allow us. So, play a little with this my (inaudible) . This is something interesting. Recently we hired a solutions architect to our team. Solutions, architects, meaning, UI engineer who is working with us and giving developers perspective on the side. Of course, we're working with developers from product teams, but right now we have also our core member developers. So, yeah, I think that's it. Maybe I will expand it later.
Nadia Udalova: It is exciting. I Have questions later in my list about the cards that you've been describing in your talk. By the way, everyone who is interested, we advise to go and watch Patrycja's talk around that process. I think that was fascinating. Miriam, so just now Patrycja mentioned, involving different functions into kind of the design process. In your talk, you will have been sharing about the importance of involvement of the engineering teams as well into the user validation. Then the (inaudible) validation sessions. Could you share some details on how do you bring those people in and how does that help you in your design?
Miriam Soesan: Sure. So, as I mentioned in the talk, in my talk and I think also Guillermo mentioned that a bit. Our approach is a bit more holistic in the sense that we're trying to help designers and developers educate each other on their own, on their fields. So, even if you are just a developer, we do want you to sit in sessions with designers. And the designers walk the developers through their ideas and vice versa so that they both get the understanding of the technical aspect and the creative aspect. And we do the same also when it comes to user testing, the results of the testing, the results of their research. Me, as the head of interaction design, I see it from my side is something that is very important to communicate. Let's say, to communicate our side of the story, our approach towards the user centric design also to the developers. So, that they understand why it is that we're asking them to do certain things. And we're not just annoying. We're not just picking or nitpicking on some tiny things. There is a reason behind that. And I think that if you really take developers and you show them that, they understand. And I got a lot of at the beginning when I just started, I got a lot of responses from developers saying like, Oh, I did not know that was even possible. Or I did not see that angle of the, of the story of the product of their development. So, I think it's, it's a learning process for everyone and that's why it's. It's very important for us to, to help designers, developers, engineers, work together and actually, yeah, inspire one another. It is indeed. Great. I see a lot of value in that. It's interesting, if you have any other perspectives on how maybe engineering can involve designers into their processes to create this better understanding or stronger collaboration. Yeah. I think yarmulke can answer that as the head of DevOps. And he, Guillermo and I worked together on many projects. But I think he can maybe share his experience with, let's say working with my designers on his projects. And then I think that would be a more interesting thing. Yeah
Guillermo Martinez (GM): From my side when we are going to build a solution, a product or call it whatever. We have to collaborate all together in the same direction. When we have different department, different silos, like it could be designers and developers. And each of them act a little bit independently. We are creating two different visions, so they are probably not really aligned. On one side, we have the designer to go in and we want to create something very cool, something very nice, something quite usable. And then we have the engineers. So, like we just want to play with the (inaudible) with the code and do fancy stuff, but just they (inaudible) so. So, at the end, what (inaudible) . Copying the style from, from Silicon Valley companies, we have to go in the same direction both together. So, of course, everyone heard about the cross-functional teams. We suggest something similar to cross functional teams, but not really as cross functional teams. I don't think everyone in our team should do everything, because, mastering all the skills in a team. It's impossible. If we think about the thing with design, with development, with cloud engineering, with security or the ideas within a team, having everyone doing everything won't happen. But creating an awareness, common awareness. That's good. That's very good. So, that's why I understand the other person's point of view on what they are asking for. And I might even sometimes get some interest and help out a little bit here and there. So, what we believe is in creating teams that they are, let's say a superhero's team. It's one has their own super scale, super experience, but we work together. We are (inaudible) my hand. And the designer with the lead most of the designing a domain of research domain together with the other guys of the team. So, everyone is involved in the product. Everyone has the single, that's the most important thing. We have to collaborate. And collaborate is not only talking or sending emails between one department and the other, that is really been hand by hand and making things together as an example. And some of the teams we've input people from marketing, for instance, that person was super happy when she joined the team. Like, yeah, she's not designers, it's not developers, she was not a tester, but it was part of the thing. Giving her vision, her inputs all the time, even learning a couple of things from development and see what it's like, hey guys, this tool, I really feel part of the team. They got ownership, increased motivation. And at the end they are creating altogether their own baby. Think about an orchestra, if different music players are playing their own music separately without doing it aligned, it will sound something terrible, even in all of them, they play instruments that great. If they don't align, we are not going to get a good result.
Nadia Udalova: That's a great example. I love it. Yeah. Well, thanks so much. I would like to turn this conversation into a part that probably is worrying a lot of the people. At least myself, for sure. I would be interested when we are talking about improving some of the systems on the company or building a design system. For example, in order to help build up certain consistency or processes, of course, it wouldn't be possible to do that without getting a buy-in from the management or from the leadership level. Hayley, in your talk, you actually mentioned how you worked on the partnership program and involving designers to share that knowledge between themselves to co-design the system and the new components, the new patterns there. How did you manage to get the buy-in from the leadership?
Hayley Hughes: That's a great question. I think one thing that's really important is looking over and above design ops and understanding the organizational structure of a company. And so again, not just focusing on design, but asking how can you bake the way that design systems work into just like everyday business? How a company runs and how it's measured? So, one thing that really helps get buy in is making sure that people within your organization are not just measured by whether or not they're contributing and shipping to product. But also that they are free to contribute to the systems that are within an organization. Because, usually, companies of a certain size have more than one design system. And so what we try to do is really do things like baking design systems into our career frameworks. Making sure that people are recognized for different types of work within a company. And then that means that it's not just the job of any one team, but it's actually the job of everyone too. In some way I can contribute components back to the system. Write new guidelines, build context around the surface areas that they're working on to reduce those silos. So, that's the first thing that comes to mind.
Nadia Udalova: Cool. That sounds actually pretty interesting. Patrycja, you have gone through a big process there at Brainl. And it seems like you have opened up also specific roles. Like you said, you're an engineer or something similar. How did you make sure that the business understands why they need such people on the team?
Patrycja Rozmus: Oh, it was a struggle. It was a very long struggle. And we are step-by-step, coming to the (inaudible) , like full stuff in the core team. But, when it comes to contributors to design system, we are doing something similar as Hayley sets. So, all people from product teams are contributing to the design system, so it's not centralized and it's baked into the process in fact. And I think that the key factor that management bought this was the fact that when we started this process. It was like one person that was working here and here with the design system and inside the product team. That's so amazing work that they could see the value. So, I think like showing the results, that's, that's the only way. But often it's about making an effort even after hours, because when we started the design system, it wasn't on the agenda. It had no priorities. So, we are working in a small team of three people. Often after hours, like almost every day, because we believed that this is a project that will make an impact and it did. It did. And after like the company saw that when we went public with our guidelines and also gave some assets to the whole company. That was like a game changer for us. And then it was really maybe not easy but easier to move forward with this project.
Nadia Udalova: Right. Right. So, it sounds like you needed to showcase, to work hard first to showcase their result and then the teams gained quite some belief and buy-in from the management layer.
Patrycja Rozmus: Yeah. I think it's classic. When I heard talks about these design systems. I think it's like a usual puff.
Nadia Udalova: Probably, yeah. For sure. We have an interesting question from the crowd. I hope I pronounce the name right, Valadez. And the question is, can you advise on any good books or articles around outcome oriented development? And our OQRs a way to actually do outcome oriented development or not? GM, probably that's a question to you or anybody who wants to step in?
Guillermo Martinez (GM): There are a couple of books. They are very interesting. The ones from Jane Kim. I don't recall all of them, the titles and so on. But from the IT revolution as the editorial and Jane Kim is the author. He's the heavy, let's say the father of DevOps. I think our devOps, the philosophy of really trying to work in an efficient manner and customer centric oriented. He has a couple of points there. That they are very interesting. Also one book from the miracle healing as well as the modern enterprise landscape. Something like that is called, I can't remember exactly. Also a very interesting book and OQRs. Ofcourse, they're the heap of the year, last year. I think they work quite well. They are not new. They are from the sixties or seventies. Some guys, they were great at them. (Inaudible) in companies and IBM, for instance, they were fine. I mean, at the end you want to get a goal and you'll want to find a way on how to reach the goal. So, it's just a way of working where you are going towards an end and you find a way so how to make it possible instead of micromanagement or traditionalist style. I like OQR. I'm using that right now for our capability in Accenture. And I think it's somehow increasing the creativeness of the people and also the motivation, which I think is quite important.
Nadia Udalova: Yeah. Definitely a good technique. We're also following that at getting up really really successfully. So, definitely. Thanks for those advices. I actually have another question. We have talked about the importance of building other systems to maybe creating some processes in order to scale the design. But I'm curious. When is it a good time for an organization to put powers into that or put effort or money? For example, building a design system or getting a certain process around the design. Anybody wants to take that question? (inaudible) You're smiling.
Patrycja Rozmus: I think it comes with the scale or maybe in our case, we were a very small team just two years ago. We were very small. Now we are small, but we know that we are going to be big. And we are preparing for scaling. So, on one hand we know that there will be more designers. So, the design system has a place in our company and on the other hand, we have quite big products. Because we are the biggest online learning community in the world. So, we have 20, sorry, 250 millions views and counting. So, this is like a big product, small team, and this team will be bigger. So, I think that for us, it's a no brainer to scale, but maybe if you have a startup and you don't know what's going to happen, maybe it doesn't make sense to focus on a design system and processes and stuff like that.
Nadia Udalova: Thanks. Thanks for that. Hayley, do you have anything to add there?
Hayley Hughes: Yeah, I would say that some indicators that operationalizing is an important factor to things to Patrycja's point. Like one of them would be growth. But another thing that I would bring up is just even just a very small team needs a way to work together. If you think about culture is where people are in even a startup or a small company or a nonprofit, some another or type of organization. I think there's still people come and go. Right? And the minute that someone leaves and someone new comes in there can be a sort of loss of institutional knowledge from that last person. So, making sure that people are documenting their thinking and their ways of working. And making sure that people understand how to work together when they're onboarding and coming into a new organization or have their own personal development around career growth. I don't know of anyone who wants to come to a company and not understand the steps to career development. And so I think just those basic fundamentals are sort of just, I would say are good about like good for running good business. Whether if you do it at the smallest size, you're just doing something that maybe doesn't scale yet. And then as you grow, you prototyped it several times. Within that small group to keep going. So, yeah. I think that's just something to keep in mind is that, I mean, to your point, I've often been asked if a really small company has a design system. And my point of view would be that maybe even to Patrycja's point, if it's not the first thing that you invest in the minute that someone else starts working on a design, that isn't one single designer is an opportunity to start documenting the rationale and the thinking behind the work.
Nadia Udalova: For sure. It's a great point. I think we could look into that as a preparation for this scale just like, as you said, the progression for the orchestration and optimization of the process. This is at the end, what kind of design ops is as we align in the beginning and also, yeah, to preparing to scale the design and its value in the org. Thanks a lot for all of your answers. Thanks for them for the great questions from the crowd. And I really encourage you to ask the rest of the questions in the Slack or being directly to the speakers, to the panelists. Watch the great talks from Miriam, Hayley, Guillermo and Patrycja. There is a lot of useful content. And John, back to you.