Putting it All Together

In the past couple of years, I’ve had the chance to see many musical productions. Sometimes, they’re taking place within a 30 minute drive up to Hartford. Other times, I’ve taken the train to New York to catch a Broadway show.

Being an artist and performer myself, I understand the amount of preparation that goes behind the scenes. There are hours of work that take place, but all the audience sees in the two hours they’re seated in the theater is the result.

The same goes with prototyping an app, which my group tackled this week in Phase 3 of our design sprint. In this phase, we created a high-fidelity prototype of our fintech app.

Just to Recap

I’m participating in a design sprint with my group members, Taylor and Drew – and I’m documenting our journey on this blog. My first post was about what the design sprint process is. I also recapped our pre-sprint experience, as well as our ideation of solutions in phase 1 and the voting activities in phase 2. In this week’s phrase, we created our idea.

Planning the Work

After looking over the tasks for phase 3, I decided to reach out to my team in the group chat. From my previous experience in prototyping apps, I knew that this would be a much longer and intensive activity than the past two phases. I suggested that in addition to our weekly Thursday meeting, that we include an additional meeting the day before. Both members of my group agreed, and we added a Wednesday night meeting.

At our first meeting, we devised a plan for how we would go from our sketches and ideas to the high-fidelity prototype we wanted. According to a Figma blog article, “A high-fidelity prototype is a polished simulation of your final product. Visual design details and real content show the look and feel of the end product.” Our group chose to create a high-fidelity prototype because we want the users to see how the app would actually look and operate in real life. I mentioned how we should use Figma to build out the app. Once we got everything set up on Figma, I showed my group the basics of using the app, which was just enough for everyone to get started.

Deciding on Roles

There’s an old adage that says “two is company, three’s a crowd.” My group has exactly three members, myself included. This means that we had to specifically delegate who was doing what in order to keep track of all the moving parts.

The plan was simple: every member would do equal work in designing specific sections of the app. As a graphic designer, I had the ability to make changes that would improve the app visually. According to Jake Knapp in Sprint, “when you put together a diverse sprint team you’ll have all the right expertise in the room. Chances are, a few people in your sprint will do most of the work, but we’ve found time and again that there’s a role for everyone.” I found my role in being the lead designer, and though that holds a lot of weight, it was great to know that each of us in the group carried our weight – an agreement we had determined in the pre-sprint meeting.

Before prototyping, we made a board in Miro detailing everything that would need to be built out in Figma. We wrote down different topics, each serving as a menu option on the app, and then used stick notes to detail what specifically needed to be designed for each section. Then, we divided sections amongst the three of us. Creating this board allowed us to visualize what needed to be done to get from point a to z.

Prototyping

For the rest of the meeting, we stayed on the Zoom call for around 45 minutes, working on the app. At the end of our working session, we checked in with each other to see how much progress we had made.

Although a lot of the basics had been worked out, there was still more to be done. We decided to end our meeting, but all agreed to keep working on our sections independently before our second meeting the next day.

On Thursday, we hopped on the Zoom call and went back to work. We timed ourselves for an hour, during which group members unmuted at time to ask questions and give updates.

Trial Run

At the end of the hour, the prototype was 90% of the way there. We decided to give it a run by conducting a trial run. According to Pattie Belle Hastings in The Sprint Handbook, “The ‘Trial Run’ refers to a practice session where the team simulates the user testing process with a prototype before conducting actual testing. It helps fine-tune the prototype, identify potential issues, and ensure a smooth and effective testing session.” Not only did the trail run allow us to practice for Phase 4, but we were also able to see how well our app performed.

Taylor was chosen to be our tester. As she went through the app, we clearly noticed areas that were successful, and some others that weren’t as effective as we had thought. I jotted some notes down in a Google Doc to keep track of what went well and what needed to be improved.

There was still work to be done. The user test allowed us to see what that work actually is. We ended the meeting after giving ourselves a hard deadline to have the prototype fixed and finished to the best of our ability by Saturday.

The Big Picture

Phase 3 taught me a lot about managing expectations. Previously, I’ve built app prototypes that took weeks to create. In the design sprint, my group only had one week. And if one thought that’s already difficult, in a 5-day sprint, teams only have one day.

I had to accept the fact that this prototype, despite being built in Figma and being high-fidelity, would not be the absolute best that it could be. But an element of the design sprint is to focus on what actually matters. I had to shift my focus from the small snapshots to the big picture.

Take a Look

**1st screen:** The City Square is a virtual world, similar to Club Penguin. Users can tap different destinations, which takes them to educational activities related to personal finance topics.
**2nd screen:** The bank shows the amount of “Growthcash” — the city’s currency — they have earned and deposited into their “accounts.” Growthcash can be earned by completing the activities in the virtual world. This is used to teach money management and budgeting, as users can spend their growthcash on stuff for their virtual avatar.
**3rd screen:** The categories section is the more serious side of the app. It organizes all of the activities and lessons across the virtual world into one place by topic. If the user knows they want to learn personal finance, the categories section showcases everything the app has related to the topic. That way, the user doesn’t need to walk all over the virtual world to find activities that match what they want to learn.
**4th screen:** The Leaderboard Mountain incentives users to play the activities with their friends in friendly competition. When users friend each other on the app, they appear in each other’s leaderboard mountain.

Onward We Go

Now that the prototype is complete, our group moves onto Phase 4 – the second to last portion of the process. In Phase 4, we will conduct actual tests of the prototype with people outside of our 3 person group. I can’t wait to see what the feedback will be.