.svg)
DESIGN METHODS
PROCESS PAGE
Utilizing the Goal Directed Design Method, my team and I went through the entirety of the design process to properly assess market and user needs, synthesize research and key findings, determine potential users and use cases, and creatively build out a working, interactive prototype. This process yielded Jointly, a habit-tracking app that pairs users with accountability partners to encourage prolonged productivity.
Approach: Goal Directed Design (GDD)
Objectives: Familiarizing myself with & utilizing GDD
Team Size: 4 Individuals
Tools: Figma, FigJam, Adobe Illustrator
Application: Accountability-Focused Productivity App
Role: Visual Designer, User Interviewer
Duration: 6 weeks
Links: Prototype, research report, Team figJam
iNTRODUCTION
overview
I'm Chrissy Fortier, and I completed this project as part of an Interactive Design class requirement. My team's application, Jointly, is a productivity app created with the goal of increased user retention through accountability partner pairing. As busy college students juggling work, friendships, and academics- our team worked to build an app that not only helps users to meet professional goals, but personal goals that typically become low priority. This page walks you through our end-to-end process of preliminary research, synthesizing findings, structuring design plans, and building out a final prototype.
mETHOD
Goal-Directed Design
Jointly was created using Goal Directed Design, in accordance of Alan Cooper's book, 'About Face'. Cooper who founded and popularized Goal Directed Design (GDD) defines this method as a "complete process for understanding users' goals, needs, and motivations (Cooper 13)" This behavior-oriented design method focuses on user goals over application features. GDD is meant to fill the gap between research findings and design solutions. This gap is met when the information you know as a designer is used to implement key features, contexts, and elements of a product. GDD continues to hold design and research in balance, creating a thorough process, efficient timeline, and well-designed product- with the consistent priority of user goals.
This semester we completed the first five phases of Goal Directed Design, which I will detail in the next few sections. The tabs below outline each phase we covered, and its significance.
During the Research Phase, designers participate in a variety of activities to collect qualitative data. This consists of a kickoff meeting to develop timeline, a literature review to research existing content and knowledge, competitive audit to access current market needs, subject matter expert (SME) if needed, and user interviews, where designers can learn user goals, needs, and the context in which the product will be used.
Jump to Research Section ⤵️
The Modeling phase of GDD focuses on synthesizing research findings. It is the beginning of building the bridge between the data discovered, and how that data influences design decisions. Within the modeling phase, designers begin to identify patterns within their research findings to ultimately 'model' a potential user.
Jump to Modeling Section ⤵️
The third phase of GDD, the Requirements Phase works to identify specific requirements of the product. After creating a prospective user in the Modeling Phase, designers must now identify the requirements needed for the user to achieve their goal. What features must be included? What expectations must be considered? What scenarios must be detailed?
Jump to Requirements Section ⤵️
After determining product requirements, designers move to the Framework phase to implement these requirements within the app. This is done by creating user flows, (key path and validation) scenarios, and low fidelity wireframes to build out the structure of the application.
Jump to Framework Section ⤵️
Within the Goal Directed Design Process, the Refinement Phase is for refining, or perfecting the project. This involves building out a high-fidelity prototype, aesthetic visual design elements, and usability testing. The refinement phase is a cyclical process of designing, receiving feedback, applying the feedback, and so on.Jump to Refinement Section ⤵️
THE RESEARCH PHASE
Within Goal Directed Design, research is essential. The decisions that made Jointly were a result of our research findings. Our team used a variety of methods to accurately determine potential user, stakeholder, and design goals. Our research phase was outlined by four main components: a Kickoff Meeting, Literature Review, Competitive Audit, and User and/or Subject Matter Expert (SME) Interviews.
Kickoff Meeting
In professional design settings, a kickoff meeting is a common practice to sync stakeholder goals and product objectives. This serves as a landing point for teams to assess needs, potential obstacles, and product work flow. Since Jointly was made for a school project, our team took on the role of stakeholders to replicate a professional Kickoff Meeting. In this meeting, I tapped in to what stakeholders might expect for and from our product. With this, I created problem and vision statements. My team and I identified initial assumptions we had about the product and users. Ultimately, I decided that while many young adults have productivity apps, most users don't use them consistently enough to see an effective change in their goals or habits. I believe stakeholders could see an opportunity to transform the productivity app market by effectively increasing user retention. To read more about the results of our kickoff meeting, view our FigJam.
Literature Review
A literature review is typically conducted for designers to deepen their understanding of the topic their product is related to. Out of all of our research, the literature review contributed the largest amount of qualitative data. Since Jointly is a productivity app, we focused on a few areas relating to productivity, outlined below.
Procrastination
When researching procrastination, we realized that a need for productivity affects a wide range of individuals. In Joseph Ferrari's research on the topic, he stated there are many reasons people procrastinate, such as a lack of motivation, stress, and poor time management skills. Ferrari goes on to say that approximately “20-25% of all men and women procrastinate". This statistics continues to grow when looking at college students. It is estimated that 50% of undergraduate students procrastinate their work in some capacity *(Ferrari and Diaz-Morales 2014, 1).
.svg)
Data from Ferrari & Diaz Morales*
Accountability
Accountability is a large foundation of Jointly and a major part of our vision. Data supports the positive effects of accountability partners, estimating “people are 65% more likely to meet a goal after making their goal public. But their chances of success increase to 95% when they have a specific accountability partner to report to". The article continues to state that many people prioritize work tasks over personal goals, since individuals rarely have accountability for their personal goals, unlike professional goals(Liska 2020).
Data from Liska*
Goal-Setting
How do individuals approach goal setting? How can Jointly help them be successful in goal setting? When following individuals' success in sticking with New Year's Resolutions, a study showed that “one week into the new year, 77% of participants had maintained their resolutions; the number decreased to 55% after one month, 43% after three months, 40% after six months, and 19% at the two-year follow-up." The author of the study suggests a helpful framework when it comes to goals- to create goals that begin small- “specific, measurable, accepted, realistic, and time-framed"(Oscarsson et al.2020, 1).
.svg)
Data from Oscarsson*
Competitive Audit
A competitive audit is often included in the Literature Review but may stand alone. This audit serves as market research- What already exists? What are competing products? Is there gaps within the market our product can fill? While conducting our competitive audit, we accessed four major productivity applications. We noted strengths, pitfalls, and user feedback on these products and recorded our findings. When creating our competitive audit, we looked at four specific competitors: Habitica, Habit Tracker, HabitShare, and Habitat. After examining and using these apps, we created a competitive analysis table to chart our observations.
When deciding what categories to observe within the apps, we applied patterns we had seen in popular productivity applications. Our team concluded key features the app should include, and what spots are missing within the current market. As seen below, we compared various abilities, such as creating tasks or selecting from a default menu of tasks. Additionally, we reviewed key elements like the calendar, checklist, and accountability features.
.svg)
Competitive Analysis (Report pg10)
User Interviews
User Interviews are designated to flesh out real user experiences to shape the way we approach product design, and consider potential user goals. To start user research, our team needed to understand who to research. At this stage of GDD, a persona hypothesis is completed in order to define the product's users. For our persona hypothesis, we imagined that our user would be fairly organized and have pre-existing knowledge of organizational tools. We sought out college students and young working professionals, the primary demographic of our app. To understand potential users, Goal-Directed Design uses interviews, and these interviews aim to get a better sense of user lives, behaviors, and attainable goals.
We surveyed 5 students from Kennesaw State University and The University of Georgia. Interviews were completed virtually using tools such as Discord and Zoom. In these interviews, my team and I asked participants about their lives as college students/ working professionals, with an emphasis on how they organize their lives and what organizational tools they use. Immediately following each of the interviews, my team and I completed an affinity map exercise in FigJam. To do this, each team member took 8-10 minutes writing out all observations, questions, and notes regarding the interview. Ultimately, we highlighted patterns and commonalities between individual notes. This helped our team condense research findings and establish majority observations early on in the design process.
Affinity Mapping (FigJam)
With our Research Phase wrapped up, our team was set to begin the Modeling Phase.
mODELING
Synthesizing Research & Modeling Users
The Modeling Phase focuses on synthesizing data collected within the previous Research Phase. This phase affords designers a methodical approach to condensing content so it can be effectively considered for further design decisions. Ultimately, this phase models a hypothetical user, yielding a 'persona'. Cooper describes a persona as "the main character(s) in a narrative, scenario-based approach to design (Cooper 26)." Personas represent groupings of user behaviors, goals, and intentions revealed within the Research Phase. Before my team and I could render our persona, we needed to synthesize our data.
As stated in the previous phase, we hosted interviews with 5 individuals. Upon completion, my team and I compared notes, observing any commonalities or mutual behaviors between participant answers. Essentially, we were looking for any user traits, attitudes, or goals observed by multiple participants. From this, we created over a dozen behavior variables to represent our data. Seen below, each of the 5 interviewees is represented on a sliding scale. This allows us to easily synthesize our data and condense our findings.
Behavioral Variables
Behavioral Variables (FigJam)
Behavioral Clusters
Observing these behavior variables, our team was able to easily identify groupings that represent commonalities between interviewees. The groupings below represent majority behaviors found through research. For example, most of our interviewees reported high levels of self-motivation, while all of participants stated the preferred a minimal user interface over a complex application.
Behavioral Clusters (FigJam)
Persona
The majority groupings highlighted above are then compiled into one hypothetical user- a 'persona'. Our persona represents the behavior patterns observed within our interviewees. A persona creates a narrative of research findings, making it easy for stakeholders to imagine a hypothetical user. When designing for user goals, our team can refer to our persona to examine hypothetical user goals. This process yielded our persona, Annie Ramirez, shown below.
Persona (Report pg21)
Research Report
For a more in-depth look into the first two phases of Goal Directed Design, my team and I constructed a research report detailing each step. This report includes our completed literature review highlighting the positive effects of accountability partners regarding productivity. It also features our full competitive audit, analyzing competitor apps and current market needs. Overall, the report provides deeper background into how our persona, and ultimately Jointly, came to be. To learn more about our Research & Modeling Phase and read the full report, click the button to the left.
rEQUIREMENTS PHASE
Defining Requirements to achieve user goals
Since we were able to establish user goals in the previous phase, the purpose of the Requirements Phase is to define what is required for the user to achieve their goals. These requirements are initially thought of in a broad sense, and ultimately produce key features, necessary functions, and more. To accurately determine these requirements, our team established problem and vision statements, brainstormed application functions and behaviors, and determined persona needs and expectations.
What are problem and vision statements? The problem statement describes the difficulty the company is facing- what is your product going to solve? Cooper describes a vision statement as "an inversion of the problem statement that serves as a high-level design objective or mandate" (Cooper 110).
In this phase, my team and I identified the current problem- productivity apps with low rates of user retention and effectiveness- and established our vison- an accountability-based app so users can work alongside partners to achieve goals. Once the vision is established, we brainstormed on how this vision can be a real, working product. For a product to be successful, our product must meet user expectations.
Brainstorming Requirements
We knew now what problem we faced, and our vision for a solution. My team now had to brainstorm on how our vision would actually come to fruition. To the left, you can see our FigJam notes, hypothesizing what the app should do, what it might do, and what features it could have. Each team member was able to individually write out features, and then the group could compile commonalities named within the group, and sort through outliers. Many functionalities were mentioned as a result of our Research Phase, where interviewees highlighted key features, they thought were necessary, such as checklist and calendar features.
.svg)
Brainstorming Requirements (FigJam)
Persona Needs
Following brainstorming, my team and I synthesized the needs and expectations of our persona. Each user has a mental model of how they expect a product to look or behave. This expectation is often subconscious for the user, but remains a high priority for designers as we work to replicate that mental model, we produce represented models. Alan Cooper explains that "the closer the represented model comes to the user's mental model, the easier he will find the application to use and understand (Cooper 18)."
As we sought out to create our represented model, we started with hypothesizing our persona's mental model. What would Annie Ramirez (our persona) need from our product? What would she and other users expect? My team and I concluded around a dozen expectations observed from our research. These expectations include the ability to be paired with an accountability partner with similar goals, the ability to track progress, and the ability to be supported despite an inactive partner.
.svg)
Persona Needs (FigJam)
Context Scenario
After identifying features users may expect or need from our product, my team and I worked to conclude the context in which our product would be used. This was manifested as a context scenario highlighting how our persona, Annie Ramirez, would likely utilize our app. Our users expect particular features, but how would they use them? This context scenario provides clarity on how the typical user may navigate the app, and maximize its features. My team and I concluded Angela may use our app between classes and work, organizing both professional goals and personal hobbies. She relies heavily on notifications to remind her to return to her workflow within the app.
.svg)
Context Scenario (FigJam)
Requirements
With a context scenario established, my team and I were able to create a list of requirements for our app. To identify requirements, we reviewed our context scenario. For example, if our persona relies on notifications to be reminded of tasks, we must include notifications within our final product. From our knowledge of existing user motivations, behaviors, and goals, we compiled a list of requirements to achieve user goals. We also referenced data from our literature review, competitive audit, and original vision statement to include requirements that would meet stakeholder and business goals. With these requirements, we can begin creating low-fidelity frames.
Requirements (FigJam)
FRAMEWORKS PHASE
Defining the structure & flow
Using the list of requirements as a guide, my team moved into the Frameworks Phase. This phase determines the structure, flows, and architecture of the product. By limiting myself to low-fidelity prototypes (minimal use of color and visuals, frames to represent elements), the organization of the app can be determined before aesthetics. This helps to ensure the product's design is focused on how it works more than how it looks.
.png)
Low Fidelity Wireframes (FigJam)
User flows & scenarios
Within the Frameworks phase, we also fleshed out multiple pathways a user may take. This allows us to structure how screens connect to one another, and what pages could be prioritized for a typical user. To do this, I selected two main scenarios- Key Path, the primary pathway our persona will navigate throughout our product. Validation Path Scenarios were also includes, pathways the user may take, but wouldn't frequent as much. These pathways are necessary to have, but are taken less frequently by the user. The image below outlines the app's organization using low-fidelity wireframes and various scenarios.
.svg)
Key Path & Validation Scenarios (FigJam)
For Jointly's Key Path Scenario, I concluded our primary persona (if already a user) would enter into their dashboard, simulating a hub for all their tasks, partners, notes. If the user does not have an account, they would go through an onboarding process first. Validation Paths include screens like editing tasks, managing application settings, and other less traveled paths. With these scenarios set, Jointly was ready to enter the Refinement Phase.
REFINEMENT PHASE
High Fidelity Prototype & Usability testing
The Refinement Phase ultimately rendered Jointly's final prototype. However, to get there, we had to refine our screens from the Frameworks Phase, eliminating non-helpful elements for the user, maximizing clarity in navigation, and applying user feedback through usability testing.
My team transitioned to Figma to begin building out our high-fidelity prototype. To establish cohesion throughout team members' work, we created design styles in Figma. This design system was established before creating screens and remained consistent throughout the entirety of the design. All screens were designed on an 8 pt. grid, and adhered to iOS guidelines (touch targets and other tappable elements). We decided color and text styles, shown below.
.svg)
Color & Text Styles (Figma)
After establishing color styles, I moved forward as a visual designer. Since the structure and organization of the app was established in the previous phase, I was able to be detail-oriented with things such as alignment, spacing, and aesthetics. Hover over the images below to see the screens transform from low fidelity to high fidelity. Some screens remained similar throughout the Refinement Phase, while other screens were endured large transformations. Hover over the images below to see the screens transform from low fidelity to high fidelity.
Hover to view Before & After
Usability Testing
After creating a cohesive, interactive prototype we conducted usability testing. This allowed us to observe how a user would naturally navigate the app. This shed light on obstacles within the app, reassured positive features, and offered constructive criticism to Jointly. Our dashboard was the primary feature that received negative feedback. To apply the feedback and reconstruct our dashboard, we referred back to the Requirements Phase- evaluating what the user needs to achieve their goals. With this insight, we reworked the dashboard as an intuitive homepage, allowing users access to all other pages, while still remaining clear in functionality. Our dashboard is in the center, pictured below. Jointly ultimately underwent 3 rounds of usability testing.
.png)
Onboarding (Figma)
.png)
Dashboard (Figma)
Partner Browse(Figma)
With feedback applied and changes made Jointly emerged as a final, working prototype. Featuring Notes, Calendar, Partner Pairing, and more- Jointly is an all-in-one hub for productivity powered by accountability. Test it out for yourself- use the Figma embed below to interact with Jointly!
View FigmacONCLUSION
key takeaways
From Beginning to End
End to end, Jointly was birthed and grown around user goals. Initially, we conducted various research methods to gather data on the influence of accountability, the current state of the productivity app market, and what hypothetical users think about productivity/accountability. This research was compiled and synthesized, allowing us to model our hypothetical user, or persona, Annie Ramirez. With our persona established, we analyzed requirements needed for our persona and users to achieve their goals. These requirements were later compiled into low-fidelity wireframes, creating a framework for the structure and flow of the app. This framework went through usability testing in the refinement phase, working out obstacles and increasing clarity. Finally, Jointly came to be- with thanks to to the wisdom of Alan Cooper, my professor Dr. Lahey, and my wonderful, hardworking team.
How this made me a better designer
My longest project to date, Jointly took what I knew about design, and broke it. It refined my visual-focused design thinking to prioritize user goals, data, and methodology to create sustainable applications. Jointly grew my capability to communicate and design with a team, partnering new ideas and collaborating on workflows. Overall, Jointly made more aware of research-backed design and its significance in the current design space.
WORKS CITED
Cooper, Alan, Robert Reimann, David Cronin, and Christopher Noessel. 2014. About Face: The Essentials of Interaction Design(4th Edition). Indianapolis: Wiley.
Ferrari, Joseph R, and Juan F Díaz-Morales. “Procrastination and Mental Health Coping: A Related to ...” ResearchGate, January 2014.
Liska, Cathy. "Measuring Coaching Roi: ATD.” Main, November 19, 2020.
Oscarsson, Martin, Per Carlbring, Gerhard Andersson, and Alexander Rozental. “A Large-Scale Experiment on New Year’s Resolutions: Approach-Oriented Goals Are More Successful than Avoidance-Oriented Goals.” PLOS ONE 15,no. 12 (2020).