 And it works for you? Yes. That's great. I was trying to think. My absolute favorite, actually, is Nestle. It's one of my favorite apps. And why is that? Why is it your favorite? It's a great aggregator. It gives me an easy interface. It helps me say things that I want to look at over time. Okay. So it sounds like the things that came to mind for everybody were apps that you use all the time. You use them all the time because they're easy and they fulfill a need for you. So today with scenario-based planning for engineers, we're going to talk about how you two can try to achieve the same end result. The app is not working for me. So the question here is how do you want your users to feel when they use what you've created? Do you want them to feel that same amount of excitement, that same desire, that conviction to use what you've created? And how can you do that? So do you want your users to feel like this, wondering endlessly not understanding where to go, what to do, or do you want your users to feel like this? Accomplished, excited, successful, confident, and how can you do that? So scenario-based planning can help you achieve that result. Scenario-based engineering is really a method of planning that allows you to assure that you're meeting your users' needs and your business needs in a flexible and fast manner. So what does that mean? So it's the difference between, for example, making a list of features that you want to deliver versus an experience that you want to deliver to achieve those end results. So why should you use it? You'll deliver faster, better, allow you to use complete tasks. And a story I like to tell around that is Jared Spool, I don't know if any of you are familiar with him or his work. He's a usability specialist researcher who has a company called User Interface Engineering, and he's been doing this for probably over 30 years. And he tells a story of the $300 million button. And what it was was his engineer, he, a client of his, the engineers designed a system and developed a system. And it was a web application, you know, commerce product, where, you know, they instituted a standard typical login screen. So there was nothing special about it. User name, email password, reset password. But the abandonment rate was really high and the client couldn't figure out why. So he went in there and what they unearthed was that, you know, users didn't want to commit to have to be part of this specific club or whatever it was. They just wanted to buy what they wanted in their cart and get out of there. And the User Interface didn't allow them to do this. It was a scenario that wasn't taken into consideration. And so what they did was they, it was really the placement of the login and registration and the task that was overseeing, which was allowing users to continue without having to join the club or login or register. So they moved the login screen. They put the continue as guests button. And the, within one year there was a $300 million increase, $300 million increase for that customer base on their consumer site. So how does it work? We're going to go through how it works at a high level first using the example of you wanting to make macaroni and cheese. And I don't know if macaroni and cheese is an American dish or if everybody here is fairly familiar with it. It's pasta noodles with a cheese sauce. So there are many ways to accomplish this, right? You can buy boxed, homemade, frozen. You can order it out or to take in based on your requirements, right? So if you're heading out to the store just to pick out things that you think you might need, you might put orange juice, you know, maybe some pasta bread. And you get home, you want to make macaroni and cheese. And this is what you get. And that's not terribly appetizing. And it's not macaroni and cheese. So you're not getting your desired results. Versus you know the end result, the scenario that you want to accomplish is making homemade macaroni and cheese. So these are the ingredients you go to the store to get that you know you need in order to accomplish that. So you come home. You have all your ingredients. And you get to your desired outcome, which is macaroni and cheese. So how does it work? So first you want to plan based on your user-centric scenarios. So for instance, I want to make my macaroni and cheese homemade for the first time. I need to buy a pot, a measuring cup. I might grab some packaged cheese because I think that might be a little bit more efficient and easier. And I've scoped it down for my deliverable homemade macaroni and cheese. And I want to be able to accomplish that. And in order to do that, you have to first spec out your scenario. This is kind of the high-level process. You want to establish your scenarios, your release goals, maybe some pain points and some enhancements that you want to include. Pain points are things that a user encounters in your product that prohibits them from accomplishing the tasks or frustrates them. I'm sure none of you have ever encountered that in a software product at all or any other product. When you expect it to act or behave a certain way, and it doesn't, and then you have to spend time losing productivity to figure out why or maybe you're not even able to figure out why and so it's actually a blocker. So you may want to look into some pain points that users have and think about some enhancements that will extend the experience moving forward for them. And from that, you want to establish goals and for each goal, there'll be multiple tasks that come out of that goal and for multiple tasks, for each task, there'll be multiple steps and if you're using Agile, it might be stories, for example, or issues. And to start this, you want to decide who your user or users are that you're focusing in on. And in this case, it's John. He's a junior developer. So understand your users and the product that you're creating, the scenario for. And then you want to develop your scenarios. And scenarios, if you're working at a company, you might get them from your product management, product development. Support is really good for understanding pain points or things that aren't working for your users that you may want to develop scenarios around. Marketing can be included. If you're a contributor or you're at a small company or an independent, you can look at, even as a UX specialist, you might look at forums to see what kinds of issues of trending around your product, what kind of questions people have, what kind of things are saying, I wish I could do this. Short of customer visits with your product management and a UX will engage in, that's a way to get some insight into your user base. And once you've had a chance to establish your scenarios, tell them out like they're a story. The story communicates the needs of the user. So in this case, the user wants to persist their environment that they're working in so that when they revisit and they come back to it, it's always as is. They don't have to keep resetting things. They have the challenge that this particular user is an independent or a contributor and likes to work from a coffee shop and doesn't have two screens. And so how can you make this user more efficient and productive without having to navigate around a lot and waste a lot of time kind of moving between environments? And this user would also like an embedded library which maybe currently resides on a website and there's a lot of back and forth. Maybe there's a lot of downloading involved. And gee, this person thinks it would be really great to not have to do that every time and to maybe be able to access that from an embedded library and their IDE, for example. So I like to tell the story of, I don't know if you're all familiar with Starbucks. I know they have one here in Brno now. But Starbucks has a crafted and specific experience that's very well-branded for their customer base. And so when you walk into a Starbucks, you have a certain set of expectations. But each experience for any one person can be very different. So for example, I might walk in and I have a food allergy. And so they may have a different script, a scenario that they have to deliver on based on my food allergy or your preferences. Maybe it's a first time for your visit and you don't know where to go to pick up your coffee, right? Because you haven't been into a Starbucks. It's unusual. But it could happen. It doesn't have anything to do with your hair color or what type of shirt you have on. It's really more about the experience and the scenario that you fulfill when you go in there. So the next thing you want to do, once you have your driving factor here, that's the story that you want to fulfill. And then to do that, you want to plan around that. And that might be in the form of your release goal. So what do you want to accomplish based on that scenario for your release? And maybe in this case, it's increased productivity on different environment and different devices based on your environment so that you can access assets. Then you want to ask how and this is, how can you do this? And this is based again on any pain points you've ever been earthed on any enhancements you want to include. And you're basically making a thoughtful vetted out list based on that that will address those issues. And then, you want to take those and you want to establish work as goals. Establish the goals to solve the pain points and the enhancements. And in this case, we're going to go with the first example of persisting the settings and configurations for the workspace. This way, if I go to Starbucks and I log in, and I ask or, you know, I go on a business trip on a different device. Maybe it's an iPad or maybe it's a laptop. My experience is, and I don't have to keep going and maybe reconfiguring. It's set for me. And then, you want to scope those down into multiple tasks. And in this case, you know, the first one would be, the step would be, the task would be, you open the IDE, you configure it, maybe you go into a, I don't know, dialogue. You don't want to give a solution, but you just want to kind of understand what the task is of going in and configuring the environment. Maybe they directly manipulate the IDE workspace and configure it. Maybe they, I don't know, maybe there's configurations you can download that are already preset that, you know, your favorite bloggers configurations and you can download them and import them. We're not quite sure how, but we know we need to do just that. And then, based on that one task, what are all the steps they have to do to get there that will build out a story? So now you're getting to a very finite focused piece of work. And this is really great if you're across distributed teams, remote teams, contributor, that you're all working towards one goal and you understand maybe other things that's influencing, but you can work fast and focused because they're in very small bits. But when you release and you deploy to your user base, they're not getting bits, they're getting all these pieces coming together to fulfill the initial scenario. So this is a high level representation of the process. And on the left, you'll see the goal. So keep the environment sticky for reuse, say is the goal. And then you can write a description about it. You identify the user or users if there's more than one. And then you put the tasks across the top and then below it, it shows each story that you've broken the task down into. And this might be each path for each goal might be for one release, depending on how many groups you have or how many contributors, or it could be multiple release goals depending on how you structure your product. And this can be done in a spreadsheet. It doesn't have to, you know, necessarily look like this. It's a really easy way to plan and see your kind of high level needs and goals based on the scenario. Kind of out flat and how they relate to each other. A nice high level overview of what you want to accomplish and how. So if you zoom in, you can see, you know, the two tasks, equal small focus stories. And this can allow you to rapidly iterate and deploy. Versus a list that you might come up with to say, oh, well, I think that maybe if I want a better environment, I could just say, I want to reuse component code. But you don't say, how or why. Or workspace environment. We know we want to do something with that. And then everybody kind of comes up with their own ideas. It's not fulfilling any user's needs or addressing any pain points. So this is a list versus a scenario. And in doing so, the users will feel accomplished and cheer you on and come to a seminar and say how much they love to use your product. So to recap, user-centric scenarios, they're very focused on desirable, scalable. They can be very rapid and they alleviate a lot of pain points and enhance user experience. Thank you. Any questions? Do you have any pointers for how we can develop scenarios and who we should be talking to and how to get that initial information? Yeah, sure. So I'm not sure if you're here earlier. Depending on how you're working, if you're working in a company, traditionally you have things like marketing, product management, UX teams that can all kind of contribute and help you or even give you the scenarios or give you some kind of idea of what you could build on to do that. If you're an independent, some other tools are forums, blogs, things that people say about your product or the technology you're working with. You know, they don't like and they also love to put out what they wish that a product had. So those are good resources. They can give you insight. What else? So, do you iterate over the tasks and the pain points? So, yeah, so you may have a longer-term scenario that you want to fulfill and you may break it down and see that there's a lot to do there and you may break it into levels of accomplishment. Like, what do they need to do first to be successful? And then you could say, okay, well, we're going to do these three things first and then next time we'll do the next three. But you're all the time you're working with the end result in mind rather than just a random list of things that you need to check off and you might not deliver them in any sensible order that makes sense to your users, right? So, that way it's, right. And, you know, it may be, you know, you plan this out and you go to development and, you know, or you're the developer and you run into a problem while you're developing and you may have to tweak things. But at least you're still kind of heading towards the same goal with the same goal in mind and you may have to adjust it along the way. So, do you ever put value stream into sort of the idea of the scenario probably if you have this scenario and you break it down into goals that might be when you want to prioritize if it's a real necessary goal or not. And, you know, these are things, again, within a company you may get from product management or you may work very closely with product management on. If you're an independent it may be that you work with your customer on that as a client or if you're a contributor you may work with the community. Usually, it's nearly the same scenario. I mean, for example, with the environment I can imagine like sending it as a file or maybe having some centralized server for synchronization or diodes or whatever. How or at what time or important you decide which way to go or how does this work? That might be your goal or the task. Somewhere within that I want to be able to achieve this and it might be as quickly as possible and you might like in my case I might work with product management development to determine what that is and if we say we have a week to do it well, okay, developments is the fastest way they can achieve that is to import a file. Okay, and maybe next time if we want to revisit that because people are really not happy with that or they want additional functionality to make it easier then you maybe visit it and say, okay, or you schedule it out so that next time you then have the next way to do it and you kind of build on it that way but you don't give them no way to do it until you have the best way to do it so you progressively prioritize how you get there. Do you anticipate that the whole product can be built using this method or is it some additions or some new features? You could start out trying it on a feature to get the hang of it but I think if if you have enough force you could plan your product like this depending on the scope but you could break it down into individual areas and then just keep like within maybe an area of say planning if you may break that down into different scenarios for planning and establish which ones you want to ship at first that are important so you can kind of break them into different areas of your product and plan it out that way it's really a matter it's like a it's really a scoping exercise that you use your focus Yes sir Question So I was trying to think about how this is different than behavioral driven development just in the sense that here we're creating a scenario so is there a distinction in your mind or is that What would your definition of behavioral driven development be? So I would think that I would be creating a situation where I expected some activity to occur and then that and then verify that activity is indeed occurring So it sounds similar except for your this is more user centered rather than just like technical verification so it's almost it's similar and then you pick that kind of skewer like T and you align it to what you might be what value you're bringing to your users So the same just kind of more user centric for the experience to enhance the experience and not just the technical not just the technical value right So Spotify could give you access to music anywhere and it works beautifully but it takes you 10 minutes to get to the song that you want Is that right? Yeah, okay Thank you everyone for coming