So, this is where things start to get really exciting, because we're able to take all of the research and the data gathering that we've done up until this point and turn it into something tangible that we can put in front of people's hands. At this point we're able to really start to test all the assumptions and validate all of the thinking that we've had at that point. Well, up until this point. There's no quicker way to validate your assumptions than to put pen to paper, take a couple of photos and string together an experience and then start to put it in front of people. The prototyping process, it really helps us to think in the shoes of the customer and map out the whole customer journey, or at least part of it anyway and identify pain points up early. And in case of the prototype that we're working on with the students post the MBA program, it taught us a number of things and that was really about making sure that you're supporting the customers throughout the onboarding process. So, we aim to build an app that was so simple that anyone could pick it up and use it. And in doing so, we stripped back the interface so it was so simple that that in itself became quite confusing. So, going through that prototyping process and having the time to refine the prototype, we ended up with just three separate screens. That allowed us to really focus on each of the data points we were capturing and give customers the confidence and knowledge that what they're inputting had importance and how it was going to be used. Yes. What we found really interesting about the ideation process and seeing the teams go through it was, it was really challenging any preconceived notions that they might have going in. And watching the teams come in and present their prototypes, taking our feedback on, and then really building on our ideas. Really, over the short period of time they are working on these prototypes and was getting to a much quicker and better outcome. So, we're really proud and confident of the products that we've designed and we're starting to build. We know that we've followed a really strong design process which means that we're getting a much higher quality product out into our customers hands. The prototype decision was a complex one. We received a lot of information from customers we spoke to, but it was actually a combination of the client validating our initial thinking combined with consumer feedback. We had about 20 in total, but all of them helped shape to the final outcome. So, we used elements from each of the earlier prototypes developed and rolled them into the one that we tested and felt was the best way. The switch from very simple scamps to full development actually came through a check in with the U Bank clients and they were wonderful in terms of collaborating with us and seeing how far we had moved the idea along. So, once we felt that the common themes from the people we were talking to had been answered and we felt that that was a really simple process, that was the point where we had it developed and rolled it out properly with very simple steps to make sure we answered it. We created a very simple 10 step process to show how people can visualize their savings goals using various social media channels. The initial prototypes we first had were very, very simple sketches. So, we drew, and redrew, and redrew them whilst we were testing at the same time. So, whilst we were collaborating with young millennials and getting their input, we ended up redrawing them to help answer their needs and what they're looking for in an app. So, it evolved across a few different iterations. The process was really interesting to us. I think the fact that we had a variety of solutions that the students came up with so it wasn't just one idea. There were four really comprehensive and value-creating solutions that they came up with. So, the process that they went on and the interviews that built in the feedback that they got really made us see that there had been so much thought and knowledge put into these prototypes that we thought, why not give one a go and why not take it to the next level and actually see whether this can work with our customers. And we'd not actually done that before. So, I think for us it was a real eye opener about what is possible, and not being afraid to go out there and test and learn. So, Swiss Re really enjoyed the prototyping process. It was something very different for us and the fact that the students that worked on projects came from a whole variety of backgrounds, meant that all of the things that they could bring into those prototypes were really outside the box. We weren't dealing with a roomful of insurance professionals; we were dealing with students from such a variety of backgrounds. So, for us it was really exciting to see the different prototypes that they came up with, and how quickly those prototypes evolved to become something that was really user-friendly, and something that we could actually envisage our customers using in the long run. So, over the six weeks, we really saw that prototype evolve into something that met the constraints of insurance. So, that was a part of the partnership which is really crucial. The fact that we had to embed the constraints that we are bound by in terms of insurance and regulation to make sure that there was the expertise side from an insurance angle but also the customer angle and what we thought or what we had gained from the process that the customers wanted in that app or in that software program to make sure that we were really meeting their needs, but within the constraints of insurance to make sure that we weren't going to do anything outside regulation, and we're still providing a service that was going to improve the process or the experience that customers had when they're on claim. Go out and you talk to lots of people, you get lots of feedback, you get lots of user needs, and need to translate those needs into insights. Those insights if you analyze them well enough, will then determine what your purpose statement is for designing what you're doing. And then from there everything sort of, the point of view, your point of view statement. Your point of view statement then determines what your working prototype would be. We ultimately did end up on one minimum viable product which then resulted in a single prototype, which then went through the process of iteration. And by the end of it we had created about seven or eight prototypes, all low fidelity prototypes, before we start developing our high fidelity prototype. It was a conscious choice. High fidelity means a lot more work, a lot more effort, and in most cases, money. And obviously we were doing a project so we didn't have any money. We had a skilled personnel team who could do it but we didn't want to waste this time designing a high fidelity prototype until we were quite certain that the low fidelity prototypes were-, it came to a point where it was almost constant and not changing significantly anymore which meant that the sixth or seventh prototype was pretty much validating, or was being validated by our users through user testing, and that apart from minor issues, it was pretty much good to go in terms of designing something that was high fidelity. So, we consciously decided that we will not design high fidelity until we were quite happy with the low fidelity version being translated into high fidelity. Our first prototype was a PowerPoint deck, which had clickable content in it and we figured out that you could click and actually open up to another screen and another PowerPoint slide, so we use that as our initial very first prototype. And it was an ugly blue color scheme, but it worked. We used it for user testing and it generated the results and the responses that we wanted. The high fidelity prototype was pretty cool. One person in our team knew how to use some sort of software. And it pretty much looked like an app, only that it was on the screen as opposed to being able to put on your mobile phone. So, it had all the functionality of an app and it was touchable also so you can touch and it reacted. So, it pretty much was a creation of an app without it being on the phone. And it was slick in terms of how everything moved and connected to each other, which was a far cry from our low fidelity, mouse clicks here and there. So, that was pretty impressive. In terms of deciding what features to put into the prototype, that's where version one was the, put everything in and use. We put all the thoughts, all the ideas into a version one prototype and start testing our user base. And very quickly you could see mass confusion in terms of "I don't understand how these things interact". And even then in designing the first prototype I realized that, we as a team realized that certain parts of these don't actually really fit together. Let's just put it in anyway and see how people respond. It's amazing how people respond to a prototype in front of them and quickly hone in on what they like versus what they don't like. That pretty much helped us to start eliminating ideas, especially when there's enough users saying, "I really don't like that. I don't know why it's there". That generates an insight and we're like, Okay, enough people have said "That's useless..." a useless piece in the scheme of things, let's take it out. Through the process of elimination I guess, we start reducing features in the next levels of prototyping to a point that you come to a prototype that forms your minimum viable product. The other piece was just what was our point of view and what was all strategy in terms of the solution that we're presenting? Whenever we put something into the prototype, we'd ask ourselves, does this actually result in the end goal that we want? And if it doesn't, does it really have to be there?
