As part of the process, the students went out and interviewed collectively probably over 1,000 different key stakeholders in the insurance landscape. So, from customers, people who've got insurance claims right through to allied health providers, insurers, employers, the whole gamut of people that you would find involved when people have insurance claims. So, for us to get that wealth of information was really, really amazing. I think some of the insights that came out of that that were unknown to us was the fact that customers just want to know how their claim is progressing. They want to know where they're at, who they can contact if they've got a question. They want to be out to do it in their own environment, in their own time frame, in their own format that suits them rather than having something that the insurer prescribes to them. So, a letter or a form or a phone call that may not actually meet their needs. It was really, really encouraging to see the different communication preferences that our customers have. Our customers also are doctors, and we know that time is really precious for doctors. So, to be able to have one of their patients come in with the AF1 on their smartphone and show them their claim form, and show them the information that they need, one would make things a lot quicker, and it would make the doctors life a lot easier and for the insurance companies to be out to get the information at the click of a button. One of the earliest and most interesting customer insights we had wasn't so much about the product itself, but it was about how we were positioning the product. Because the product itself it's really flipping the whole idea of the spending savings paradigm, so something completely new to customers. What we did after we built our prototypes, we then hunkered down and built a working proof of concept which we're super proud of. Then we recruited all this beta testers, just put it out in the world and it completely flopped. It wasn't necessarily the product, people got the idea. But it was a massive learning for us that you have to have the right supporting information to let people know, number one, why should they use the product? Number two, how they should use it? And number three, what's in it for them? By identifying this early through the prototyping and proof of concept process, having that information in place as we move into customer launch is getting the right level of focus that it needs. With this challenge I faced in the whole iteration feedback process is being able to distinguish between what the end user is saying versus what the end user actually is implying or feeling in the process. So they could say something but deep down inside that you're trying to articulate something else. They might not know how to say it. And in most cases they don't. But when you start unpacking further, you realize actually the key insight is this as opposed to what they're saying specifically in front of me. Then try to distill that in such a way that it can form an insight that then influences your point of view and then gets, I guess, translated into design strategy. Is also trying to cut through the noise of the feedback points that we get. We get feedback points that say, "I don't like that color. I don't like where that pattern is." But really what they're trying to say to you is I don't see how the location of that specific feature is going to help me engage with it. I don't see how this color is going to really draw me into uses any more than I have to. And it's trying to really break through all that. How we went about doing that in terms of selecting or prioritizing this feedback over another feedback was pretty much letting the users do the talking on that. So, as we put a feature in, we test it. And if there's enough noise on that specific feature, you tend to see a trend over time as you start talking to enough people. We might keep that button in just to see if it frustrates a few more people. And enough people say, "I really don't like that button there. I really don't like that color." Then the volume itself tells me, "Okay, there's an issue with that." If it's a one-off, one person says it I unpack it a bit more potentially. But it doesn't mean that I've changed the whole product design because of that one person's feedback. Maybe there's a little bit of it got a few as well based on a sense that if you've designed something, you've designed it because you've designed it with people's feedback in mind already. So there's already a basis for that being there. And I wouldn't take it away just because one person says, "I don't like that." If 15 people say, "I don't like that, " then that's a problem. I think the greatest challenge is really the overwhelming amount of feedback we received. And as a team, it's about being really single-minded and distilling the core essence of what you're trying to address and what you need to address to solve UBank's business challenge. Knowing the business problem you have to answer is key. Yeah, it's about really defining your customer, having clear personas and understanding their needs and wants and how the bank can really help solve them in an innovative and digitally simple way.