 Welcome to our talk. Thank you for joining. We're going to be talking to you today about building an experienced vision and why users will thank you for doing so. So here are the things we're going to cover today. We're going to introduce ourselves. We're going to talk through a few problem statements to consider and see if you relate to any of those as audience listening to us talk today. And then we're going to get into a couple of topics around an experienced vision. So why might you consider building one? What we really mean by experienced vision? And then how might you go about doing that, building one with your team? And then we'll conclude and talk about how understanding and solving real user problems is what it's all about. So let's jump right in. I'll introduce myself first. And I'll hand it off to Dash, who we have here too. So I'm Liz Blanchard. I work for Red Hat. I've been with Red Hat for about, I guess, almost nine years, give or take a few months. And I started working on OpenStack. And then I started working on OpenShift after a few years. Recently, I've taken on a role of an experienced design architect and thinking a lot more about our open hybrid cloud portfolio and how we, as designers, can work more in a proactive design way, a proactive design approach to solving user needs at Red Hat. And so yeah, I'll kick it over to you, Dash, if you want to introduce yourself too. Yeah, thanks, Liz. So Dash Copeland, I'm the other user experience design architect. And I've been at Red Hat for September of six years. So for a good while and worked in a lot of different things as well, mainly in the partner space, working with partners on certification stuff and workflows and so on, both for RHEL and for OpenStack and for OpenShift. So yeah, I'm really passionate about combining open design methods and generative research. And at Red Hat, we get to solve really technical, complex problems. And so it really does take kind of a close working relationship with our engineers and product managers in the field and everything. So Liz and I have been working on the vision for over a year now. Right. Crazy. Yeah, so excited to share what we've learned so far with everyone. Awesome. Thanks, Dash. So yeah, we just wanted to kick off by throwing a couple of potential things you could relate to out there. And so we're wondering if you ever find yourself thinking things like this. Why am I developing the features that I'm working on? Another one is, how does this feature I'm building improve the overall experience for a user? And then the last thing you might be able to relate to, you might think, is where does the feature I'm working on right now fit into the larger product or portfolio? And so what we really want to talk about is how an experience vision can help answer some of these questions for you and make you feel confident you know the answers to these questions. So I'll kick it over to you, Dash, to go through this section here on the why. Why you might consider an experience vision. Yeah, so I think those three scenarios that you just talked about are pretty common, you know. I think the two of us have both worked on a lot of different projects and with a lot of different folks and especially on the more complex things, you know, where it's maybe it's a platform that consists of a bunch of different services. Maybe a developer on one of those, you know, it's fair that they would ask like, not really sure how what I'm doing connects up to the bigger picture. And so the why ultimately for doing an experience vision is to try to provide that big picture vision and enable folks to really understand what they're building. So one of the big reasons to do it is that it enables you to discover the outcomes that your users will value. So, you know, when we think about why people use your product or use any product, really, it's ultimately really about them being able to become something more than they are today. You know, users value outcomes. So the like classic example by Clayton Christensen is like, you know, people don't want a drill. They want a hole in the wall, right? They want an outcome. And so they want things like, you know, being smarter or more capable or more productive, right? They wanna be a rock star. They wanna feel good about themselves. And, you know, those are kind of grand things. But, you know, for any product or service, you know, the reason they're interested in hiring you is, you know, because it gives them an outcome that they really appreciate and value. So the next thing, big reason why you'd wanna consider building an experienced vision is that it helps you anticipate how users want to grow. You know, so we, as designers, of course, do a lot of research. So do product managers. And, you know, I've worked with development teams that talk to customers quite a bit, right? So you have a lot of things that you know about your customers or your users. And you know what they need today. But doing an experienced vision allows you to anticipate where they see themselves tomorrow. You know, tomorrow being the future, right? At some, you know, ideal state, you know, maybe two years away, they see themselves as being, you know, far more capable, far more effective, far more productive than they are today. And that's where your product helps them and the experience vision explains and describes that. So the last thing that it helps with is that it's gonna get your team to align to deliver on those user outcomes. So those things that the user of your product wants finds desirable, the things that they're hiring you, your product or service to do. By having an experienced vision, you discover those things and you build that with your team. So you build the vision in conjunction with a cross-functional team. So, you know, development, design, product management. And by having that vision, you understand the outcomes that your users appreciate and you understand how the things that you do on a day-to-day basis deliver or come together to meet those needs of your user and deliver them the outcomes and the future selves that they envision. So, I guess this is the last thing. The final thing is it really helps you to understand your impact. As I said before, you know, having that vision really enables the individuals on your team to see that big picture and how, you know, on a day-to-day basis, when they make that commit, right? How that contribution maps to some user outcome. So, you know, if you're working in your ID and you make a commit for this microservice, right? It actually delivers or contributes to delivering this outcome that your Rockstar user wants in the future. Okay, so you're probably thinking, you know, so you told me the whys and then tempting, but what exactly do I mean? Or, you know, me and Liz, what do we mean by an experience vision? Sounds cool, but what is it? So, I'll first say that, you know, anyone that's familiar with the design process you've probably seen this double diamond. And it, you know, and we all know that it's actually a loop, right? So you discover, you define, you develop, you deliver, you measure, you know, did what you deliver, was it effective? And then you go back to the beginning, right? That's an input back into discover. So a user experience vision, we consider it proactive design. So it really happens in what's traditionally kind of the research diamond that discover and define. But what you're actually doing is crafting a vision. You're kind of designing a story that captures those outcomes that your users really value. And you are sharing it with them, right? You're telling them that story about where your product or service is headed in the future, and you get their feedback and therefore it aids that problem discovery and definition. You start to hone in on, okay, these are the outcomes that excite our users. So ultimately, what is it? It's a story of your user's future. It imagines your user's life and how it's transformed by your solution. So all this work that you do and deliver to your user allows them to achieve those outcomes that they value and be something more than they are today, tomorrow. And so now I'm just gonna kind of walk you through some of the crucial elements of what that story needs to contain, the key ingredients, let's say. So the story should really focus on the user, right? We're user centered. So you need to be talking about how your product is used by the user. So you talk about your product from the perspective of your users. And so you really need for your team and anyone else that you share your vision with to really care about your users and identify with them. So who are they? What do they care about? What are their worries? What challenges do they face? What are the things that they have to overcome? And how ultimately does your product enable them to be successful and overcome those challenges? The other key piece is the format of your story. So it's a classic narrative arc, a dramatic narrative arc. It should follow that arc. So that just tells how your user faces and overcomes challenges with the help of your product or service. So it's like any most stories in the world that you've ever read, they start with exposition. What's the setting? You have the rising action. So what is happening in your character's life that leads to a climax, right? This ultimate challenge and moment where they really have to rise to the occasion and overcome. And then the resolution, what does their life now look like because they were able to meet that challenge and grow as a result? The other thing that you wanna keep in mind is that your vision, your experience vision story, again, it's just a story, it needs to be set three to five years out. And that's not really, we didn't pick that because of that it's super specific or we have some analytics that tell us that it's the right number of years. Really, it's just far enough in the future that it frees your team to stop thinking so much about limitations, right? When you're talking about six months out, you really do have to get to what is our capacity? What can we build? Well, when you're looking three to five years out, kind of frees you to really focus on your user and what the ideal outcomes would be for them without worrying too much about can we actually deliver this in two sprints, right? It's far enough in the future that it's safe to kind of stretch your legs and use your imagination. And finally, the story, it really needs to be aspirational, right? So it needs to serve as a beacon that inspires your team to collaborate and build that great product, right? Because your vision is far enough out in the future and it's going to contain some, let's say sci-fi, some things that maybe you won't be able to achieve. So I will put one disclaimer on this, you don't want it to be delusional, right? You don't want it to be so fanciful that you get laughed at, right? It needs to be in the realm of possibility, but it needs to represent something that would really challenge your team to really collaborate and work towards every day, right? Something they can look to while they make small decisions when they do their day-to-day jobs to move you incrementally closer and closer to delivering that vision. So I think that was it. And now I think Liz is gonna tell us how we do this, at least at Red Hat. Yeah, yeah. So I'll walk through really the process that Dash and I have gone through with a team that we're a part of that are building our own experience vision at Red Hat. And so I'll share what we've done and in hopes that it's something that you could do yourself, you could bring back to your teams, or you could at least just enjoy hearing what has come of it for us. And so what we have done is we have formed a framework, a process that we call an experience-focused studio. And what we do is we form a cross-functional team and we perform a number of design thinking activities in workshops. We do this over a regular cadence, really ultimately building out this experience vision along the way. And so we'll go through a number of phases in each experience-focused studio that we run and the first phase is really all around gelling as a team, understanding the challenge that we're facing in this studio, the challenge we're designing towards the user that we're supporting, those types of things, just getting to know the space. The second phase we call download, this is where we're really becoming very familiar with the current landscape, if there's a current product that we have in the space or competitor products in that space, just getting to know those two things. The third phase is all around empathizing, so further understanding of our user and especially the problems that they're currently facing. And then from understanding and empathizing the user, we move into more of an imagination phase and we wanna start to brainstorm these ideal user outcomes. What would these ideal solutions be mapped to these problems that we've identified for our users? And finally, the fifth phase is all around storyboarding. How can we assemble a narrative that tells this ideal story in where we wanna be? And ultimately these storyboards, these narratives end up being this experience vision, this North Star that our teams can build towards. If we build this ideal experience, we know because we're validating this along the way, we know that this is what will really serve our user's needs. And so some of the big initial questions when forming one of these experience-focused studio groups is who should be a part of this group and when should I do this? And so we definitely recommend this being at the beginning of the product life cycle. And with respect to who is involved, it should be a good mixture of designers and researchers, developers, product managers, really any key stakeholders that should be a part of some of these early planning and understanding the priorities and the use cases and the requirements discussions should be here. A lot of times it's really helpful to have subject matter experts as well to give their thoughts and their feedback along the way and shine a light on things that they know just living and breathing in these spaces. And so it's a really good idea to have a good mix, a good mix of different people with different perspectives and keep it open to people who want to join. Something we've found is not everyone might be available to join all of the time. And so we've found something that helps us to say, go ahead and delegate somebody in your place. If you can't make it often, who would be a good person to take your spot and to represent that space that you would have represented? So that's worked well for us in the case of people not always being able to attend something, whether it's two and a half days straight or a weekly thing over a course of a couple of months. And so that kind of gets to the cadence, how often should you meet as a group? It's really up to the group to decide that might be dependent on location, schedules. We've mostly been doing what we call lightweight experience focused studios where we've been running one hour weekly sessions with teams. And it seems to work pretty well. So that's something we could recommend that you try if you want to try kicking this off. But we've also seen it done in like, if you can get together and run like a two and a half day event and go through some of these activities together, you can do that as well. And so what I'll do is I'll go through each of the phases and the way we've run these workshops in each of the phases just to give you a glimpse of some of the output that we've captured and some of the activities that we've done to gather that output. And so the first phase is all around gelling as a team, introducing yourself not only to the people in the group, but also to the challenge that you're faced up against. And so I think with respect to activities here, getting to know people, getting to a common understanding of who the people are in the group, that's pretty much your classic icebreaker activity. We've run a number of these types of activities, whether it's a scavenger hunt where you have people who are remote all over the world and you do a quick like find these three items and people come back to their desk. It's always a little bit fun just as an icebreaker activity. This one here, I'm showing a screenshot on the left here of just a very classic, put your name on here, a picture of yourself, your favorite food, tell me something you've learned over the last year, just something to get to know people as humans rather than just as what we work on every single day. And then the next really important thing is to to agree on together, what is this studio challenge that we are facing today? What is the problem space that we want to dig into? What are we talking about? Who's the user that we are talking about and solving a need? And so something that we've found works well is maybe the moderator or the person who's setting up this experience focused studio begins with a proposed studio challenge, one sentence, maybe a two sentence statement, but then we encourage everyone in that studio to come up with their own. If you were to rewrite this, how would you phrase it? What would you say should be the challenge that we really tackle here together? And that invites everyone to participate from the beginning in defining what really are we going to be talking about over the next, however many hours that we're talking together on this topic and working through this together. And then the last big piece of this introduce phase is to lay out any questions or concerns that you all have together. And so this is really important to let everyone air out. I have a concern about this or I have a big open question about that. I wanna make sure we tackle these things. It just invites everyone to capture these things and you can come back and look at this list and say, have we tackle any of these? Are we feeling any better about these along the way? So the second big phase is all around download. And this is becoming very familiar with any current solutions that you have in place already in-house and also what the competitive landscape looks like. And both of these could be vast. There could be a lot on one side or the other really. And this is really all around taking tours and going through screenshotting what's there already, putting those into a canvas and taking notes on them, just discussing what's there already. What does it look like getting familiar with the current stuff that's out there? And this is really helpful because it's giving you a baseline of what's already there so that when you're brainstorming future things, what could be, what might be three to five years out that's really going to change the game here. You'll at least have a good baseline to know that I haven't seen anything like this before. I think this is a really big idea to push on. So again, take screenshots, make notes, capture pros and cons, capture open questions, have a good discussion about this as a group and just get everyone on that same understanding, level playing field of what's out there today. And then the third phase is all around empathizing. And so this is when we really start to dig in to who our user is and more importantly, what the problems are that they are facing right now, today that need to be solved. And so an activity that we have found that works really well for this phase is the speedboat activity. And so you can see in our screenshot, we have Leo, he's trying to get to Monaco, he's wearing his red hat, but he is being held back by a number of anchors here. And so this just gives us a framework to brainstorm, what are all these issues? What are all these problems? What are all these hurdles that Leo has to jump over that's really holding him back in this problem space? And so what we do pretty classically in this type of activity is you have a lot of people adding notes, whether it's on a physical whiteboard with sticky notes or in a tool like Miro here, people can add all these different sticky notes, everything that they can think of. And you can run this as a for 10 minutes on your own brainstorm these things. And you'll see all these sticky notes fly onto the canvas and then take some time to do some affinity grouping, talk through the stickies, let everyone take a few minutes to group like things. People may have repeated the same sticky all over the place. And so make sure you group them, label those groupings and then a really important piece after you make the groupings are to do some like dot voting where maybe everyone in the group gets three or five votes to say, what do you think are the most pressing problems or the biggest bang for the buck problems if we were to solve this, this would be massive. This problem is a big nightmare for Leo. And so drop your votes on each, well, I shouldn't say each one, you can actually wait, you could drop all five of your votes on one of these categories if you wanted to. I think that's an important part here is you can start to see these groupings rise or fall in what the group thinks are the most important things to tackle. But it's actually not enough for just this group to vote on what they think are the biggest problems, right? But instead, this is a really important validation checkpoint in this process. And something that can be very lightweight is to make a list, just a one liner of the problems that you all have identified. Make a very lightweight survey out of that list and send it to users and say, help us rank these from what you think is the biggest problem today in this space to, yeah, if this thing doesn't get fixed it's not a big deal. But also make sure you leave a open space for, what are we missing? What are the other problems that you're facing today? How we could add to our list and how might you rank that in importance, right? So this allows you to not only double check, are we thinking the right way with how we've come to understand the problems or are we missing anything? Do we have the right prioritization? It just gives you that validation built in with your users. So you know you're already set up to say, great, if we solve these problems we are solving real user problems at this point. And so the fourth phase is all around imagining. It's taking those problems that you've identified, you've validated and in order of importance start with the top priority problem, put that over on the left somewhere and understand that problem and then think about, okay, what would an ideal user outcome be? And so I think that she used a really good example, right? You know, I need a hole in this wall here. Like what is, that's my outcome. You know, I need a hole in that wall. And so it's interesting to what you do here is you actually skip the solution piece. You don't necessarily wanna dive into technically, you know, how do we do this, that or the other thing? You just wanna think about, you know, what's an ideal user outcome here that solves the problem? And so what you'll start to see is a flow start to emerge of, you know, things that are connected to each other of what a user does in a natural flow to get to the outcome and to have that ideal experience here. And these user outcomes start to become the basis of what you form to be your experience vision. And so that leads us really into the fifth and final piece of your workshops where you take your user outcomes and you start to string together a narrative to tell a story. You might have five to 10 user outcomes. And I think this is somewhat of a tricky part to say, how are these five to 10 things related? How could we tell a story? There might actually be some secondary characters that you have to talk about in this narrative and in this story to support the pieces connecting and that's okay. You can just highlight, these are the big things and these are more of the supporting characters that help the pieces fit together. But in any case, when you string this narrative together you tell the story and once you have that narrative and that story, you can break down pieces of it and diverge into smaller groups to do some sketching, do some activities like some crazy eights where you just get really creative and there's no bad ideas in crazy eights. You have eight boxes and you go for eight minutes and we have one minute on each box and you just sketch whatever's on your mind, whatever crazy idea comes to mind. You never know what might come out of that and what might follow on in the next box and so something that really helps, I think with the scale of how large you could have these five to 10 user outcomes and maybe you have 12 people in your studio. If you break down into groups of say three, you can tackle four of these outcomes at a time and then you come back together, you converge back together to talk about what are some of the solution ideas that you came up with as a smaller team and you just get that many more ideas flowing and people can give critiques and thoughts on those solutions. They might extend those with more ideas so you can iterate on this storyboard process for a number of our long sessions, however long it makes sense to however many user outcomes you have, if you continue to do this work until you feel like you're in a good spot with a number of really good ideas that you wanna fold into the next round of validation. And so again, yeah, this is a very key point to do that validation, to present any of these narratives with sketches that you have to users and we've actually found, we've heard that showing users sketches is great. It doesn't have to necessarily be something that's very polished or even built to understand is this something that's going to resonate with the user? Is this something that they get excited about, that they feel like, yeah, this is something that would definitely solve my problem. I would love to use something like this. You can see that excitement that comes of just seeing somebody look at a sketched idea and we also find that showing people sketches, I think more invited to comment on them. They know that people didn't put a ton of time. They're not like tearing down somebody's idea so they might actually be more invited to say what might not work well for them or things that they say might need more work or even add on their own ideas. They know it's not fully formed, not fully baked so they're happy to give feedback one way or another. So really at this point, you're trying to figure out what's resonating with these users and what isn't. What's worth spending a lot more time building out, pulling into your ultimate vision and what needs more work. And so really in the end, how it looks like this. So you go through these different phases, validating along the way. Things that are ultimately validated. You might put more effort into having a higher fidelity version of that but ultimately you pull it into that experience vision, that North Star that you're building. Anything that just doesn't resonate with users. It can go back to one of these different phases. If it's something that they say, yeah, not a bad idea, what do you think about X, Y, or Z? And it just needs to go through another round of brainstorming another phase four here. It can come back in and keep tinkering with that idea. But some things just make sense to drop at that time or de-prioritize. It just doesn't make sense to be in that ultimate experience vision. And you almost need to be okay with letting some of the ideas that you thought might resonate go. And they just might not. And that's the point of doing this at this phase of a product lifecycle, right? Is to not waste that time building these things and all of that engineering time to build and test and release these things only to find out that they just didn't resonate. And so I think that that's it for answering the why, the what and the how of building an experience vision. And in conclusion, really this is all around understanding and solving these user problems, right? And allowing you all in your teams as a team to feel like you're being efficient in delivering product experiences that are desired. And so I said, I used the term North Star really that is what an experience vision is. It's to have this thing that everyone is looking at and everyone is working towards and something that you all feel like the piece that you're building contributes to, part of that ultimate experience vision. And so the initial quotes that we had in the beginning, the hope and the intention is that having an experience vision allows for understanding and solving real-world problems. And so therefore it really turns some of these problem statements into more of a, this is a rewarding and efficient product delivery process. And so you will start to feel and hear people saying things like I'm confident now that the feature I'm building for this next release is going to be useful. I know it's been validated already. And so I know why I'm building this. And things like I understand how this thing I'm building is actually solving a real user need. I've heard that the user has this problem and it's already been validated and they have this need. And lastly, I understand how this feature that I'm working on fits into this larger product space. I might not be building at all, but I'm building this piece and here's where it fits in and here's where it sits and contributes to that larger experience. And that's all we have. So thanks everyone for listening and yeah, we look forward to any conversation or questions you all have. All right, that was an amazing talk. Thank you so much, Liz and Dash. If anyone has any questions, feel free to ask them in the Q and A. It doesn't look like any have come in so far. So I had a couple that I wanted to go through. So firstly, I wanted to ask, did you, so have you had any actual examples where you have implemented this method in existing projects? Yeah, yeah, we do. So at Red Hat, one of our key areas of focus right now is building a really solid seamless developer experience especially when it comes to our OpenShift product. And so we've been running a studio all around that developer experience and improving that experience. And so we've done nearly everything in the process that I described in the how section there of really truly understanding who is that user and what are the big problems they're facing today? What are their ideal user outcomes, right? These users really wanna come in and deploy their application. They really want their application running, right? The code that they write, they wanna live and breathe in their IDE and they want that seamless deployment of their code. They've been told, here's how you might have to do it but they wanna be writing code. They wanna be delivering towards that application and making sure that that's a success. And so it's been really, really helpful, I think, for us to think about it this way rather than from what technology is out there and what this new technology could bring almost like flipping that on its side and saying, what does the user want? And therefore, oh, this technology could support that in a really, really cool way. So we definitely have been applying this in some of our product spaces so far. It's been going really well. That is so cool. Have you had any quantifiable, I guess, data regarding the amount of success it's actually brought? Maybe not success is the right word but just like, do you have any data to? I think rather than numbers to report out on, I think something that we have started to hear and see is just this excitement from people around it. And so you can almost hear in people's reactions and in their voice when we present some of these ideas to users, whether they're customers or potential future users even to hear them just like almost have this sense of relief and joy and to say like, wow, yeah, I would love to use this or they seem even more invested too to say, this thing is really nice but what if it could do something else like this or I see you've come up with some of these problems but more than that, here's another problem. They just seem invested in talking about it in this way and users just wanna be heard. They wanna come in and experience something that they feel like this was made for me and I feel that and they talk about these great experiences that feel like they're just meant to be and they're meant to be there and using it and it feels natural and normal and something I think we're learning a lot of especially in our product space in OpenShift at Red Hat in this container native world is there's a lot of leveling up our users need to do and there's a lot of learning. It's a little bit of a scary new world for a lot of people entering this space and so that's something I think we really wanna keep pushing on to is that helping users feel like they belong like they are not out of place even though it's new like how can we help them learn and really make them feel welcome and like they're here for a good reason and we in our product experience can help them along this journey of them leveling up as a developer or as an administrator, whatever their role is. Right, because the products you're designing have the user in mind first and the solution is as you said kind of oriented around the user. Yeah, these are humans coming in and this is their lives like their day to day life at work mostly, right? Yeah, and it's like a crazy concept that the user should be considered. I guess one of the examples to success and I don't know if this method was used in particular but I think we've seen like GCC have a lot of like I don't know if I'd call it backlash but it would cause a lot of problems for people trying to compile code because the output that you get from errors is not very like humanly readable. And now we're seeing the emergence of like Rust as a solution to that because they realize, okay, well, we can't catch a lot of these bugs at runtime. So if we can just make everything get caught in compile time then we can provide a humanly like readable output and that's exactly what they've done. So now we're seeing like this widespread adoption of that programming language. But with that in mind, that is a big project. When you're talking about smaller projects how viable is this as a solution? Yeah, I mean, I think it's a very viable with smaller projects it might just be the whole team does something like this activity in a shorter amount of time even too. But it depends, this is something that I mentioned, we as a cadence at Red Hat like to get everyone we need in that room together we've almost had to do this like lighter weight come for an hour a week. But I think that a smaller effort, a smaller team could probably dedicate, let's do this over the course of the day together or maybe we do a day together here we hash out all the stuff then we do some validation and we come back for another half a day. And so I think you can move a little bit faster is my thought on a smaller group, a smaller team. We actually end up with a lot of different studios at Red Hat because our portfolio is vast but you could easily say, okay, here's one studio for this thing that we do as a smaller team. And to be honest, I think like 10 to 12 people in a studio is ideal, much more than that and it's a lot of cats to herd as you could imagine. At what point in the development lifecycle would you actually want to like adopt this as a method? I mean, ideally probably as early as possible but are there any caveats to that? Yeah, I think the tricky part and the key really is to do this like way up front. This is like something that happens at the beginning of a product lifecycle and so it really is in the before any implementation begins. Now you could have some planning around architecture and help that influence some of the discussions but this is really truly about saving time for those developers and really feeling confident that what you're building is not something that you're gonna release and then say, you know, didn't quite hit the mark. You know, in doing something like this, your confidence level is gonna be much higher than it would be without doing something like this when you're releasing because you've already done that initial upfront validation with users, with customers that this is really gonna fix their problem or meet their need. And you know, I think it's something that we talk a lot about in user experience as designers is we are happy to do like as many iterations in wireframes as we need to to get it right to save that time in development and testing and documentation and all these things that, you know, if we can do this stuff upfront ahead of time, like it just completely like improves that efficiency of the things you can deliver. And I think a big part of that too is working really closely with product management to like help mitigate any risk in like the things that are on that backlog, help prioritize in this way with validation and such. So there's a lot of good things that come out of doing this but definitely the recommendation is like at the beginning of that product lifecycle. I mean, not to say it can't be done in the middle but I think best results would be at the beginning before people feel like, why did I build all of this? And now you're telling me to shift. Now, maybe you'd get lucky and say, we just happened to validate that we made all the right guesses. That'd be ideal, I guess, if you do it in the middle but I think that tends to not happen as much. So yeah, and I think that that's a very important concept and I guess being able to detect a potential issue like upfront would really help. But one of the things that comes to mind as a like problem is what if you get like a very biased group of individuals or like users that all want a particular thing but that's actually a minority of the whole user space. How would you go about actually selecting the correct like group to participate within this workshop? Yeah, I think there's multiple layers to this and so having a really good cross-functional group involved in these studios is important. It's not just designers that should be in this. It's not just designers and developers. It should be product managers, researchers, QE docs. It should really be cross-functional. I think having subject matter experts in there as well is key so you get to know the space a lot better and what's going on today in that space and they have a lot of great ideas around what are the big problems that they see today out there that could be fixed with some future design thinking. And so that's like layer one is to make sure that this studio is cross-functional and then the second layer is to make sure that you're doing that validation with your user target. What is that target and product management marketing can really help figure out what is your target? You might learn stuff in that validation. They say, yeah, we're not sure if this is the target. We need to expand to more to help figure that out. This is all about like learning and helping ahead of building but really I think that that extra layer of validation with the target user where you're learning what they truly need and who that person really is and what their problems really are is helpful. And I think that naturally some efforts might, you're gut feeling on it might be easier to get right than others, some spaces are just really murky and you just don't know what you don't know. So the more research and validation ahead of time, the better and also always keep in mind this is a complete learning phase. There's no like, I've actually heard lately like I actually use the term validation a lot. It might not necessarily be the right term to use. It's more like you're evaluating, you're learning. This isn't about being right or wrong necessarily. It's about like learning continuously. So evaluation might be a better term to use. Right. And all right, thank you so much for your time today. Yeah, thanks for the questions. Yeah, yeah, no problem. And thanks both Liz and Dash for just this awesome presentation. With that, we are unfortunately out of time because, and which sucks because I kind of had more questions, but... Feel free to pick me. Yeah, I will. All right, thank you so much.