The Design Process: Golden Path to WOW

Muriel Naim at UXDX EMEA. Video: https://youtu.be/qQAvrPYmQsM

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.

Introduction and agenda

[00:00:00] Hello everyone, my name is Muriel. I'm going to talk about design process, or how I call it, the golden path to ways of working. I'm going to start with a lot of intros. I'm not going to talk about myself too much; I'm just going to say that I am the head of UX research and design at Fabric, previously Disney, Walmart, Google and a bunch of other places where I led and scaled up design and UX teams, as well as research with the research teams.

[00:00:25] A little bit of the agenda here, which we'll cover. The framework: I'm going to start from the end. It's really about design ways of working, and how to make sure systems are in place to unlock creativity. I'm a big, crazy creative person; I like coming up with original ideas myself. I actually found out that the more process and clarity there is, the more ability it gives you to be original and creative. So I want to make sure this thing works for anyone, which is how I'm going to start: step by step.

[00:00:56] Next we're going to move into the what, or, as I wrote, a free sample. We've got a bonus saying how I did it, how I failed, and then made things better, failed, made things better, until they worked and became well-oiled machines. And then how to get there, and then the didn't agree [?]: do-it-yourself ROIs, and how to prove the KPIs of that, which is pretty hard, but you can do this through Jira. So this is really what we'll cover. And I'm going to start right away, because you want to get some info here.

Step one: treat the process as a research task

[00:01:28] I split it into about four or five steps. The biggest recommendation I have really is in step number one of the whole approach: treat this process as a research task. What I mean by that is, treat it as much as you would treat some kind of thing in which you're not sure what you're going to get. You have some guiding principles, but you also just listen and absorb. It doesn't matter if you just joined the team as a head, as a process person, as a designer even, to influence things, or you inherited the team, or you're starting a new team, or you've been around for a while and something doesn't work. Treat what you have in front of you as the stepping stone, and absorb.

[00:02:11] I put these glasses here, but really it's ears, eyes and pencils, to make sure you get a fit into the current organization. There's no one fit for all; we all know that. The first step is probably the most crucial, in my opinion, to understand what you need to make it work. Again, every organization is different. Make sure you take notes. I'm going to explain a bit of what I did to treat it as the UX research portion, but just take it in.

Step two: plan it out

[00:02:40] Next step is to plan it out. If you've got a framework: I got lucky. I did ways of working in a bunch of different very large companies, so when I went to a small company I had some type of framework that I could start from. This is your table, if it's your process, if it's your step-by-step, whatever that is that you already did. Take it as the starting point. If you don't have one, guess what, there are five million resources online. Just look into how others do that. Not everything is the same, obviously, but look at what feels right to you. I believe a lot in the subconscious gut of a head of design, or of a manager, or of a designer. Our subconscious brains work really well. Read through, look around and see what feels right, and take the one that felt right as a starting point.

Step three: the sell-out

[00:03:26] The next step is the sell-out. Step number two is really putting it together: distilling information from this research portion and making it go into your tailor-made creation, which is this process that you have in mind. This step is as important as the previous one. Why? Because you have to see where your organization is standing. Where are they at? You need to meet them where they're at. What I mean by that, for the most part, is: what is the level of maturity you have in the organization towards understanding design as a whole, understanding the UX process and product design as a whole, incorporating yourself or your team, or your upcoming team if you're alone, which happens a lot in startups. There is going to be a bit of a gap between where they are and where you want to go.

[00:04:15] You came up with your amazing plan in the previous step. It's like a spark in your brain: "Oh my god, I've got it together, I'm going to make it happen." Guess what, you have to sell it. Again, the key for this is the same research approach that I talked about in step number one. If you know where they're standing, and you get a sense of the company, how they function, how people talk and speak, how they react to each other, get checks and balances of that stuff and insert it into your plan of selling it. Again, it can be as a head, as a manager, whatever that is, as an operations manager. But you have to understand where they're at. As we all know as UX people, the why is how to know how to sell the what to them.

[00:04:56] So the sell-out is really a meticulous plan, and I highly recommend doing it as a storytelling thing. Stories are great. They involve emotion, they also involve metrics, and you can do a lot with that. But again, every organization is different; they will need a different sell-out. So this is as important a step as the previous one, I would argue.

Step four: run it and measure outputs

[00:05:15] Moving on: of course you were able to sell your process, this crazy thing you came up with after research, after framework, and now you have to make it work. So you have to run. This is the most iterative step of all. You really have to measure outputs, you have to collect your metrics, you need to start telling your story. You have to think about the end. The end is: is it working, is it not working, can I change it, why do I need to change, how do I prove my ROIs, my KPIs, and all these things you have to do. Which is gibberish many times to any of you that started as a designer. We all don't like these technical things. We want to create art, we want to create super solid mood boards. We don't want to deal with ticketing and pointing and code-related applications.

[00:06:02] So we want to measure the outputs the way most companies treat it, which is agile. I highly recommend taking a framework that's built as similar as you possibly can to the engineering metrics. The reason I'm saying that is because it's very, very hard, as we know, to quantify good design. But there is a way to quantify the amount of good design, and to put a lot of caveats in as an inspiring factor, which I think is the lead. I'm not going to say the boss or the manager, but really the inspiring factor of making the best quality it can be. To unlock the ability to do best quality, which is very hard to measure, you can use the metrics from the quantitative side of things to measure outputs.

[00:06:54] This portion again is just the nitty-gritty of how to make it happen. Start it. Don't be afraid to fall and fail and change things, and then readjust, rerun, rerun, until you get to a good place. It's really the testing period of that.

Step five: show it

[00:07:05] And don't forget this last step, because it's important: something worked, show it. This is a step that I forget sometimes to do, and I think it's super crucial. It will unlock your ability to do more things with whatever organization you're at. If something didn't work, don't go here. Go back, rerun, adjust, rerun, do more interviews, do more measurements, quantifying in different ways. Speak to your crew, do a lot of retros, understand what doesn't work for them, adjust, rerun. When it works, showcase that, and that's where you go back to the second step of the process and adjust a lot of things there to become your golden path. Pretty straightforward.

[00:07:50] A lot can go wrong, but there are a lot of steps to make sure you make it right. This framework should really work in any organization, because I think the how is as important sometimes as the what, and it's important to know where you're standing. This matters less, necessarily, for design studios, or visual studios, if it's print design, in which we're working in a known pool, a very knowledgeable pool of folks. But even there you have a certain process, and some processes work better than others. The only way to make it happen is to start quantifying, qualifying and then readjusting all the time. So that's regarding the process, the how.

Interviews and the pre-plan at Fabric

[00:08:37] Starting from the end, now I'm going to go back and click down into something I did. Again, I was the head of UX architecture for Disney ABC, I was the head of UX for Walmart Labs at some point, and then I moved to Fabric, which is the headless e-commerce platform, and a really scrappy startup. As you can imagine, those companies are very different. I'm going to show the distilled version of what I do right now, what I recently changed and did at Fabric, and how we scaled up from a team of one to a team of seven that is working at a very, very high velocity. I'm going to talk about my shift from what I knew before, my latest one, which was Disney, and then what the sell-out process and story was that I did at Fabric, which is a very different story, because the company was in a very different place of understanding the importance, the how-tos and the nitty-gritty of design and UX processes.

[00:09:36] So we're going to start with this free sample for you. Step one: in this specific company there were a lot of cooks. So I said, all right, sounds good, let's bring them into the room and hold all the interviews. Obviously I came up with a script; as researchers we should have some kind of starting point. What I like to do a lot, and I did adjust a little bit for this company, but I typically run it anywhere, is getting very different types of people, not just types of roles, that have an attachment of sorts to the design process.

[00:10:09] I love to start with just saying, "Hey, no judgment, no yes or no, just tell me: today, how do you work with the design, UX or research teams? Break down your process to me, step by step." I love doing journey maps to understand exactly what they're doing from the beginning, even before they think they work with design, where there is maybe an attachment, all the way to the end, to completion and delivery. So I do a breakdown; it's really robust. Of course I want to look into inputs and outputs; that's the last step. But then I'm asking very directly: what works and what doesn't work for you today?

[00:10:39] It's really open; it's an open conversation. It can be anything from metrics, since some people are very analytical and technical, while some people are very emotional, and their soft skills are what's important to them. So I just document that. I'm trying to keep as similar a format as I can across all the interviewees, just to measure more correctly, as we do. But that was pretty much it. The interview step was big. I was able to unlock a lot there and understand a lot about the organization, but I was still new.

[00:11:10] Then I dived into the next step, the pre-plan. I took what I knew before, which was very big companies. By the way, I am coming from a startup background, so it's not like I just started in corporations. Corporations were a big stepping stone. I still love startups, but I was able to look into really large teams there and adjust some really intense initiatives. So that was my background, that was my pre-plan. I had a bunch of things there. I distilled it a little bit, took things from different places. There's some Walmart here, these are processes; you see some process that I came up with earlier at Disney, and how I adjusted it. I was like, okay, I have a starting point, let's see how far it is from what I had in mind.

[00:11:51] I put some things together about what things I can pull from. You see the front here of Walmart Tech; it used to be Walmart Labs. And some of the method that I came up with, again with a very similar process, but adjusting a lot from the previous, even larger Disney team that I had, which was cross-functional. I took a lot of things in, and I came up with a framework that matched. Again, this is not doing anything yet, just looking into the research, the first step, putting together a chart of ways of working for my team based on my previous knowledge. I was a bit privileged in that I'd already done that. But I had a starting point, and this is not a bad one. You see a very robust process.

Peer reviews as glue

[00:12:30] We're not going to get too much into the process itself. I'm just going to note one thing about it that is pretty cool, like a quick bonus: glue. How do you provide glue to your team, and how do they glue together and gel? And how is the, I'm going to say a word that's very Gen Z, vibe kept very kind and caring and pushing each other? This is really done, surprisingly, through reviews, and I'm not in these sessions. They're having peer-to-peer reviews, and I enforce the step of peer reviews for every single item. People start getting feedback, and they also need to give feedback.

[00:13:12] Say you have some kind of rock star in your team, which is never recommended, but someone very talented. If he or she or they are giving problematic critique, so personal, non-professional, or not building up, not challenging the other member, and also not speaking a lot is not great, since we want them to be really involved in someone else's project, they will not get this feedback. And they'll see others that give good feedback and constructive criticism make their work better, their peers' work better, and eventually hopefully some people become friends. That creates this camaraderie of, "Oh, I'm going to push you, you're going to be better." My projects became our projects, but very organically. So that was pretty cool.

[00:13:55] One of the things that I like the most to do is a lot of internal reviews. It just provides people with a challenge constantly, for each other, and that's pretty cool. I just want to highlight that; there's a lot more to highlight there. But again, this is something that I came up with. You can have your own version of it, you can start from somewhere, you can even start from that.

Selling it: what design means and what isn't working

[00:14:12] Then I was like, all right, I had a plan. I did the research, I adjusted my chart, my process. Now how about the org? I got a sense of this org from a bunch of folks in the beginning, in the interviews, but the more time passed, like the few days that I was really adjusting this, I realized a lot of things about this company, and I had to go really back. The sell-out for this specific company was: well, they had some good designs out there in the wild, and while a lot of them think they really appreciate and love design, I basically realized that to them, design literally equals that, whether it's for marketing, for sales, or UX. That's what design means to them.

[00:15:00] I would actually argue that a lot of companies have the same perception of what design means: the aesthetics, or the high-fidelity layer, the UI. But as we all know, hopefully, good design really means that the high-fidelity wireframes at the end are the tip of the iceberg, really based on all of those steps, in very different shapes and forms. Not everything is always possible in scrum and in agile, but you can do a lot.

[00:15:32] I went back to this. This is the slide that I presented as the sell-out, to say: please let me run my own scrum team with my design team, and adjust the columns and adjust the processes to fit what I think will fit this team. You won't just get it free. Maybe you will; awesome if you do. If you don't, you have to really look at how you're going to sell it. For this company, I realized that there was a bit of a misleading understanding of what design really means, and it was truly a little shallow, in the way that they only see visuals. Really good design means all of this, to me and to many others. So I had to do some teaching, some education, some evangelizing for this thing.

[00:16:14] The second thing I had to do was basically tell them, "Hey guys, some things are actually not working." This just came from the interviews, so this is actually qualitative: here's the data of what works and what doesn't work. There's a lot that doesn't work. By the way, this is not unique to this company I worked at; it happens in a lot of places. A lack of process, and a lack of ability to give the time and effort level for design, UX and research teams, is a known pain all over the place. In all of the, I don't know, eight, nine companies I've eventually worked in, probably more, as a contractor, as a freelancer, there's always some type of lack of understanding or appreciation towards design, UX or research processes. The question is always what level they are at. Meet them where they're at, and make sure that you're reflecting what's happening and also where to go.

[00:17:04] So again, I said: "You guys, this is not what this means, and also we have some problems." A big one, something that is really important for me, and the reason I like a rigid process, is that it actually allows me to see what's going on, so I can make sure work-life balance is kept. One of the hardest things in this current company, and a lot of startups, especially in the first few years of building, is that you see people running around on a wheel like hamsters, without the ability to breathe, and things are actually not moving faster. They're running their fuel on not necessarily the right things, and you see people doing weekends and nights, and this just makes me hurt, because I don't think that's the way to go.

[00:17:45] Can you sometimes do a weekend? Sure, go ahead, enjoy. But if a designer of mine is doing a weekend, something went wrong in the planning. Let's look back into that and see how it doesn't happen ever again, because guess what, we all need to have work-life balance, and mental health is super important, truly. So get a process into place so that you can actually measure and help your teammates to grow. That's another thing I had to present a little bit.

Agile for design teams

[00:18:12] This is going to the crux of this presentation, in one slide: why do we need to work differently in agile as designers? It's because we work differently, period. Unless, that is, we have to really use whatever software you have and whatever process there is in place for engineering, and say, "Hey guys, just a little bit of a white flag: we're different. We don't write code." Instead of a single solution, there are multiple iterations. Instead of one-directional step by step, the review process is back and forth, and again, iterations.

[00:18:49] To work in a real agile fashion, and truly to run fast, we really need to implement a creative system within the larger technical one, and I coin it as agile for design teams. I'm sure there are five million other names for this, but again, this is what I found to be useful. This explanation, this slide, I have to say, was carried with me in my back pocket in all the companies I just mentioned that I utilized this system in. There's a lack of understanding many times. You have to take a little step back and be like, "Ah, do they even know how different we are?" The answer is, many times, they do not. And people will not necessarily tell you, "I don't know how design works, or what's your process." They're like, "Oh, do this thing," and then they show it, I don't know. Make sure you are caring, and sometimes just show what we do. That's important, I think, for any company, any process.

Running a design-only board in Jira

[00:19:40] Okay, step number four: you have to just go. Thank you to my cross-functional designers here; I took a screenshot to say hi, with the meditation on Mondays. Again, that's what I found to work for my team. But to just run: on the right you see a pretty boring screen called Jira, scrum, agile or whatever. That's just the tool. If you actually look inside, you see a lot of different columns there that are quite different from other teams' columns. The biggest thing you'll notice is that all of those tickets are either UX, which we call low-fidelity prototypes; UI, which is the high-fidelity prototype, so design-system-related items; and UXR, which is the research portion, which I'm trying to introduce into every single ticket. I'll talk about it at a different time.

[00:20:21] You see that we actually only have those tickets. We don't have engineering. This is not a sprint with engineers and product leads. Now I just put an X factor into this room. Some will be like, "Oh my God, how can you even do that? That's horrible, we can't move fast." Actually, it moves faster, because our process is a little different, and syncing it with tech and engineering is a little tricky. I'm not going to talk too much about story writing. I do think you need to hone in on it as well. I do think designers, and design producers, and UX writers [?], and researchers, and product designers should be able to write their own stories. The reason I think that should be the case is that then you get the why. You can ask the hardest questions.

[00:21:06] Again, a lot to unfold in here, but you just have to let it run and see what happens. Then we have to pause if something is weird, and there's a lot of weird stuff, and just measure and adjust. Okay, so we had this peer [?] process; it works okay, but do we need more? We do. Why? Do we need to do some kind of mixed ticket? We should. The research separated from design has been taking extra time; we have to consolidate it. How do we do so? Just start looking into what you can do, how you can utilize the system to make it work for you and your needs, the velocity that's required, the motion of the company, and what you want to include as a head, your objective. You may be a very data-driven design head, you may be a very visually driven design head and you want to go wild and then test and then try. I'm not going to tell you what to do, but look into your own process and be diligent, be critical.

[00:21:56] Some things failed in this process that I did. With some clients, some things were released and they didn't have an upper eye, or rather a lead review, which came from a manager. I had two periods that were brilliant, but not the most solid in low fidelity and prototyping, and there was something that was released that was not working very well. It was gorgeous, it was pretty smart, but the motion of the journey was a bit cluttered. So I was like, all right, maybe we need to add a bit of a lead review; let's see how it works. I thought my team was going to hate me. They did not. They were actually excited to get some extra eyes on things sometimes, and then they became seven times better than what I could do. So again, it depends on the process, but make sure you're being really diligent, self-critical, wide-eyed, but also very tough on the process. That's where it's really important. It's not enough to just put it in place; you have to make sure it's working.

Adding stakeholder reviews and measuring the work

[00:22:53] I highly recommend, in the first trimester, either doing it yourself, scrappy, which takes a lot of time, or getting someone who understands a bit of the design process to do it with you, and start going through the motions. So I'll be like, okay, we moved into implementation without an external stakeholder review; we need to do an external stakeholder review. Then we realized we needed to do an additional external stakeholder review. It's not enough to have one; we need to do one after low fidelity, and then one after high fidelity, to ensure everyone got what they needed to get. Then we realized we were actually missing another stakeholder review, because again, we have some cooks in the kitchen, some smart people that want to weigh in. All right, we need to do an internal product-led stakeholder review and a customer stakeholder review in the same process, without releasing it, because the money we'd be wasting on engineering it is too much.

[00:23:40] So we needed to include a bunch of steps. This is the result of a lot of work that you see here, this colorful thing; while I was speaking you were probably looking through what that means. That proved to work really, really well for this company, for our motion. Again, this is coming after running it and adjusting it.

[00:23:59] Then here we run, and you start completing a lot of things, and you're like, okay, now I've completed a lot of things. Look at this beautiful graph; we can show how many points we completed. Again, it's a systematic, engineering-led process, which is called Jira, but you can quantify your work. You can quantify design work. Now, the quality portion is up to you. Personally, I involve an enormous amount of best practices, involving Baymard for e-commerce metrics, and Nielsen Norman, all the time. We do audits many times. So I have my own personal system that works really well for me to measure quality, and I'm very hardcore on quality. I think quality is top-notch. However, I also have to show the others, my heads, all the executives, that there is a reason I took this board and made it only for design teams. How do I show it with metrics? That's where I think utilizing this tool can be really useful.

[00:24:51] Then show and tell. Something worked really well; you have to make a case for it. Again, this is the other side of it, the boring side of it, but you have data now. You have it, go ahead and show it. It may not prove the ROI of design, which is always hard to prove, but it will show completion. You can show quality, and what metrics you checked, and include whatever things in the process you want, to make sure you're working well. Another big thing for many people is accessibility. Include it in the process. Make sure you get the right eyes. If you have someone, that's incredible. If not, just go into WCAG 2.0, 3.0, hire a contractor. Make sure you have that as a checks and balances for yourself, for your quality check.

[00:25:30] Again, this changes between teams, but to quantify it and put it in a systematic manner really helps. The more that design and research, this group, is sitting in its own scrum, not together with attitudes [?], the better you can actually measure it. Even if eventually you have enough people, for a 500-person organization let's say, and you actually do have a head on a domain, awesome. Go ahead, let them go, make sure everyone is aware of the process inserted there. But many, many times, design teams are scrappy. In Walmart, a very scrappy team, it was I think a ratio of 1 to 50, designer to engineer, so they had to move between different domains. I couldn't put a head on each domain.

[00:26:13] I had to work in this manner so that I could evaluate. I can give people the same amounts of work, and no one is going crazy on one project while the other person is just chilling. So that's a way for you to do the checks and balances for your team and make sure they're happy with the work. Also, they know the process, so they can't fail too much. And if they're failing, it's with an original idea, which is great, and not failing because they missed a step.

[00:26:37] That's it for today. Again, I highly recommend starting it as a research task. See what you've got, and then start adjusting it. Feel free to steal my framework for the process, but then make it your own. It's only going to be good if it works for you and your team, and it's ever changing. As long as you do it, you should be good to go. That's it, have a nice day.