The Design Process: Golden Path to WOW

Hello everyone my name is Muriel. I'm going to talk about the design process or what I call it kind of the Golden Path to ways of working. And I'm not 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 a bunch of other places where I lead a scaled-up design and UX team as well as research teams. A little bit of the agenda here which we'll cover. So the framework actually starts from the end. So it's really about designing 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. I actually found out that the more process and clarity there gives you the more ability to be original and creative. So I want to make sure this thing works for anyone, which is how I'm going to start this kind of thing. Next, we're going to move into the what or I wrote the free sample. We get a bonus saying how I did it, how I failed, and then you know how to make things better, fail, make things better until they are worked and become well-oiled machines, and then how to get there. And then the nitty gritty you know, do it yourself, our lives and how to prove the KPIs of that which is pretty hard. But you can do this through JIRA. So this is really just kind of like what we'll cover. And I'm going to start right away because you guys want to get some info here. So I can split it into like about four or five steps. And the biggest recommendation I had really is in step number one and the whole approach treats this process as a research task. What I mean by that is treat it as much as you would treat some kind of a 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. So it doesn't matter if you just join the team as a head as a process person or as a designer to influence things or you inherit the team or you start 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 as I put these glasses here but really it's kind of like ears, eyes, and pencils. To make sure you get to fit that into this current organization. There is no one fit. We all know that the first step is probably the most crucial in my opinion. To understand what you need to make it work. So again I've got an admission that is different and makes you take notes. I'm going to explain in a bit what I did to treat it as a UX research portion. But yeah just take it in. The next step started out. So if you get a framework, I got lucky. I had different ways of working and a bunch of different very large companies that I went to a small company had some type of a framework that I could start from. So this is kind of like your table if it's your process if it's a step-by-step whatever that is what's your what you did to get to the starting point. If you don't have money guess what there are 5 million resources online just look into how others do that. Not everything is the same obviously. But look what feels great to you; I believe a lot in the subconscious guts of a head of design or of a manager or of a designer. Our subconscious brains work really well to read through, look around and see what feels right and take the one that's filled right as a starting point. The next step is the sell-out. So you know step number two is really kind of like 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 up. Where are they at? You need to meet them where they're at. And 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 you're coming to me for a long time which happens a lot in start-ups. And there is going to be a bit of a gap between where they are and where you want to go. So you came up with your amazing plan in the previous step which is like sparking your brain. Oh my God, I've got it together I'm going to make it happen to 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 then 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 step and insert it into your plan of selling it out. Again it can be as a head as a manager whatever that is as an operation manager. But you have to understand where they're at as we all know UX people write the way to know how to sell the watts to them. So the sell-out is really a meticulous plan and I will highly recommend doing it as a storytelling thing. The stories are great.
And they involve emotion. They also involve metrics. And you can do a lot with that. But again every organization is different; they're willing to sell out differently. So this is as important a step as the previous one I would argue. Okay moving on of course you are able to sell your process this crazy thing you came up with after researching the framework. And now you kind of have to make it work. So you have to run this is the most iterative step of all. And 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, is it working? Is it not working? Can I change it? What do I need to change? How do I prove my ROI is my KPIs and all these things you have to do which is you know gibberish many times to anyone view that started as a designer we all don't like this technical thing we want to create art we want to create super solid motherboards we don't want to deal with ticketing and pointing and you know cords related applications. So we want to measure the outputs the way most companies treat them which is agile. So I highly recommend taking a framework that gets filled as similar as you possibly can to the engineering metrics. And the reason I'm saying that is because it's very very hard as we know to quantify good design. But there was a way to quantify the amount of good design. And to put a lot of caveats as an inspiring factor right which I think is the lead not going to say the boss or the manager but really the inspiring factor or make think best qualities can be right. So to unlock the ability to do the best quality which is very hard to measure you can use the metrics from the quantitative side of things to measure outputs. So this person again is just like the nitty-gritty of how to make it happen. To start it, don't be afraid to fall and fail and change things and then readjust, rerun or run until they go to a good place. It's really the testing period of that. And don't forget this last step because it's important something worked to show it.
This is a step that I sometimes forget to do. And I think it's super crucial it will unlock your ability to do more things with whatever organization you're at. So if something didn't work don't go here and go back rerun adjust rerun do more interviews do more measurements quantify in different ways speak to your crew do a lot of retros on this demo doesn't work for them adjust rerun when it works showcase that. And that's where you kind of go back to the second step of the process and adjust a lot of things there to become your golden path. Pretty straightforward. A lot can go wrong. But there are a lot of steps to make sure you know you make it right. So 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 kind of measure is less necessarily suitable for studio design studios like people. The main metrics are Visual Studios. It's a print design in which you know we're kind of working in a known pool of very knowledgeable pools of folks. But even there you know you have a certain process and some processes work better than others. The only way to make it happen is to start quantifying and then readjusting all the time. So that's regarding that. The process of how to start from the end now I'm going to go back and click down into something I did. So 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 a headless eCommerce platform and a really scrappy start-up. And 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 dated 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. So like when I talk about my shift from what I knew before which is my latest one which was Disney. And then what is the sell-out process and story that I did at Fabric which is a very different story because the company was in a very different place of understanding the importance of the how-tos and the nitty-gritty of design and UX processes. So we're going to start with this first sample for you. Step one: in this specific company, there were a lot of cooks. So I said Alright sounds good. Let's bring them into the room. Let's hold all the interviews and obviously come up with the script as the researcher should have some kind of a starting point. And what I like to do a lot and I do the justice a little bit for this company but I typically run it out anywhere is getting very different types of people not just types of roles that have an attachment of sorts to the design process. And then I love to start with just saying hey just no judgments no Yes or No just tell me today how you work with a design UX or research team to break down the raw process to mean 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 but there is maybe an attachment all the way to the end of the completion and delivery. So I do a breakdown. It's really robust. Of course, I want to look into inputs and outputs is kind of the last step.
But then I'm asking very directly what works and what doesn't work through today. And it's really open, right? It's an open conversation. It can be anything from metrics, some people are very analytical and technical and some people are very emotional. And their soft skills are very important for them. So I'm just, you know, a document that I'm trying to keep as similar of a format to all the interviewees that I can just imagine more correctly as we do. But that was pretty much it, the interview stuff was big and I was able to unlock a lot there and understand a lot about the organization. But that was still new. And then I dived into kind of the next step of the pipeline. So I took what I knew before which was very big companies. And by the way, I am coming from a start-up background. So it's not like I just started in corporations as a big stepping stone. I still love start-ups. But I was able to look into really large teams there. And then just some really intense initiatives. So that was my background, right? That was my pre-plan and a bunch of things there. I distilled it a little bit and took things from different things. It's a Walmart here. You know this is processed. You see some process that I came up with earlier at Disney and how I just didn't know that. Okay, I have a starting point. Let's see how far it is from what I had in mind. So I put some things together like Okay what things can I pull from you see the frontier of Walmart tech I used to be Walmart Labs. And some of the methods that I came up with again were a very similar process but ingesting a lot from the previous even larger Disney theme that I had which was cross-functional. So I took a lot of things in and I kind of came up with a framework that matched again. This is like not doing anything yet just looking at the research as the first step and putting together a chart of ways of working for my team. Based on my previous knowledge I was a bit privileged in that I already did that. But I had a starting point. And this is not a bad one; you see a very robust process. I will not 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 the glue to your team? And how did they glue together the gel and then how am I going to say a word that's very Jimsy?
The vibe is kept very kind and caring and pushing each other. This is really done through surprising reviews. And I'm not in these sessions. They're kind of happening peer to peer but to enforce the step of peer reviews for every single item. And people start getting feedback. They also need to get feedback to kind of save and have some kind of a rockstar in our team which is never recommended. But someone is very talented if he or she or they are giving problematic critiques right like so personal, non-professional or not building up right now challenging the other member. Also not speaking a lot is also not great right? We want someone that will be really involved in someone else's project and they will not get this feedback. And they'll see others that give good feedback. And you know constructive criticism makes their work better, their peers work better and eventually hopefully some people become friends. So that kind of creates this like camaraderie of like Oh I'm going to push you you're going to be better this is going to be a project is going to be a by-product and things became our projects but the very organically. So that was pretty cool. One of the things that I liked the most to do is a lot of internal reviews. Just provide Skipper with a challenge constantly for each other. And that's pretty cool. Just want to highlight 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 and you can start from somewhere you can even start from that. And then I was like Alright I had a plan right? I did the research. I just did my chart or my process. Now how about the org. And I kind of get a sense of this org from a bunch of folks at the beginning and the interviews. But the more time passes, like the few days that I was really adjusting to this, I realized a lot of things about this company. And I had to really go back. So the setup 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 designs and basically realize that to them. The design literally equals that. If it's for marketing, if it's for sales, if it's your ex, that's what design means to them. I would actually argue that a lot of companies have the same perception of what design means the aesthetics or you know the high fidelity layer of the UI. But as we all know hopefully good design really means that and the high fidelity wireframes are the end right? The tip of the iceberg is really based on all of those steps in very different shapes and forms, right? Not everything is always possible in Scrum and you know in Agile but you can do a lot. And I went back to this slide inside.
I presented it as a sell-out to the state. 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. Also if you do if you don't 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 kind of, you know, truly a little shallow in the way they only see visuals. And you know really good design means all of this to me and to many others. So I had to do some teaching at this some education some of you know evangelizing for this thing. And then the second thing I had to do is basically tell them Hey guys some things are actually not working. And this just came from the interviews. So this is actually qualitative. Here is the data on what works and what doesn't work. There's a lot that doesn't work. And by the way, this is not unique to this company I work for and it happens in a lot of places. A lack of process and a lack of ability to give the time and effort level for the design UX and research team is a known pain all over the place. In all of them I don't know if eight, ten or nine companies I eventually worked in, probably more the contractor as a freelancer there's always some type of a lack of understanding or appreciation towards design UX or research processes. Always, the question is at what level are they at meeting them where they're at and make sure that you're reflecting on what's happening and also where to go. So again I do some of you guys this is not what this means. And also we have some problems. A big one that was a big thing for me that is really important. 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 their work-life balance is kept. So one of the hardest things in this current company and a lot of start-ups, especially in building steps you know the first few years, is that see people running around on a wheel like hamsters without the inability to breathe and things are actually not moving faster. So 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. Can you sometimes do a weekend show go ahead you know enjoy. But if it's a designer of mine 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 too early. So get across this 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. And this is kind of going to the crux of this presentation in one slide. Why do we need to work differently for agile as designers? It's because we work differently, right? And that's we have to kind of 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 flag white flag we're different. We don't write code. So instead of a single solution, there are multiple iterations instead of one-directional step by step the review processes back and forth and again setting iterations. So to work in a real agile fashion but to truly run fast we really need to implement the creative system within the larger technical one. And I coined it as agile for design teams. I'm sure there are 5 million other names for this. But again this is what I found to be useful. And this explanation, this slide as I say, was carried with me in my back pocket. In all the companies that just mentioned that I utilize this system, there's a lack of understanding many times if I take a little step back and be like Do they even know how different we are? The answer is many times they typically do not necessarily tell you I don't know how design works. So what's your process? Like oh, you know that this thing and then they show it? I don't make sure you are carrying in something just showing what we do. That's important I think for any company, any process. Okay, step number four. You have to just go thank you to my cross-functional designers here who took a screenshot to say hi we do meditation on Mondays again that's what I found to work for my team. But to just run now on the right to see a pretty boring screen called Jira Scrum agile or whatever.
That's Just a tool. If you actually look inside you see a lot of different columns there that are quite different from other teams' columns. And the biggest thing you'll notice is that all of those tickets are either your weeks which we call our fidelity prototypes video which is the high fidelity prototypes or design system-related items. And you accelerate, which is the research portion that I'm trying to introduce to every single ticket after being provided at a different time. But 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. Somebody be like Oh my God like How can you even do that? That's horrible. We can't move fast. Actually, it moves faster. So again because that process is a little different from tech in the end engineering there is a little tricky. And 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 you know design producers and users 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 why you can ask the hard questions. So again all to unfold in here but you just have to just let it run and see what happens. And then you know we have to pause if something is weird and there's a lot of word stuff and just measure and adjust. Okay so we had this pay process with the works okay but like do we need more we do? Why? That's why we need to do some kind of mixed tickets. We should know the research separated from design has been taking the extra time we have to consolidate it. How do we do so just started looking into what you can do and how you can utilize this system to make it work for you. And your needs your velocity that's required the movement of the company and what you want to include as a head its objective you may be a very data-driven design head you may be a very visual driven design and you want to go kind of wild and then test and then try No but I'm not going to I'm not going to tell you what to do. But look into your own process and be diligent, you know, be critical. Some things failed. And in dispersals that I did. You know at some clients there were some things that were released and they didn't have an upper and upper I or other you know like to lead review which came from a manager.
I had two peers that were brilliant but not the so not the most solid and low fidelity and prototyping. And there was something that was released that was not working very well. It was gorgeous and it was pretty smart. But the motion of the journey was a bit cluttered. So I was like Alright, maybe I need to add a bit of an LED 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 and self-critical. You have a wide eye but also are very tough on the process. And 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. I highly recommend ScrumMaster or do it yourself. Scrappy takes a lot of time but just do it yourself or get someone who understands a bit of the design process to do it with you. And start going through the motions right? So I'd be like Okay we moved into implementation without an external stakeholder review we need to do an external stakeholder review then realize we need to do an additional external stakeholder. So it's not enough to have one we need to do one after low fidelity. And then we need to do one after high fidelity to ensure everyone got what they needed to get then realize we're actually missing another stakeholder review because we have again you have some cooks in the kitchen, some smart people that want to weigh in. All right we need to do an internal product lead stakeholder review and a customer stakeholder review and the same process without releasing it because then no the money we're wasting on engineering is too much. So when to include a bunch of steps? This is a result of a lot of work. But you see this kind of colourful thing here. While I was speaking you probably were looking through what that means. That's proved to work really really well for this company for our motion. Again this is coming after running it and adjusting it. And then Iran and you start completing a lot of things that are like okay now I've completed the little things. Looking at this beautiful graph we can show how many points we completed against a systematic engineering-led process that can scale in JIRA but you can quantify your work you can quantify design work. Now for the quality portion of the thing, this is up to you right? So personally I involve an enormous amount of best practices.
I involve a mark for E-commerce metrics and Rob Lisa Norman all the time. We do audits many times. So it's like my own personal system. For me that works really well to measure quality. And I'm very hard-core on quality. I think the quality is top-notch. However, I have to also show the others in my head all the executors that you know 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. And then show and tell you know if something worked really well you have to make a case for it. Again this is kind of like the other side of it and like 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 a completion you can show quality and what metrics to check. And include everything in the process you want to make sure you're working well. Another big thing for many people is accessibility. Included 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 you know hire a contractor make sure you have that as the checks and balances for yourself for quality check. So again this is changing between teams. But to quantify the political system Matic matter really helps. And the more design research kind of like you know this group that you can make happen is sitting in a scrum not together without it because you can actually measure it better. So even if you eventually have enough people in over 500 people organizations I'd say you actually do have a hat on a domain. Awesome. Go ahead and let them go and make sure everyone is aware of the process inserted there. But if you don't and many times teams are scrappy of design enrolment at the very scuffle team it was I think a ratio of like one to 50 designer to engineer so they had to move between different domains. I couldn't put a hand on the domain. I had to work on this matter so that I can evaluate whether I can give people the same amount of work. And no one is going crazy on one project and 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. And also they know the process but they can fail too much. And if they're failing, get in with an original idea that was great and not fail because they missed a step. So that's it for today. Again I highly recommend starting it as a research desk see what you 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, it's ever-changing. As long as you do it. Should be good to go. That's it. Have a nice day.