OBJECTIVE
Bridge the gap between motivation and physical activity by designing an app that implements a rewards system to motivate people to start a healthier lifestyle and promote consistent fitness habits.
Role: Research, Interactions, Prototyping
Method: Goal-Directed Design
Duration: Feb - Apr 2023 (8 weeks)
Team: 4 Designers
Tools: Figma, FigJam, Discord, Zoom
INTRODUCTION
Imagine a gamer that thrives off the thrill of leveling up and beating final bosses because of the joy it brings them. When it comes to working out however, not so much. Working out can be a mental and physical challenge for many, considering they could be doing something more enjoyable like gaming. So, how can we keep people engaged during a workout like they are during a gaming session? That is where Plus Ultra Fitness comes in: a gamified fitness app that makes working out motivating and engaging, all while earning redeemable rewards for your efforts.
Our team created this project for our Interaction Design I class, where we learned and utilized Goal-Directed Directed (GDD), a design method developed by Alan Cooper. The following sections will further explain the GDD process and how we went through each part (Research, Modeling, Requirements, Frameworks, and Refinement), summarize our overall experience, and my personal takeaways from this project.
METHOD
Goal-Directed Design (GDD) is a design method that provides a “complete process for understanding users’ goals, needs, and motivations…” (Cooper 2014, 13). This process was originally created as a means to bridge the gap between results from research and effective design solutions, with its main purpose being to satisfy the goals of various users.
GDD is divided into six phases (research, modeling, requirements, framework, refinement, design support), however, to work with the constraints of completing this project for a 16-week college course, we only focused phases one through five:
RESEARCH PHASE
The Research Phase is the first and considerably most important phase of GDD, as it “the most effective means for gathering the behavioral knowledge that will help designers define and design products for users (Cooper 2014, 34). It is carried out by attending a kickoff meeting, creating a literature review and competitive audit, conducting stakeholder and subject matter expert interviews, and completing user observation and interviews.
Kickoff Meeting
Since this was a class project, a Kickoff Meeting did not take place as there were no stakeholders involved. We instead completed a Kickoff Meeting template provided to us that allowed us to take on the role of stakeholders, as it is important to understand the business context surrounding our product’s domain. In this “meeting,” we generated our problem statement and asked some key initial questions:
Literature Review
After the Kickoff Meeting, we reviewed literature related to our product’s domain to get a better grasp of it. This review includes but is not limited to: market research studies, user surveys, usability studies and metrics, user forum archives, industry reports, blog posts, and social media discussion topics. Cooper states this collection of literature is needed as a “basis for developing questions to ask stakeholders and SMEs” (2014, 38). Our team searched for various sources that fell into one of the following categories: motivation, the fitness app industry, video game enjoyment, and gamification.
The key takeaways from this review were:
Competitive Audit
To get a better understanding of the fitness app market, we looked for possible competitors of our product, particularly ones that utilize gamification or a rewards system. We analyzed the following: Nerd Fitness, SuperHero Jacked, Playfitt, and Peloton.
From this audit, we found that our competitors were lacking in several aspects, all while having several key features restricted behind a pricey paywall.
Stakeholder and SME Interviews
Since there were no stakeholders for our project, we did not conduct any stakeholder interviews. As previously mentioned, we took on the role of stakeholders during our hypothetical Kickoff Meeting. Due to the limitations of this being a class project, we also did not conduct any subject matter expert (SME) interviews.
User Interviews
Prior to looking for candidates to interview, we completed a Persona Hypothesis, which is “based on likely behavior patterns and the factors that differentiate these patterns…” (Cooper 2014, 46). We addressed three important questions to help shape our ideal interviewees:
- What different sorts of people might use this product?
- How might their needs and behaviors vary?
- What ranges of behavior and type of environments need to be explored?
Each team member was then tasked to reach out to at least one individual to interview. Our interviews took place via Discord or Zoom, and consisted of 6 participants of varying backgrounds. We inquired about their general life situation, workout habits, and gaming habits.
Once our team conducted all the interviews, we began to reflect on the information collected by completing an exercise known as Affinity Mapping. With our affinity maps, we looked for patterns within each of our interviewees’ responses, and categorized data based on those patterns.
From this exercise, we made the following observations:
With the entire interview process completed, we then moved on to the Modeling Phase where we synthesized all of our research to develop our primary persona.
MODELING PHASE
The second phase of the GDD process is the Modeling Phase, where we begin to represent our research through the creation of user models, known as personas. These personas are defined as “composite archetypes based on behavior patterns uncovered during the course of our research” (Cooper 2014, 62). In other words, they are models that are carefully crafted with user goals as the primary focus. The specificity that goes into making a persona aids us as designers to create an accurate solution that satisfies users’ needs.
Before we introduce the persona we developed, let us explain the process of how he came to be.
Behavioral variables
There are several steps that go into constructing a persona, the first being identifying behavioral variables. This process involves listing distinctions between the behaviors of our interviewees, focusing on their activities, attitudes, aptitudes, motivations, and skills. We identified 16 variables, which we then used to map our interviewees on continuums, and took note of significant clusters.
The clusters we identified often consisted of interviewees 1, 5, and 6, who we deduced to be individuals that were less motivated when it came to working out. The variables at which they clustered came to be the significant behavioral patterns that would build the foundation of our persona.
User goals
To define the goals of our persona, we first looked to the behavioral patterns identified above and synthesized some characteristics. We then added brief descriptions for each of these characteristics based on factors such as use environments, frustrations and pain points, attitudes and skills.
Cooper also emphasizes an important step at this point of the Modeling Phase, and that is to give our persona a name. With the help of a name generator, we can now get a better idea of the goals of our emerging persona, Tyler Maynard.
There are three types of user goals that can be utilized as effective design tools: End goals (what the user wants to do), experience goals (how the user wants to feel), and life goals (who the user wants to be). For Tyler, we defined four end goals and one life goal. Experience goals are not always needed for a persona, so we did not include any for Tyler.
After crafting a brief narrative and a few other details, we now introduce our fully realized persona, Tyler Maynard.
The Persona: Tyler Maynard
Now that we have Tyler, as well as completed the Research and Modeling Phases (compiled into a report that can be viewed here), we can now take our research and user goals to start defining requirements for Plus Ultra Fitness.
REQUIREMENTS PHASE
This next phase helps us to bridge the design-research gap through the use of narratives, and determines what requirements are necessary to help users achieve their goals. A key point in this phase is that requirements are not to be mistaken as features, as they focus more on the human and business needs that our product will provide.
Setting the Vision
It was important that we set a clear direction prior to the ideation process. To do so, we formulated a problem and vision statement through consideration of the goals and frustrations of our users. The problem statement emphasizes business needs and “defines the purpose of the design initiative (Cooper 2014, 110). The inverse of this is the vision statement, which puts users’ needs at the forefront and “serves as a high-level design objective or mandate (Cooper 2014, 110).
Once these statements were solidified, we explored ideas through brainstorming. As designers, it is hard for us to not have preconceptions of what we want our final product to look like, so an unrestrained brainstorm session helps eliminate those preconceptions. After this, we identified persona expectations. Expectations for how a product may work are highly influenced by users’ mental models, or how one internally makes sense of reality through their own representations. When constructing persona expectations, we derived them from users’ attitudes, experiences, aspirations, general expectations of using our product, and how they think of basic units of data.
Context Scenario & Requirements
To better understand how Plus Ultra Fitness would fit into our persona’s daily life, we constructed a context scenario, which is a narrative that focuses on “high-level actions from the user’s perspective” (Cooper 2014, 113) within our product. In order to make this context scenario, we addressed the following:
- What setting will our product be used?
- What primary activities does our persona need to perform to meet his goals?
- What is the expected end result of using our product?
Utilizing our newly crafted context scenario, we then derived from it the requirements needed to begin creating our prototype. Requirements typically consist of actions, objects, and contexts that our persona would execute or rely on to achieve his goals. As we read through our context scenario, anything we deemed necessary to meeting Tylar’s needs became a requirement, and this process — along with considering general business and functionality requirements — helped us to produce our requirements list.
FRAMEWORKS PHASE
With our list of requirements decided on, we then proceeded to the Frameworks Phase, where we placed importance on the “overall structure of the user interface and associated behaviors” (Cooper 2014, 119). In this phase, we first started out by structuring a low-fidelity wireframe through the use of Key Path and Validation scenarios, then followed that up with a high-fidelity prototype that we would refine in the final phase.
Lo-fi Wireframes
In order to put an initial emphasis on structure, we created low-fidelity wireframes based on our requirements list. These wireframes were very minimal in detail, as getting bogged down on details and aesthetics early on in this phase would only cause a lack of consistency in the prototyping process.
After making these frames, we connected them to each other using Key Path Scenarios and Validation Scenarios. Key Path Scenarios are the pathways our persona would frequent the most, typically tasks that can be inferred from the context scenario. Validation Scenarios are less important interactions that would not be included in the primary paths, but could still be necessary in an alternative scenario, such as accessing settings. Below is our low-fi wireframe with both types of scenarios distinctively shown.
Hi-Fi Prototype
It was now time to transition to rendering our hi-fidelity prototype in Figma. To ensure consistency, we decided on color and text styles prior to getting started. The aesthetics of our app were influenced by the cyberpunk genre, as we wanted to evoke an animated and energizing experience for our fitness app. Taking these stylistic choices, as well as everything we have gathered up until this point, we finally began to construct our first iteration of Plus Ultra Fitness.
Though we were happy with the progress we made so far, we knew that to craft the ideal prototype for our app, we needed to collect insights from people interacting with our initial prototype. This is what led us to the final phase of GDD: The Refinement Phase.
REFINEMENT PHASE
In this phase, we take our first iteration and fine-tune everything into a concrete design. We conducted two usability tests in which we introduced the concept of our app to the participants, and had them complete tasks to better help us uncover any potential pain points. From these tests we received the following feedback:
- App was easy to navigate
- Top navigation bar should not have any glow effect
- Text was a little overwhelming
- Less of the glow effect on the main pages
- Leaderboard was good
We took these comments and implemented them as we began refining our prototype. After two weeks of team meetings, YouTube tutorials, and careful consideration, we produced our final prototype for Plus Ultra Fitness. Below are images of some of the changes we made, as well as video clips of the final product.
CONCLUSION
This project our team’s first time creating an app utilizing a method as extensive as Goal-Directed Design. We learned how to conduct proper research and use our findings to create a persona that would lay the foundation of the design process. We were also able to list out requirements from the detailed work of creating a persona, that would be later used to bring Plus Ultra Fitness into fruition. In all, this experience was full of challenging moments that pushed us to think more with the intention of keeping users’ goals in mind.
What I Learned
With everything I do, I always make sure to reflect on what I was able to take away from it. These were my takeaways from this project:
Learning to speak up during lulls of communication within my team promoted more efficient work and exchange of ideas.
Usability tests are extremely important. Looking back, I would have liked for our team to conduct more thorough tests to gain more detailed user feedback.
As brought to my attention by my professor, licensing concerns would make it difficult to truly bring an app like this to life, as we used a lot of characters from popular anime and video games.
Even subtle animations and gifs can give more life to a prototype.