Getting to Know Stolen Focus

Introduction:

Our goal with this project was to develop a digital experience for teenagers that educates them on personal finance. The aim was to take a subject that is under-taught to teens and present it in an engaging and accessible fashion. Our team, including myself, was made up of 3 members of the Interactive Media and Communication (ICM) program at Quinnipiac University. To design this product, we conducted a non-traditional design sprint over the course of 5 weeks. Over that time, we designed and prototyped a mobile game called FinGrow, which combines a virtual world with video lessons and mini-games to increase teenagers’ financial literacy and knowledge.

Sprint Overview:

For this design sprint, we met once a week for 5 weeks, simulating a traditional 5-day design sprint. 

Phase 1: Following the sprint facilitation guidelines, we discussed the minimum viable product (MVP) for the application we wanted to develop. Following this, each team member conducted brief research on existing applications, mobile games, and finance topics. We presented our research to the group and we agreed on inspiration for leaderboards, in-game currency, avatar customization, and more. 

We individually completed the 4-step sketch exercise. We used the notes from our research as our inspiration for our sketches. The first three steps eased us into the final one where each team member sketched a proposal design for the main screen of the app. This process helped us narrow down what game concepts and educational elements were most important to the app. 

Phase 2: We uploaded our sketches and ‘solution sketch’ to Miro, a digital collaboration platform. Through presentation and discussion what we examined each team member’s sketches. This helped our voting, as we identified the our favorite proposal and then two individual game elements from the sketches that we would use as our foundation moving forward. Having a more sound basis for the app, we each created a 6-step ‘user flow’. This detailed what some most important steps in the path of the user, impacts from the game, and overall experience of using the app. For example, “user is financially literate and having fun while learning.” Although this is a simple statement, this is something foundational to the product we are designing, and clearly identifying it will help us maintain those criteria through further development. 

Phase 3: For this next phase we had enough concepts and details agreed upon to create a prototype. The team created the prototype using Figma, an interface design collaboration platform. It is important to understand the purpose of the prototype going into designing it, and its relevance to the purpose of the sprint. Moving from concept to prototype in just two phases is not a lot of time. However, one of the main purposes of a design sprint is that product development can be easier when the product is testable. Traditionally it could take a large amount of time and resources to get to a point where the product is testable. By jumping right to the point of having a testable prototype it helps the design team focus on the most important elements to the user, thus making a better user experience. What the design team needs to understand is that because they are creating a prototype in such little time, they should aim to create a simulation or a facade because creating a real product is not feasible. The details of what to include have already been documented and agreed upon through sketching and user flows. The team worked together through out the week designing each page and interactive element within the application prototype on Figma. 

Phase 4: At this point the prototype was in a testable place in development. It included an interactive main city, mini-games home screens, avatar customization, video lessons and quizzes, leaderboards, a friends-list, and user settings. Each team member scheduled a user test where user navigated the prototype, took notes on their experience, and answered a series of questions. 

Phase 5: Using our documentation throughout the process of the sprint the team compiled a sprint report which outlines our step-by-step process of designing FinGrow from conception through testing. 

The problem statement of this design sprint was to design an interactive experience for teenagers that educates them on personal finance. Similar to the way that social media platforms focus on maximizing the amount of time users are on the platform through algorithms, our team wanted to determine design elements that would maximize the time that users would be on our application through curating specific game elements. The thought process behind this is that the longer users are on the app, the more they will learn about finance which will get them closer towards the ultimate goal of financial literacy. That mindset combined with our research on existing mobile games and finance education inspired the social elements like the friends-list, avatar customization, and leaderboards. The goal was to give users added social value outside of the application through in-game competition and personalization. Our team’s approach was to design an experience that gave the user everything that they could want in a mobile game based on the base features while not sacrificing fun for education.

Sprint Activities:

Lightning demos: team members presented research based on current market solutions and other inspiration

Sketch Exercise: Each team member completed the 4-step sketch exercise, ultimately creating a ‘solution sketch’ which they would go on to present next meeting.

Speed Critique & Voting: Through presentations and voting on Miro, the team decided on their favorite of the three solution sketches and two design elements they would like to incorporate going forward.

User Flows: Using our sketches as inspiration, we each created a 6-step user flow. Following, we each presented what we made and voted on our favorite one.

Storyboarding: Based on the user flow we voted on, the team collaborated on Miro to make the storyboard. This served as the basis for the prototype in the next phase.

Prototyping:

Using Figma, the team divided up tasks and created the first prototype of FinGrow. The focus was on creating the general interface that users will use to navigate through the app.

Testing:

Each team member conducted their own test of the prototype with an interviewee. Users took notes while clicking through the prototype and then were asked a series of questions about their experience.

Results and Outcome:

The primary feedback that we received from testing was that users were easily able to navigate and interact with the prototype interface. Based on the interface, text, and designs they were able to intuitively make sense of the prototype and game concepts. All 3 users from testing said they would’ve liked to see a more cohesive theme throughout the application.

Conclusion:

Overall, the design sprint was run smoothly. Each team member was prompt and a strong contributor during our virtual meetings. All work was completed on time and up to our standards. Based on the sprint process and our results from testing, it is clear we need to further develop the individual mini-games, create a curriculum for the video quizzes, make a more detailed theme throughout the map. Our Team was able to accomplish a large amount in a short period of time through virtual meetings and collaboration platforms. We created a strong foundation for a mobile application that has a clear purpose and direction for further development. By playing to each other’s strengths and approaching each sprint phase with an open-mind it led us to create a product that includes each team member’s perspective.

For design sprints, there is almost always going be a surplus of ideas. Not only that, a lot of them will be good and intriguing ideas. I’ve always admired decisive people. Being able to know exactly what you want in a given moment or putting your mind to something and then having an unwavering commitment to it is a great quality. As a creative person, and someone who always has multiple ideas, the decision to go in one direction also means the rejection of other ideas. For those reasons, decisiveness can be intimidating and a challenge. 

The unique experience I’ve had from my time sprinting is that decisiveness doesn’t have a strong impact on development. The design of the sprint process is refined enough that the role of a decision-maker is placed in moments where decisiveness is required. It is important to maintain a flow and work environment that is constantly moving forward. After all, part of the sell of a design sprint is that it puts two months of work into 5-days, so constant progress is essential. To ensure this, the role of the Decider is worked into the design on sprints. The creators of design sprinting call it, “a role so important we went ahead and capitalized it.” (34) Typically, the role of the Decider will be given to a Founder, CEO, VP, product manager, or an executive in the company that has the proper depth of knowledge to make assessments. 

My experience with sprinting has been in an academic setting so I would argue that the power of the decision-maker is more pure in a sense than in a professional environment. In an academic setting, the role of the Decider is not concerned with stakeholders or personal gain, so it is truly about working with the best ideas and centered on creating the best product. ‘Working with what you have’ is a phrase that continuously pops up in sprint discussions. Only having about 5-days means you can’t exactly reinvent the wheel in that time, so finding ways to incorporate the best of what you already have is the best way to move forward. Additionally, I believe that not having a true executive in the role of the Decider allows the rest of the sprint team to freely generate ideas without concern for doing what an executive might want or think. 

I certainly don’t think that the relationship between the Decider and the rest of the sprint team will hinder the process in most cases. Rather, it was justl to highlight a difference in my personal experience. Some of the best advice from Jake Knapp’s book Sprint is, “All the knowledge on your sprint team is locked away in each person’s brain. To solve your big problem, you’ll need to unlock that knowledge and build a shared understanding.” The more that is shared and understood from multiple perspectives, the higher the shared understanding will be. Genuine discussion and consideration is required for sprinting and design sprints are best executed when there is the highest shared understanding across the sprint team. 

Preparation is the key to success for design sprints. The preparation is arguably the most important element of the sprint. In my opinion, the preparation for the sprint is what actually makes it a sprint. It’s a lot like cooking. If the design team is an ingredient, the preparation is how those ingredients will be used. You can prepare an egg 100 different ways which drastically changes the final product and you can facilitate a meeting in many more different ways than that. In other words, a sprint would a terrible option for a weekday dinner. Sprint experts have broken down nearly every ounce of preparation required to do a successful design sprint. It starts from two weeks out from the first day of the sprint, details each minute of the sprint days, and every step until a final product is reached. 

The same way there is a time and place for an extravagant meal, there is a time and place for a design sprint. Author of Sprint, Jake Knapp, states that sprints are designed to, “solve problems quickly and be self-sufficient.” In cooking, something with this level of preparation can sometimes be intimidating because the ingredients are oftentimes expensive and you don’t know if all of the time, effort, and money will pay off. Knapp states on sprints that, “Best of all, the process relies on the people, knowledge, and tools that every team already has.” (23) I really can’t escape these food metaphors, but it’s like being forced to work with only what you already have in the kitchen and then finding out you have everything you need. 

If we cook so we can eat then why do we sprint? We sprint to problem-solve. Simple and linear problems are not a reason to sprint. We sprint to solve complex problems and overcome great challenges. We sprint to solve problems that do not have clear solutions. Knapp writes, “with the right team in place, unexpected solutions will appear.” (42) I love the term unexpected solutions. I love it because it makes it clear that for a lot of the problems we aim to solve a singular perspective does not capture enough of an understanding for the solution to be clear. The solutions for sprints are unexpected because the problem-solving process involves a fusion of perspectives that have never been combined before. Only through high levels of detailed preparation can the fusion be seamless and effective in the short window of a time for a sprint. When the resources are used most effectively,

“The room itself becomes a sort of shared brain for the team.”

Jake knapp

I’m upset with myself because I was entirely unaware of what a design sprint was until a few weeks ago. I’d argue most people don’t know what a design sprint is, so it shouldn’t be something to be upset about. However, it involves so many of my favorite things that it’s astonishing to me that I’ve never encountered it before. 

I am an athlete and a creative person and the number one thing that both of those have taught me is that process is the primary dictator of outcome. Process is the key to creation and design sprints are a detailed process. A design sprint is a carefully designed team project aimed at “providing teams with a practical framework to solve problems and innovate efficiently.” Design teams are created with members that come from different disciplines or backgrounds and the sprint is designed to enable high levels of cross-functional collaboration. The goal of these sprints, as opposed to more traditional solutions, is to compress months’ worth of work into a five-day process. 

What is the five-day process of a design sprint?

1. Understand & Define
2. Diverge
3. Decide
4. Prototype 
5. Test

The Sprint Handbook

My initial reaction to this process was doubt. How much can truly be accomplished in such little time? This process is designed to create a final product. Certainly, the final product won’t be perfect, but there is so much value in having a finished product to examine. Jake Knapp claims in his book Sprint that, “Focusing on the surface allows you to move fast and answer big questions before you commit to execution, which is why any challenge, no matter how large, can benefit from a sprint.” The final product of the sprint gives the foundation to “work backward to figure out the underlying systems or technology.” The final product from the sprint won’t necessarily be what ends up in the consumers’ hands, but to continue to develop something that is whole rather than assembling parts over a long period of time can have great benefits. 

Over the coming weeks, we will dive more into the specific days and challenges that could be met during Design sprints.

For the time being, I would like to discuss something that should take place prior to the design sprint to enhance team chemistry. To bring the athlete side of myself into things, I believe the job of a coach is to put his players in the best positions to succeed. Similarly, in a design sprint, you want everyone to play to their strengths. The name might be dry and uninviting, but Personal User Manuals are one of the best tools to help facilitate an environment where everyone can play to their strengths. 

“A personal user manual (PUM) is a document that allows you to explicitly communicate how you best work, who you are as a human being and provide others advice, ideas and a framework to best interact with you.”

Adam cammies

Rather than assuming what works best for others and wasting time trying to become a cohesive group, PUMs allow team members to gain a deeper insight into who they are working with leaving little up to question. Participants can include things like their favorite environment to work, best communication styles, how they respond in groups versus one-on-one, areas of weakness, and core values. By doing this, the facilitator of the team will be able to act like a coach and put everyone in positions where they are most likely to succeed.