Hello, and welcome to the bottom up skills podcast I might pass since I'm the CEO of quality and sound. We are well on the way with rapid prototyping. And today we're going to talk about some important thoughts. On how to actually do rapid prototype. And the crazy thing is that there is a really distinct pattern to conducting a sprint and to prototyping.

And there's a real journey to it. Any points of which can trip you up? Let me tell you. And, um, one of the key ways to get through all of that is having the right team. So today we're going to dig into rapid prototyping and how to do it so that you can be on your way to building a great product. Okay. Uh, the rapid prototyping journey.

[00:01:00] I mean, it is ridiculous. It's sort of mirrors the classic hero's journey starts off in such a good way. Uh, with lots of excitement, you're prototyping. Maybe you've got some great colleagues and creative people with you. And you're testing. And then all of a sudden, at some point in this journey, be confronted with the user saying, you know what?

I just don't like the prototype. I don't think the product idea is any good. And everybody in the team is going to look at each other and go, Oh, Now for first time, is this feedback, uh, can be pretty confronting, you know, like sitting with customers and having them say, you know what, I'm not into this at all.

Uh, I don't think this helps me is really confronting and it's a bit of a shock. And what I notice is that, uh, the idea of the customer has kind of become quite abstract, uh, for large [00:02:00] organizations. And so when they're actually confronted. Face to face person to person with a, with a user, with a customer saying, ah, this doesn't work for me.

I don't like the idea or whatever. It's like, Ooh, kind of uncomfortable, but it's, this is the moment where you can choose to embrace the feedback. And to work with it and to start to discover what it takes to delight them. And, um, it's really important that if you're rapid prototyping, remember that, you know, you would want to have three or four sprints in one day.

So, uh, you want to do it really close together. And I'm going to talk a lot about why that matters so much, but you don't just want to do one test with a user and then wrap up for the day. Uh, this sort of compounds. So what would be perfect is to do a whole series, like just to have an Epic day testing with users and you know, you're going to learn a ton, but the key to that learning is embracing that [00:03:00] feedback, particularly when either it's not clear or they're just.

Don't like it, because once you make the turn and start to discover what they do like and how it should work and why it should work in that way, that's when you start to move into this process validation and that validation will start you on a long journey. Now. The length of that journey is weeks and months.

Like, don't just think as you have one or two days of good prototyping with your users that you're done, um, I mean, I'm working on a product right now that we've been doing for over three months and we are still. Still learning new things. And we are one week from today, we will be launching and we're still learning new things.

So please remember that learning is a constant now often, um, what will happen when you're in a rapid prototyping sprint? Let's say for one, maybe two days in a row. At the beginning, [00:04:00] it's really all about learning. And then you will kind of shift more into what I call refining mode. So this is another distinct pattern to how we do it.

One embracing that feedback that I was talking about, but to knowing that you will, if you're doing the right learning, you'll get to a moment where you've actually like, Hey. I'm really confident. They like this feature or they like this product or service. Um, and then what you would do is you would move into what we call the refining mode, because what you need to do is tie up some of the loose ends about some of them, maybe the entry points in the user experience, you know, onboarding being a classic one.

Or completing an experience, helping them move into that advocacy part and sharing with others. But I want to give you this next idea. It's really one part learning followed by one part refining. And if you do the learning then refining you'll, you'll feel like a real level of satisfaction that you. You know, went [00:05:00] in, you learn a ton, found the things that worked, you validated those in your find them up.

So they might be ready to brief into a UX person to do wire frames, maybe even straight to a designer or developer. The important point here is make sure there's learning and refining going together. Now, the next thing I want to, uh, make sure that we talk about is this idea of the rate of progress. It is essential that you minimize the time between.

Testing the longer, the bigger, the gap between user testing with rapid prototyping, the harder it is to remember what you learned last time and the harder it is to discern the patterns in the feedback. If you test all day. And do 20 tests and every single one, uh, involved a user where they gave feedback, the pattern.

I mean, you hopefully have worked it out by, at [00:06:00] that point that you're like, wow, they hate this. They love this. We need to fix this. But if you're a particularly, you've got days and weeks between two different rapid prototyping, you're going to really struggle with the decoding of the pattern because you're just like, Oh, what did they say last week?

I can't remember, you know, It's just too much a, of a, of a gap and mint and too much memory or loss to make sure you do your rapid prototyping as close together as possible. And the thing that bridges each rapid prototyping test is the following question. What did we learn and what are we going to do next?

This orientates you to write quickly? What do we learn? What was working? Okay. How might we put that into the next test? How do we take it? One one step further. This is really important because if you do this, you'll get incredible velocity. You'll make a lot of progress and it'll be really, really worthwhile.

Um, [00:07:00] so what did you learn and what are we doing next now? The last thing I want to touch on is how to set up, um, a bunch of people, um, and how this is really important to rapid prototyping. We've talked earlier in this series about all the different types of prototyping. We've talked about creating direct response, which is really important.

So I'm assuming you've kind of got this now deep into your mind. And when now we've started to talk about these kind of more matter ideas, admittedly. About how to do these also, well, the rate of progress and making sure you're asking that question of what do we learn and what are we going to do next?

So now I'm going to kind of wrap up with how I would structure a team of people in a rapid prototyping sprint. And there's lots of good books on doing sprints and so forth, but I'm going to give you my go to a formula. And of course, you know, We're often tweaking this depending on the project or maybe some [00:08:00] time and availability constraints, but in a perfect world, this is what I would do.

I would build out from the sprint. So a sprint is going to be like a one hour session then where you've got prototypes, you've got real users, real customers to come and test them and to give them tasks, they're going to give feedback. And within that sprint, you want to look at doing six really good tests.

In a one hour sprint, if you only test once or twice, I would be really concerned about the productivity. I think there would be too much ta...