Design Ops: How do you Scale

Hayley Hughes, Patrycja Rozmus, Guillermo Martinez, Miriam Soesan, Nadia Udalova at UXDX Europe. Video: https://www.youtube.com/watch?v=fBb6eNz8cFU

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Framing the panel: how do you scale design?

[00:00:00] Nadia: 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 scaling design today with you all. Starting from yesterday you have been able to view the great talks of Patrycja, Hayley, 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.

[00:00:47] Nadia: 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 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.

[00:01:35] Nadia: What's exciting today is that we not only have the representatives of the design departments like Miriam, Hayley, Patrycja, but we also have GM to represent the engineering and DevOps background in this conversation. So it's supposed to be really exciting.

How each organization defines design ops

[00:01:54] Nadia: Right, let's dive into the topic a little bit. During the last couple of years in our industry, I believe that the term design ops or design operations has gained this crazy popularity and interest among people. However, I think between different professionals, between different organizations, it seems that 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. How is your organization today understanding design operations? How is it defined actually? And GM, we had an interesting conversation with you previously. How does Accenture see and define design operations? What does it actually mean? Is it the process and methodology, anything else?

[00:02:51] Guillermo: 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 — and when I mention something that maybe some people don't like, or maybe some people laugh at, or even some of them might like it — I'm the head of the DevOps department, the only capability [?] the Netherlands, and I hate the term DevOps. I don't like it at all. I think it leads to a misconception of what it really means. DevOps in general is not only putting developers and operational guys together. There is a 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, it's becoming a buzzword. Well, at the end, you want to brand it with some area, some type of something ending with ops, because it became popular.

[00:03:53] Guillermo: And that's all for me. The philosophy behind design ops, or call it whatever, UXDX or call it anything, it's steady[?] 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, 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 giving it as soon as possible. So there's an early detection of their new experiences, an early delivery of the new experiences in a continuous manner. So for me, that's what would be called design ops.

[00:04:31] Nadia: For sure. That makes a lot of sense to me actually. Thanks for the perspective, Guillermo. Hayley, 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[?]?

[00:04:52] Hayley: I think one thing that's important in defining design ops is first to define design. 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.

[00:05:33] Hayley: So for me, I would always start talking about design ops with culture. And that for us at Shopify means the rituals that the teams have together. It means the people that we invest in and hire and grow. It means the symbols in the culture, the things that represent teams and 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.

Patterns and processes: a design system beyond the design team

[00:06:10] Nadia: 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 really be meaning to me as well. And of course, when we are talking about maybe changing the culture, or working to enable the people, or creating new rituals, I guess an interesting question would be here to answer next: 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.

[00:06:53] Nadia: Patrycja, I know that you talked about, you gave actually a nice timeline in a timely manner in your presentation about how design was growing and design system implementation growing at Brainly. Would you mind highlighting some interesting patterns and processes that Brainly happens to implement in order to make design bigger or scale it as a practice?

[00:07:19] Patrycja: So first of all, I think design system as a thing that allows not only designers to 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 presentations for new joiners, or every single member of Brainly 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 Brainly, inside Brainly.

[00:08:03] Patrycja: But when it comes to processes, and as Hayley mentioned, the culture, and how we for example are 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 to play a little with this. [?] This is something interesting. Recently we hired a solutions architect to our team. Solutions architect meaning a UI engineer who is working with us and giving the developer's 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.

Getting designers and developers to educate each other

[00:09:03] Nadia: 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 you 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 the design process. In your talk you have been sharing about the importance of involvement of the engineering teams as well into the user validation, the validation sessions. Could you share some details on how do you bring those people in and how does that help you in your design?

[00:09:44] Miriam: Sure. So as I mentioned 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 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 the research.

[00:10:33] Miriam: Me, as the head of interaction design, I see it from my side as something that is very important to communicate. Let's say, to communicate our side of the story, our approach towards 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 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.

[00:11:15] Miriam: And I got a lot, 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 story, of the product, of the development. So I think it's a learning process for everyone, and that's why it's very important for us to help designers, developers, engineers work together and actually, yeah, inspire one another.

[00:11:47] Nadia: 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.

[00:12:00] Miriam: Yeah, I think Guillermo can answer that as the head of DevOps. He 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.

Superhero teams rather than everyone doing everything

[00:12:27] Guillermo: 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 departments, 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 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 [?] with the code and do fancy stuff, but just they [?]. So at the end, what [?], copying the style from Silicon Valley companies, we have to go in the same direction, both together.

[00:13:14] Guillermo: So of course everyone heard about 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.

[00:14:01] Guillermo: So what we believe is in creating teams that are, let's say, a superhero's team. Each one has their own super skill, super experience, but we work together. We are [?] my hand. And the designer will lead most of the design domain or research domain together with the other guys of the team. So everyone is involved in the product. Everyone has a say[?], 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 being hand by hand and making things together.

[00:14:34] Guillermo: As an example, in 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 a designer, she's not a developer, she was not a tester, but she was part of the thing, giving her vision, her inputs all the time, even learning a couple of things from development and seeing 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 if all of them play instruments that great. If they don't align, we are not going to get a good result.

Getting buy-in from leadership

[00:15:15] Nadia: 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 people, at least myself for sure. I would be interested, when we are talking about improving some of the systems in 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?

[00:16:07] Hayley: 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.

[00:17:06] Hayley: 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 to, in some way, 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.

[00:17:34] Nadia: Cool, that sounds actually pretty interesting. Patrycja, you have gone through a big process there at Brainly, and it seems like you have opened up also specific roles, like you said, a UI engineer or something similar. How did you make sure that the business understands why they need such people on the team?

[00:17:57] Patrycja: Oh, it was a struggle. It was a very long struggle. And we are step by step coming to [?], like full staff in the core team. But when it comes to contributors to the design system, we are doing something similar as Hayley said. 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.

[00:18:29] Patrycja: 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. They did such amazing work that they could see the value. So I think, like, showing the results, 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 priority. So we were 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 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.

[00:20:00] Nadia: Right, right. So it sounds like you needed to showcase, to work hard first to showcase the result, and then the teams gained quite some belief and buy-in from the management layer.

[00:20:12] Patrycja: Yeah, I think it's classic. When I hear talks about these design systems, I think it's like a usual path.

[00:20:25] Nadia: Probably, yeah, for sure.

Audience question: books on outcome oriented development, and OKRs

[00:20:25] Nadia: 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 are OKRs 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?

[00:20:47] Guillermo: There are a couple of books, they are very interesting, the ones from Gene Kim. I don't recall all of them, the titles and so on, but from IT Revolution as the editorial, and Gene Kim is the author. He's the heavy, let's say the father of DevOps, I think, of DevOps, the philosophy of really trying to work in an efficient manner and customer centric oriented. He has a couple of points there that are very interesting. Also one book from the miracle healing[?] as well as the modern enterprise landscape, something like that it's called, I can't remember exactly. Also a very interesting book.

[00:21:24] Guillermo: And OKRs, of course, they're the hype 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, in companies and IBM for instance, they were fine. I mean, at the end you want to get a goal and you 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 how to make it possible, instead of micromanagement or a traditionalist style. I like OKRs. 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.

When is the right time to invest in a design system?

[00:22:13] Nadia: Yeah, definitely a good technique. We're also following that and getting on really, really successfully. So definitely, thanks for those pieces of advice. I actually have another question. We have talked about the importance of building other systems, of 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? You're smiling.

[00:22:53] Patrycja: 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 250 million 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.

[00:24:07] Nadia: Thanks, thanks for that. Hayley, do you have anything to add there?

[00:24:11] Hayley: Yeah, I would say that some indicators that operationalizing is an important factor, to Patrycja's point, like one of them would be growth. But another thing that I would bring up is that even just a very small team needs a way to work together. If you think about culture as where people are, in even a startup or a small company or a nonprofit or some other 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.

[00:25:03] Hayley: 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, I would say, good for running a 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.

[00:25:55] Hayley: So yeah, I think that's just something to keep in mind. To your point, I've often been asked if a really small company should have 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.

[00:26:20] Nadia: For sure, it's a great point. I think we could look into that as a preparation for the 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 aligned in the beginning, and also, yeah, preparing to scale the design and its value in the org. Thanks a lot for all of your answers. Thanks for the great questions from the crowd. And I really encourage you to ask the rest of the questions in the Slack, or go 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.