Episode 41 highlights – Erica Rider podcast about DesignOps 2.0 at Paypal :

• DesignOps 2.0 at Paypal
• Shifting the focus from scaling designers to scaling design itself
• Comparing DesignOps and DevOps
• Changing the responsibilities of UX designers so a small team can focus on the work that matters
• Scaling design without hiring more designers
• Tools and processes to for successful DesignOps

Episode Transcript

(transcription was automated and has been minimally edited, please excuse any typos or weirdness 😀 )

Zack Naylor 0:00
This is the Aurelius podcast episode 41 with Erica Rider. I’m Zack Naylor, co founder at Aurelius and your host for the earliest podcast where we discuss all things UX research and product. This time, I got a chance to chat with Erica Rider, the UX lead for the internal tools team at PayPal, Erica shares with us her vision and execution for what they call design ops 2.0. She talks with us about how her and her team created tools and processes to support an organization of nearly 1000 developers in 60 different products with only three designers. That’s just insane. A big part of this for her and her team is flipping the script on how we think about design Ops, going from the idea of scaling designers to simply scaling design. This was an awesome chat, where she shares exactly how they do this challenges they faced in stories of successfully supporting such a large company with so few resources. The earliest podcast is brought to you by Aurelius, the powerful research repository and insights platform release helps you analyze, search and share all your research in one place. Check us out at a release lab.com. That’s a u r e li us, la b.com. Okay, let’s get to it.

Zack Naylor
Hey, Erica. Oh, how’s it going?

Erica Rider 1:26
It’s going pretty good. How are you?

Zack Naylor 1:27
I’m doing just fine. I’m glad to have you on and have a discussion on our podcast. This episode, I’m actually really excited to chat with you about some things, some specific work that you’re doing that you had shared with me before. You know, before we dive in, I would really like if you could introduce yourself, maybe tell the folks listening about you know, the work you’re doing who you are things you’re passionate about.

Erica Rider 1:47
Okay. Well, my name is Erica, writer, and I am the user experience lead for the tools and platform experience group at PayPal, we’re under the CTO organization. And we are responsible for all of the tools and platforms used to build and run paypals business and all the other businesses. It’s a large organization. But we’re a small UX group of three people. And we’re responsible for working with about 1000 developers, somewhere 60 to 100 different products.

Zack Naylor 2:17
That’s pretty serious to have a team of three supporting, you know, number one that large of an organization. But then number two that many developers have to believe that comes with some pretty unique challenges. Oh, it’s

Erica Rider 2:28
insane. Yeah. I was just gonna say it actually kind of drove where we’re at today, we because we weren’t going to get more people. And it drove us to actually be innovative to solve this problem here.

Zack Naylor 2:40
Yeah, well, so tell us a little bit more about that. Because I think you have a pretty unique way of doing it. It was really interesting that I believe you were calling design ops 2.0. Is that right?

Erica Rider 2:51
Yeah, it’s interesting, because there’s a little little bit of a clash between traditional design ops and design ops 2.0, I don’t really think there is, you know, design Ops, initially was as a model for scaling designers, as UX wanted to seat at the table, and companies became more aware of the importance of UX for product development and product design, they got the seat at the table, and then they realized, Oh, we have to actually deliver on this stuff. So the traditional design ops model was to scale designers adding more and more designers. And once you got a large design team, you needed a way to actually support that large design team. So design ops was originally is or traditional design ops is about the operations. To support that large design organization, we were never going to have a large design organization, we’re a ratio of about three, sorry, one to 311 is about our designer to developer ratio. And if we were going to try and get to that traditional model of one to 10, we would have a huge design organization within an internal group, which was not going to ever happen. And so we started looking at ways and how are we going to do this. And we traveled down the traditional design Ops, some of the traditional design ops models here and some of the more traditional ways that design teams scale. At one point, as we were kind of evolving and innovating on stuff, we started to think about it, we thought, well, we’re looking at design Ops, and we thought, Well, okay, well, what if we actually look a little closer at DevOps? Because we’re supporting a lot of DevOps teams, and DevOps, I don’t know how much you know about DevOps. But you know, in nutshell, there used to be a development groups or product development groups, and there was an ops team and the product development groups would produce a product and then they would have to give it to the ops team and they would have to wait for the ops team to do all the stuff to push it out to production. And so as DevOps evolved really what happened was the ops team didn’t go away. What the ops team did was now they evolved kind of this walled garden or these guardrails and the platform and everything there for the product teams to successfully deliver their applications live to production on their own, so can a self service model Right, but they made it so that everything was gonna be secure and safe. And they gave them that freedom, but they continue to kind of have that safety net. The ops team is still there. So we started looking at it, we thought, Okay, well, what if we actually scaled design that way? What if we kind of looked at this approach differently? And what if we said, What? What is it that we would need to do to make product teams successful? Right? How can we help product teams successfully deliver useful and usable products? That’s where the design ops two came was it was really about aligning design ops with DevOps and taking that same fundamental methodology or approach to design and scaling design and some operationalizing design, not creating an operational layer to support designers. Yeah.

Zack Naylor 5:40
Interesting. So if I were to summarize a little bit, you know, what you just shared is, you kind of went from this focus of design operations of scaling designers, and you tried to focus on scaling, just the practice or the execution of design. Is that fair? Yeah, a fair size.

Erica Rider 5:56
It was it was not about scaling designers. It was about scaling design.

Zack Naylor 5:59
Interesting. So talk to me about what that looks like practically. Right. So I think I certainly get it at a conceptual level. How do you do that? Right. That’s the next question to ask.

Erica Rider 6:10
Yeah, I get lots of questions about this. This, I could talk for hours on this part alone, we have an evolution of the roles and responsibilities. At a high level, product teams have always been responsible for delivering a bug free code that’s secure and low latency and all the stuff, right? They were never responsible for delivering a good user experience. Right? So we flipped that around. We said, okay, you know, what your responsibility is for delivering a good user experience. And actually, a lot of the stuff that you were responsible before, the reason you were responsible for them is because of the user experience. latency is a user experience. issue. If you have an API call if I’m, if I’m a user, and I’m dealing with your API call, and I have to wait two minutes for a response from the API call. That’s a poor user experience. Mm hmm. Right? If I click some button, and I get a 504 error, that’s a user experience problem. Right? That impacts my user experience, really. So we kind of expanded and we started saying, look, this is what user experiences, this is what you care about. Right? That means that the UX team, I get the question a lot of like, well, aren’t you putting you UX people out of work? The answer is no, for x, absolutely not. Right, we’re absolutely not putting them out of work. What we’re doing though, is we are shifting their responsibility. At a key level, our responsibility is to provide the tools and environment for product teams to successfully deliver useful and usable products. Right. And so I can get more into detail on that. But once we get to a point where they are successfully delivering that stuff, we never expected product team to get 100% of the way there on their own, we expect them to get 80%. If they get 80% there on their own. That’s great, right? Because that frees up a huge amount of time for our UX team to actually do the big ticket issues. The main things that we’re working on in our group is we’re working on what we call the console. And this is a overall platform for delivering what we call extensions. But all the functionality is a single unified platform. It’s not just a back end platform, it’s actually a UI platform, where we used to have a bunch of different products. And you just had to travel through seven different products to complete a workflow. Our goal now is that they go to this console, and they go through one end to end flow within this console. Right. And all these extensions that were these individual products are not part of the same console. Well, what UX focuses on now is we focus on how do we deliver a platform that is going to be cohesive, and consistent and is going to deliver a parade predictable experience across everything for the end users of that. And so we deal with things like okay, well, let’s take search, every one of these products that we have has some form of search. But we can’t have a platform where you go into some kind of extension and you perform search in that extension. Search is going to be a platform level function, there needs to be search box that is in the global header of this platform. And when I search in that box, I need to search across all the extensions across the entire platform, right? If we look at an object may have four different application or four different of these products that deal with the same type of object, like see an application. If I’m doing a search for a application XYZ, I need to come up with a result for the application. And all of these extensions need to provide information about the application. I can’t look at the search results and say, Okay, well, here’s application XYZ in this app. And then here it is in this or this product, and then this product and this product, we can’t give me 10 different results for the same application. I need one application with all the information about it. Hmm. And so we focus on that, right, we don’t focus, we operationalize all the key things like 90% or mamita, or like 80% of our The screens that are within this platform are the same screen screen with standard navigation. And there is a detail list, right? It’s just a list of objects on, you might click on them. And you might view more details about an object in the list. There might be some kind of chart that goes with that list. That, you know, there’s some slight variations, but 80%, are exactly the same. So where traditionally, you’d have a UX person that is building all of those pages on their own, and it’s the same page over and over and over and over again, it’s mind numbing, you’re spending weeks creating mindless error messages, right? In reality, I got to a point where I got tired of people asking, Hey, can you shoot me an error message? And I’m like, No, do it yourself. So I created the platform for them to do it. There’s

Zack Naylor 10:48
interesting,

Erica Rider 10:49
I don’t want to do this anymore. No, I don’t have time to do what matters here.

Zack Naylor 10:54
Yeah, especially that last point, you don’t have time to do what matters. That’s something I’ve heard. I’ve heard a lot of people kind of say where it particularly even in research, right is, they’re kind of stuck in retrieving past insights, or retrieving past designs and stuff, and getting those to the here. And now as opposed to doing some of the foundational work that’s going to take us a step forward. And I want to come back to that later. But something there’s a couple things you said in here some questions that I want to ask as follow on. The first one is, how did you get everybody aligned to this vision? Right, this change? Because it’s, it is a shift rather than them saying, Hey, can you give me this error message to hear our I think, as you put it, the tools and processes to facilitate that

Erica Rider 11:33
sales? Okay, a lot of sales. So it was somewhat of an evolution of how we got there, I traveled down the traditional Palouse of Okay, well, we need to have, we’re not going to get more people, more designers. So we have to have a way that we can actually support these end product teams. And so I knew right away, well, we need to have a UI framework, we need to have some kind of tooling where they can go in and do some designs on their own, we need to have a way of supporting them and doing their own research, we need to have kind of a way standards, somehow, all the traditional stuff that design teams go through. But problem is is that I’m not dealing with designers and dealing with product teams, and I can’t have them, I can’t expect them to learn 15 different products, I can’t expect them to learn how to do sketch and envision and something else for managing a design system and understanding all of our design patterns and design standards and being able to read that all the time. Mm hmm. It’s never gonna happen. And then we have three people. And so all of a sudden, we become in this position where we’re constantly policing these teams, we don’t have the resources to do that either. And so as we kind of travel down this route, I have had a good working relationship with the UI architect, or kind of the main architect for our console platform, we’ve actually worked really closely together, we have lots of conversations and work really closely about kind of how the lower level changes in the infrastructure are the architecture of the platform, impact the higher level user experience, so much that we get down into kind of like, what is the structure for URL routes. And so our URL routes are completely human readable. And they also match 100%, our information architecture, you know, when you look at the URL, you know exactly what you’re going to get. And I know exactly what to show based on that URL. And so we do focus on those things that we fundamentally can’t change later. If we don’t have it right in the beginning, we can’t go back and change it later. We can change blue to pink if we want, but we cannot change certain things. At one point, we we kind of switched away, we started using UX pin, because it was it had a good enough solution where we could bring everything together we had, we had the design tools, we could create a design system in UX pin we could have, we could have components where they drug and snap things together. It was you know, a lot of people using figma now, but UX pen kind of had actually more functionality for us and figma has now it had it two years ago. And we create specs in it we can do. We can be really collaborative working in it and everything else. It was good. But I would say in the summer of 2019, they started releasing this beta technology called merge. And what merge did or does is it allows us to use react components as these prototyping components. Mm hmm. So where we got to was, we have a UI framework that is built in react. That UI framework is what our product teams used to build their products. And it’s also the exact same library that we use to build all of our prototypes. And so we’re not doing like, it’s not like a basic storybook integration where we’re dragging up pictures and those pictures link up to a component. It’s the same component. It’s a live component. And when we make changes upstream, we might make change the CSS, that change passes down, and it updates, everything and all of our products that are using that UI framework. And it updates all of our prototypes. So we don’t have that drift, and fundamentally what we build in our prototypes, we never build anything in our prototypes that cannot be built in a product because 100%, the same components, use all the same layout components and everything. And so it’s 100%, translatable between the two. So much so that I’ve worked with other. I’ve worked with product teams doing this. And they’ve been showing me the beta of the product. And they flip back and forth between the prototype. And I have trouble keeping up. I’m like, Wait, are we looking at the prototype? Are we looking at the beta? We’re looking at the beta. Now I can go back to the prototype and like, they look exactly the same. That’s not, it’s not like, Hey, here’s a reference, here’s a representation. And we’re asking you to build it is exactly the same. I went to Stan, who was our UI lead, and I said, Hey, what do you think about this technology? He looked at it a little bit, and he goes, Oh, this is pretty cool. As this has a lot of potential. And it came back. This was on like a Friday, came back up on Monday. He’s like, look what I did. And he had no, there was some basic components, maybe four or five basic components. And they were working, they were our UI components. And you could drag them into a prototype. They had, let’s say, it was like a textbox that you could type in. And we had the drop downs, there were some basic form elements, but they weren’t, it wasn’t a picture of a drop down, it was a drop down, and we could we could populate what was going to be in the drop down. So I didn’t have to create five different screens of a drop down, that showed different states, I had a drop down with all of the names that work. Exactly. And so I was like, this is pretty cool. So with that, I was able to go to my boss, who is the head of product for organization of our developer tools experience, and said, hey, look at this, and I’ve been talking about this notion of Hey, I think we can go this direction. And we can really enable product teams, and they can be successful. And what if we could do this and that and people looked at me like I was crazy. It was a lot of perseverance. And a lot of time of people looking at me like I was completely batshit. Crazy.

And it wasn’t until I showed this, that my boss was like, Oh, Oh, I get it. Now I see what you’re talking about, gave us a little bit more time. And we worked through a few other components and said, Okay, look at this. And I really think this has got something here, I think we can make this work. He kind of gave us the Go ahead. That was where he kind of got on board and became a supporter. So much so that he worked with the developer, the development and leads for this console platform, we stopped development on the UI for the console platform for about two months, while we built out a proof of concept of components that we would need to actually make this work. And it was enough where I could take it. And I could build any prototype for any extension, a basic prototype, we didn’t have everything. But it wasn’t something I could hand out yet. But it was enough that I really could show like this is the power. And I could show we had data grids or detail lists that we could take a CSV. So we could basically write up all the details for a detailed list or a table and excel and we could export that to a CSV, and then I could just paste it in to textbox for the data grid that was on the screen and bam, it would just render it was brand new, this render this detail list, detail list data grid table, they’re all the same for me. It’s just are there different names for the same component. But it wasn’t just Hey, this looks like this edit filtering. You could start to get a filter box. And you could type in the filter box and it would filter the results in the list. Right? work? So basically, selection work, it was the component. Yeah,

Zack Naylor 18:35
I mean, so basically just production ready code, production ready interactivity, but still in the design and iteration phase

Erica Rider 18:42
superpower? It was, it looked like a fully functioning product, but it was a prototype. Awesome. Early on, Stan, and I had this common agreement that there is no such thing as pixel perfect mock ups. It doesn’t. Everybody talks about it. But it pixel perfect mock up is still just, it’s a artist representation of what they think this might be. Mm hmm. It’s a no way pixel perfect, right? Unless you’re building with the same actual same components that you’re going to use to build it. It’s never going to be exactly that developers are never going to get exactly what you did in that drawing.

Zack Naylor 19:20
Right? Well, and then even if you do, right, the nature of the work in a digital world is the medium, which that thing is consumed on whether it’s a laptop or a phone, or a giant TV screen or projector in a conference room. Completely throws out anything you designed for right because once the real world gets gets his hands on it, it distorts everything, all the intentions you had anyway.

Erica Rider 19:43
Oh, exactly. So we have this theory. Okay, I think I can do this. I think I think I can convince for me it’s I convince and I work with I have a team that we work on this together to deliver this. But I kind of come up with this nutty idea and I will do enough time like a Let’s go this direction to kind of illustrate what I want to do. I have other people who are kind of taking it and they run with it, they’re really good at running with it. And so I started out kind of doing some of these, I would do some prototypes for the console and different products with this. And I would show where a something that was, let’s say, just a basic page with a global header and some navigation and view header and data grid, it was a pretty simple page, in the olden days, just maybe a couple years ago, because of that data grid, that data grid could make that page take many, many hours or days, just because of all the stuff that I get to deal with in there. I went from many, many hours or a day or more minutes, so much so that I could be in a meeting. And this is where I really got the buy in on this is I could be in a meeting. And I could be talking with anybody, I would just kind of bring up a blank prototype page with nothing on it, I would build a prototype, and about two minutes, fully functioning, and then run it and you’d see it was a fully functioning page, it looked just like a product, not just look, but it acted just like a product right at. And that really was because there was no way I could talk to that it was really seeing what you got any end and how fast you could do it. At that time, it was still really, there wasn’t enough stuff there. It was enough that I could do it. The other designers could do it. But it really required a designer to do it. And so that was about January, this last January is where that’s where we were, we knew that we wanted to get product teams to that point. And so I kind of focused on what do we need to do to get this to enable anybody to be able to pick this up. And one of the other designers said, Hey, you know, we really need to have something like on Udemy, or LinkedIn learning. And I said, Oh my God, that’s an amazing idea. Make it so

this is what I want, make it so I want to own Udemy. Right, and we were still building out these components. And we didn’t have enough to where we could really make the snap together. And we could build prototypes that were 100% using these components. And so he took that on. And we have over three and a half hours of training videos, to teach anybody how to use all of our components. Amazing. And at the same time, the component library that we use, we decided to use Microsoft fluent. It was fabric at the time now it’s called fluent. That was because it came with most of the component that came with a lot of components that were really useful, given the limited size of our team, not just our UX team, but the development team. There was no way we could support building a new component library or another one yet another component library. And so we wanted to find one that was working already. PayPal, the consumer side has what they call PayPal UI and they use design, they use CSS tokens. And so one of our requirements was we have to be able to take their CSS tokens and inject them into this, whatever this UI toolkit was, so that we actually could align with PayPal, our whole goal was can we take something that exists so we don’t have to maintain it? And can we make this look like an enterprise ready version of PayPal UI, it has to look like its PayPal product? Sure. It can’t be a bunch of different things. And so we went with that, because we already had these components, it was just a matter of getting all the ones we needed into UX pin into the merge library, get it in there, you could bring them straight in, but it required you to write JSON, to actually configure it, we had to write some custom wrappers that gave us UI to configure these components. One of the other designers took it on and just kind of started bringing them in and writing these components, writing the wrappers for these components bring him in, and we went from four or five to, Oh, geez, I don’t even know how he got to probably about 4040 components. I was working with the engineering manager for the console. And I said, Look, I know you believe in this, we’re not going to be successful. I need unless I have a developer to work on this. I need somebody to bring this last mile. I had started working with a few product teams in early trial, what’s called an alpha phase. And I thought, Okay, well, I’m skeptical, but if they can do it, this kind of gives me an understanding of where we need to go. They were taking my early set that we had, and I flew out to Austin and met with his team and I met with I worked with them for about two days. First day, we just kind of talked about what they were doing, what their product was. And I got an understanding of it. And I kind of broke down a little bit more of here’s a design thinking, stop thinking from an engineering standpoint and start thinking from your user standpoint, what are they trying to do? Where are they trying to get out of this? Why are they here? How do I know where I am? How do I know what to do? How do I know what I’m looking at? How do I know? What am I supposed to do next? How do I get out of here? Sure. Just some basic questions that they should be able to ask and answer on every single screen. And then the second day I spent the morning opened up, you expand and said okay, well here’s how I would just kind of use this. And there was probably seven of us in a conference room and we would talk which is talk about what they’re trying to do and I would drag stuff out there and I gave them each a license to it. And then a couple of the Developers on the team started digging into it. And they sort of trying stuff out and like, don’t worry about breaking stuff, you’re not going to break anything we can’t fix, just do it, right, just play with it, get used to it get comfortable. So we spent a day kind of doing that. And then the third day in the morning, I met with them again and kind of got them started. So they could start doing it and feeling comfortable. And I was supposed to spend the day with him. But I got booked up into meetings, I would go into these other meetings, talk a little bit about what was going on, and why I was there. And they would bring up what they were working on just as a talking point. And I’m like, Oh, my God, what is this, I just left them five minutes ago, this page was in here. And it was a fully fleshed out page in their prototype. And I was like, Oh, my God, this is good. This is really good. And that was when I was like, Oh, my God, this is gonna work.

Zack Naylor 25:47
That’s really awesome. That’s really awesome.

Erica Rider 25:50
I think this is gonna work. And then I left and I didn’t hear anything from them for two months. And all of a sudden, I hear they’re presenting a beta version of their product, it was less than two months. And it was during the start of this pandemic. While it was less than two months, and I got freaked out. I’m like, Oh my god, they’re presenting this to our CTO, I haven’t seen this. I am terrified. Oh, my God, please say hey, can you can we set up a time and go over this? That was a team where when they presented it to me, they went back and forth between the prototype and their beta. I didn’t know what I was looking at. I’m like, Wait, is this the beta? Or is this the prototype? And we went through this. When we went through it, I’m like, okay, you have this data grid here that doesn’t have any padding around it on the page. And this place, here, you’re using the wrong icon for actions. And here you’re using a primary button where you shouldn’t be using one. That’s it. That’s it. Other than that, I’m like, I am walking away. Oh, my God, completely blown away by this.

Zack Naylor 26:58
So craziness, do I need to take a step back here and just kind of say, So not only did it dramatically reduce the amount of time, so from basically, nothing to prototype, but it also increased the efficiency of the team, because they were then doing this? Also, remotely, you said it happened during this pandemic. So not only did it reduce the amount of time it took to go from, you know, concept to working product, prototype, but it also increased the efficiency by which all these teams could work together.

Erica Rider 27:28
Oh, it was even more than that. Okay, because at that point, we had some basic stuff for this console platform. Mm hmm. But we didn’t have anything really that was built yet. We didn’t have a UI for this console platform, it looked 100% exactly like what the console would eventually look like, before we built it. The extension they were building for the console. We hadn’t built the UI framework yet for the console for them to plug into. So they were doing a standalone, they’re using a plug in the look and feel of their product they were building in beta looked 100%, like the console platform would eventually look. So sure we’d one for one, one for one. Awesome. I was like I said I was completely blown away. And so they were working with not really they didn’t have any of our full set yet. So we got a developer who then built in all of this, all the stack components that we use for layout, hmm. They built in, we have dialogues that pop up, they can populate, we can have cards that you can nest other stuff in. So we have components that you can nest stuff in, we do 100%, the same layout, and we delivered it. We released it in June, I’ve worked with some product teams, I would have like a half hour meeting with a product manager and kind of show them how to do this stuff and say, here’s the training videos, and then they would come back a week later. And they would show me this fully fleshed out prototype. Not just like, here’s some screens, you click through, but there was interactivity in the page. Mm hm. interactivity. And like we had to do that. They would have tabs that icons and the tabs. I’m like, wait a minute, I’ve been asking for that. That’s been on my feature request for like four months. I didn’t know how did you do that? He’s like, Oh, we just did it like this. And it’s not documented anywhere. Oh, I didn’t know it did that. product managers who were doing stuff with a toolkit that I didn’t know it did. Nice.

Zack Naylor 29:13
All right. That’s awesome. And there’s also challenges there too, right?

Erica Rider 29:17
There isn’t there isn’t? Because my focus is on teaching them. If you teach somebody to fish, Mm hmm. kind of model. So we kind of change things around. We used to have office hours that were once a week. And we set up a system where you can go to our office hours page on the internet, you can book office hours for anybody, not just an hour week. It’s basically we have office hours that are available. And it works with our calendar. It’s kind of like what you use with calendly. Sure, it’s similar to that internal and we have different services. So we could say do you need to do a UI review? Do you want to book my office, my personal office hours, and anybody can book if it’s there, they can book it. We tell teams that we expect them If they’re working in this model with us, we expect them to actually book regular office hours. And we do regular reviews with them. So in this case here with this with this product manager, they normal review would have been about a week later. And he came a week later with something fully fleshed out. But it’s so quickly to iterate through stuff. And the collaboration is so high in it that when we went through a review, we both were on the same prototype, and I was just kind of modifying and talking to him about stuff and saying, Okay, well, this is why I do that. And you understand, Okay, so here’s an order of how this information architecture works. So where you place things on the page has a lot of impact in the way that the user is going to expect this to impact other things on the page. So I start teaching him about that. And I don’t say just move this here, move that there, explain what we’re doing and why we’re doing it. And so as they go through that, they start to learn that a lot of what we do is we teach them to make good user experience decisions.

Zack Naylor 30:54
Right? That’s awesome. Yes. So you get to take on more of a consultative type role. As opposed to design execution,

Erica Rider 31:01
I would treat as a teaching role designers on my UX team, we play a role of teachers. So it’s a lot of education. And early on, the CTO says I want to transform this from an engineering lead organization to one that’s more customer focused. And I translate that into being more design focused. And a lot of places, if they would treat that as Oh, that means this UX is at the front. And UX tells everybody what to do. But that’s not the case. For something we really design driven design is everywhere. and product development. It’s not just in the UI design, it has an impact on your API’s. And it has an impact on the way you, you model your data structure. Right? Mm hmm. And so then understanding what design is, and how to think about design and how to think about your impact, and how that cascades out and everything else. And that all that stuff is related to the user experience, user experience is not UI design. It’s the user experience experience they have when they’re using the product, and it’s everything, right. And it’s been a transformation of actually teaching an organization to make that shift, and not think about like, how do I build this, but how do I build this right for the user, it’s been a lot of that. And so we teach that and we treat everybody as kind of a junior UX person. And I’m at a point now where I have quite a few developers where I trust them. I trust them enough to go into a meeting without me and speak on my behalf. Because I know that they understand where I’m coming from, and what the fundamentals are, what we’re doing and why we’re doing it. And they can speak to what is right, and what’s going to follow those fundamentals. I strive for not just here. But in the past, I’ve always strived for developers that I could have that relationship with because if they understand that, it’s not tossing stuff over the fence, it’s it’s really everybody is on the same page. And they should be able to come back to me with things that will improve the design. And the design, like I said, is from the bottom to the top. That’s not just a not just icing on the cake. I like to say cat is a biscuit and call it a cupcake.

Zack Naylor 33:01
That’s a pretty good quote. That that’s a pretty widely applicable. Listen, a question that pops up into my head, as you’re talking about this is, with all this excellent education and tooling and processes you put in place. Where does UX and design and development truly begin? In this case?

Erica Rider 33:22
It’s really blurry, honestly. Mm hmm. It’s really blurry. As a UX. If you’re asking about where does the process begin and end? Or where does the role in a UX designer begin? and end? Those are two different questions.

Zack Naylor 33:36
Sure. I guess I’d be curious to hear both,

Erica Rider 33:39
you know, the philosophy or the methodology of three in a box? Hmm. So you know, traditionally, you’d have a designer and a product manager and an engineering person was three in a box. Mm hmm. So the model that we scale with is we have a product team. And they might have two in a box, which is an engineering lead and a product manager. It’s a UX designer and a shipping container. Okay. Right. So we’re in the big box. But we’re not in the individual box with them all the time. But we’re kind of keeping the box safe. Okay, that makes sense. Sure. Box, around the box. Sure. And so we have to scale around, we have to keep all the boxes safe, not just the one. At the same time, we have to kind of look at how all the boxes stacked together. It never ends, where they’re from end to end, kind of what we’re working on right now. So the process of UX never ends is end to end. A little bit about, like, I can send you this if you want to post this somewhere. Our diagram for what design ops to is, is it’s basically taking the DevOps infinity symbol, and we add in discovery, and we add in design and evaluation evaluation, I think was there before but evaluation is different. It’s expanded here. I’ll go a little bit into that. But you need to be constantly kind of reviewing what the user experiences is like what’s the impact on the user experience and When you get to development, that is where you get a little bit more into, like, what is your API response time? Right? What’s your availability like? And those are user experience issues. And you’d have to treat them as a user experience issue, the whole delivery mechanism of this product to a user to consume it is the user experience. Right? So it never ends, ever. Yeah. So we have this, like I said, we have this process where we say there is this discovery phase. And then there is the Define stage, and then design and then evaluate and deliver and monitor. And so the loop, we worked through the design part first, we wanted to enable teams to be able to do the design, because we just can’t scale unless we do that. And we have done some stuff where we work with discovery with them. But and that was going to be our focus right now as soon as we kind of shift the design part. But I kind of looked at the overall model here. And I realized, well, actually, where we need to focus now is on the evaluation phase. Right? We give them a chance to do design, now we have to evaluate the effectiveness of the design. If we can’t evaluate the how effective their UX was, then how do you know what to do next? Right. The other main thing was accountability. Right? You said you’re responsible for you x. But saying you’re responsible for UX, not having a way of measuring UX, the impact of the user experience, not having a way of measuring that and not having a way of holding them accountable for it. It doesn’t matter if they’re responsible, they have no incentive to actually improve it. So that’s kind of where we’re focusing on right now. And my a lot of my focus personally now is on how do we do this evaluation phase? What does it mean? How do we put in gates, I’ve worked a lot of places where they want us to be a gate to shipping, I’ve never really been at a place where it has been a gate, if it gets anything, it’s more of like a paper streamer. Okay.

You know, there’s nothing stopping, and you just walk right through the paper streamer breaks, because they’re not held accountable. But at the same time, with developers in engineering, there’s always this, there’s this notion that UX is really touchy feely, right? And it’s really arbitrary. It’s not, it doesn’t have to be there. It’s like development, right? development is somewhat arbitrary, you have a problem, you want to solve it. And there’s many different ways to solve it. And it’s effective or it’s not effective. And so we’ve been working on ways of how do we actually measure the effectiveness of this? And what does it mean? And how do we standardize this and quantify it, because to get development teams or product teams to take this serious and not as a touchy feely thing, we have to quantify it, and then we roll that up, we’re rolling that up into a dashboard, dashboard, if if you don’t meet the requirements, and you will know, at the beginning of your production, what you’re expected to meet, they’ll be flagged as red. And that’d be a report that goes out to everybody in the organization says, Hey, this product is red. If they didn’t work with us, and they’re red, the red will help you get back to green, right, we’ll help you get to a well not back to we’ll help you get to green, and we’ll help you stay there. But you have to want to do that. If teams don’t believe in the value of UX, I don’t want to deal with them. I don’t have time. So working through that, once we kind of get that then we can come back and say okay, now, you understand why we gave you the tools to do something, we gave you the tools to understand how effective it was. Now, we have the tools for teams that want to do it. But we’re going to kind of start enforcing and operationalizing the discovery and research part of that. A lot of us how do you operationalize this, if we can’t scale designers, how do you enable product teams to be able to do this on their own? And so that’s kind of we go through each phase of this and try and figure out how do we do that? Yeah, so the discovery phase, we’re doing some of that, but really, right now, we’re in this evaluation phase and getting that nailed down for the rest of the year and doing supporting teams for doing the discovery part up front. I don’t remember what the question was.

Zack Naylor 39:03
Well, we covered a lot of ground. But it’s funny, because one of the things I was going to ask you is, what part does research plan is right? Because we’re talking a lot about design execution, which is I think it makes sense to that’s where you started, you started to touch on then valuation phase and then also, you know, research and as it’s as it’s applied to this process,

Erica Rider 39:21
right. So there’s a new thing. We’re now kind of implementing, we call it our users Bill of Rights. putting this in so anytime a user is giving feedback, we will present the user Bill of Rights. The first thing in the user Bill of Rights is I have the right to internal software that’s built with my best interest in mind. Yeah, that thing right there leads straight to the research for any product team. To do that. They have to know what it means to build software in the user’s best interest. We haven’t operationalize the research part of that. But our number one, number one bill of rights is software built with the user’s best interest in mind. Totally as our first responsibility for the product teams, it’s them understanding their users, and doing research with us, as a UX team working with them to teach them. But like the design stuff, we can’t do every design, we have to have a way where we can enable them to do it on their own. Mm hmm. Also understanding like kind of what it research they want to do, and not just kind of go out and start asking random questions. Don’t waste anyone’s time, get to what you want. Yeah, that’s where we’re implementing a release. And we have some teams that are using it. And the big thing with that is like, if you’re going to go out and do research, you need to be able to go, you need a place where you can go, and you can look across and see what’s already been done, and create some kind of hypothesis that you want to validate. Is there a hypothesis for you to validate?