 Someone's buying a coffee like them from searching online then from walking down the streets Then you're actually understanding the complete experience rather than just a visual UI The faster you can come up with them and throw them away fine That's just the investment in time that you do as a designer to get to a solution When someone's prototyping something as a designer what you end up showing to the developer is not the final thing But an approximation and how do you feel about the state of prototyping tools? And just the process in general because it feels a bit like a Throwaway that you put all the energy and heart into something which is never going to be used There's probably two different schools of thought one is you use a prototyping tool to show intent This is where we can go what we want to do how it might work Whereas the other one is we use a prototyping tool to inform a developer about something specifically or here's the exact You know mechanism and parameters and all of the redlining that comes with it or the lack of redlining in terms of Opinion, I think the only thing I really care about is the speed in which you can create a prototype how you can show that intent show a vision I don't know show an iteration on a feature or or create something entirely new with minimal cost And that's the best thing that comes with it and the evolution of tools from Static images or sketches on a wall or just pointing at something and saying I want it to be like this To clickable prototypes to something that feels alive and has full flowing motion And you could almost test it with a user and have them think that or at least their mental model would be this is something real I can give you real feedback is fantastic But I think the problems that come from that can be you can let teams or organizations think that you're much further ahead than you Actually are and then there's a whole lot of engineering both reviews on the prototypes you're making But then implementation work setting themselves up in the right way Having feedback on those prototypes that you're making so you're not creating any unnecessary debts or complications down the track So give you examples of like where? Prototyping tools have been used for like the worst possible and what's the best case scenario? I think the best one I've ever seen was a guy who applied to a job using in vision while I was working at in vision He used it because a he didn't know how to build front-end at speed that he was comfortable with and be he could Test different versions with different people and see what his response rates were like Sometimes people were even leaving public comments on his prototype and letting him iterate on his case studies It wasn't accessible. It wasn't responsive. It was just a static image, but it was enough for me to go That's an interesting way that he's taken a prototyping principle and an iterative approach to how he's going to get a job How he's gonna communicate his own value. It's pretty cool Do you build to prototypes or have you built prototypes for it specifically for the engineers because that's more from the user testing side Yeah, I think Was that does the thing change because again, I suppose it's like in turn I think it can change purpose over time You can you can end up using it's your point about throw away prototypes the faster you can come up with them and throw them away Fine, that's just the investment in time that you do as a designer to get to a solution Setting up an engineering team or or pairing with them to kind of hand something off or start developing it Can be something different that's why I think specs and guidelines are a lot more and principles are a lot stronger when you can Inform the developer on like some of the variables that they need to stick to or you want them to stick to But then you show them a user's walk through time with the prototype so they go all right I can absorb that build something with the technology we have invent what I need to Augment what we don't have or do have at the moment and then stick to a set of principles variables guidelines Overall narrative when I come across the idea of redlining that seems like a really alien thing where you're designing Your sketch file or whatever and then you say okay This is going to be from this four pixels to four pixels in very prescriptive way and convey a better way of design I mean, do you find that to be the case or was that maybe me thinking of an extreme? I think a few years ago. It was still definitely something that happened, but now it's probably a symptom of something much deeper, which is that your design and I Know development or delivery teams are speaking two different languages entirely and the only thing that they can use to translate Intent or a vision into something that's real is a You know a source of truth that no one can disagree with and no one can disagree with four pixels versus five pixels versus a hundred pixels I Don't think it's something that's really necessary these days unless you're getting into something that's reusable So you could do a red line for a component that's being reused all over the world But a red line for a specific instance of something and how it relates to another component on the page is Probably something that's just a little bit too rigid Yeah, I mean it's like we're talking about the responsive web and things can change screen sizes can change sometimes a Site or browser may not load the thing properly. It just seems like a It misses the point of like you're trying to help a user get from A to B If you're obsessing over red lines, you're probably throwing something over the fence I think of back to my agency days where you would sometimes even give it to an engineer that was two seats away from you But their workflow was so different than yours and you would move on to another project that you had to give them that source of truth or a reference So by the time it went round or went through a round of revisions It would come back to you and you say yeah, that's close to what the spec was therefore I'm comfortable with that so you would give or take a percentage as you do on the web when Things scale move degrade speeds a variable things like that but I don't know in product teams these days if you're not Designing the future state of something that you own and looking at its current state and going that's not quite right That doesn't match the original intent and saying can we just nudge this component here or change this variable probably means you're not Holding on to two tracks at the same time. Yeah, which is a little bit naive Yeah, I mean I see like Airbnb have got an interesting approach where they will their code represents the components So then is that the react to sketch? Yeah, that seems like a very interesting approach I mean, have you ever worked in teams that do that kind of very close where? They're not like for like but there's like a something in the middle that translates that they both so that fits neatly into both Workflow so figmur is one tool as well or just come out with their API Yeah, I think the closest we've had was working with the design ops team that sat within a product team But had front-end engineers so they kind of informed the product designers and design leadership What variables we should be playing with by living in two worlds? They would tool you properly and they would also make sure that they were drawing from or pushing Those variables in the actual product itself in all the experiences you're building in terms of like the best alternative Is every designer can build everything that they make and a booking.com does that a lot of their UX designers have to build Front-end HTML CSS and JavaScript as a prototype So you don't really work in static images unless it's just I don't know quick divergent thinking Yeah, so you're just trying to come up with the idea first without having to try and design in the browser Exactly, so maybe you might want mentioning scenario based design So traditionally and then still to these days you get these requests, which is we have problem X I need you to solve it in these screens or this single surface And then you can go and fix that and you normally think about what's happening before what's happening afterwards What variables are at play but scenario based design, particularly if you're inventing something new or you're going to change something radically or push it in a slightly different direction is almost like a user journey but less static and kind of step-based is you'll you'll try and prototype or walk through time So you find out and you get to experience what's happening before a task is started How it articulates and is built and experienced then what happens afterwards and a scenario can be something like buying a car or Renting a car or dealing with a car accident dealing with an insurance claim That could be something that's much more specific and the insurance claim. I'll take an example That would be a scenario as a designer at an insurance company might take versus I'm going to redesign the claim form and it lets you have a lot more different perspective A lot of different perspectives other than maybe just the leadership you're dealing with or the person who's incentivized to get Less successful claims more successful claims this kind of information So you can start to balance out and really be that kind of that stretch armed person that lives in a few different worlds But has the perspective of the user because you've got you're framing that argument Rather than putting really subjective opinions on a particular field screen or widget, whatever it is So you're looking at the context like from start to finish Rather than like I said designing an individual even if it's hypothetical and you could even go and validate that scenario Or the scenario could be generated from insight or research that you've got or data that you've got It's not hard these days to visualize a user's walk through a product or a site Yeah, so you can if you're going to make a change to that run a scenario that would take that same That same path or a slightly different one that you're trying to make and just see how it feels see how it works test That see how it lands internally see if it's going to screw up anyone else's metrics If it is is that okay? You're going to create incentives somewhere else Yeah, we I think in during design sprints They call it just use a journey mapping where you actually look at the entire step So if someone's buying a coffee like them from searching online then from walking down the street So then you're actually understanding the complete experience rather than just a visual UI So how can people really start thinking more about scenario based design rather than very Specific based design and if there is an equivalent Opposite of that I think if you get and think about this every day is you get requests from people you say they come To you with a problem. It's just taking one level up and that's it Just think about the problem itself that you're getting and the person who might be doing it And then all you have to do is walk that person through that experience There's no hard and fast rule it can just as long as it's linear as long as someone goes from X to Y and something happens in between That's a scenario that you can sell it also lets you cover all possible use cases even if they're hypothetical By coming up with multiple scenarios in which someone might use this particular tool or service or product I found that it's it's a lot more exhaustive than you think it is and it lets people debate the merits of the Scenarios you're trying to design for rather than a specific instance or a screen Because you can win that argument and then lose the entire experience argument and you've done a crappy job most of that is actually processed by the brain and interpreted based on Experience previous knowledge and so on so what we are seeing isn't really what the eye is perceiving and so it's very important to design Again with intent for for those things