A mobile app prototype aimed at helping college students better organize their lives.
Opus encourages realistic assessments of time to complete tasks for college students. This is accomplished through Streaks (a feature that encourages correct estimations of time), a statistical dashboard to monitor progress over time, and notifications.
Goals
Approach
Goal-Directed Design (GDD)
Duration
March 2021 - November 2022 (off and on)
Role
Interaction design, information architecture, user research, content design
Team Size
One
Tools
Figma, Miro, Illustrator, Microsoft Teams, Discord, Google Meet
Links
Prototype (links to Opus' Figma files)
Miro (link to Opus-related research process)
Research Report (link to PDF)
Main Task List Screen
This is my “take” on a project given to students in an Interaction Design I class at Kennesaw State University. The goal of the class is to introduce interaction designers-in-training to a design method. We teach Alan Cooper's Goal-Directed Design (GDD) because it's a method that has been re-purposed by other methods in addition to being a fantastic teaching tool for students because it covers the full range of what an interaction designer might do in a career.
To complete this project, students read about GDD from About Face (4th Edition), pitch ideas for a mobile app, vote and form teams, and prototype an app from scratch. In addition to creating the prototype as a team, students collectively create a Research Report and individually create Process Pages for their portfolios. (This is an example of a Process Page.)
Opus was created as a teaching resource to help students taking this class online during the Covid-19 pandemic better understand the GDD process. Students had access to my Miro whiteboard and were able to follow along and ask questions via Discord, a messaging app. While the bulk of my work was completed in Spring 2021 alongside the class, the project was finalized in November 2022 (when I found time in my schedule!).
In the following sections, I'll explain GDD in more depth, walk you through each phase of GDD utilized on this project (Research, Modeling, Requirements, Frameworks, Refinement), and discuss lessons I learned while working on this project.
Opus was created using Goal-Directed Design (GDD) as its guiding method. GDD was used at the Cooper design agency, founded by Alan Cooper. Cooper created the concept of the “persona," a design technique often borrowed by other design methods. Additionally, Alan Cooper and Kim Goodwin, a Cooper alum, were on the formative advisory board for the Interaction Design Association (IxDA) while another Cooper alum, Robert Reimann, was the first president.
Cooper defines interaction design as the “design of interactive digital products, environments, systems, and services” with a focus on the “design of behavior” (2014, ix). In this definition, interaction design starts at stakeholder kickoff meetings and ends with supporting whatever product is made.
GDD was modified to fit the parameters of a 16-week college course. In doing so, we utilized the following phases of GDD:
GDD Phases
The ultimate purpose of GDD is to make sure users can achieve their goals. In short, if users cannot achieve goals, the product is not well-designed. Each phase is focused on making sure the designers never lose sight of this mission. The work that went into each phase is detailed below.
This phase is important because it allows designers to better understand the product's users as well as business and market contexts. Understanding these domains is important because each constrains the horizon of possibilities for the design team in certain ways. Without this information, designers are creating for themselves and not user and/or business goals.
In this phase, designers go to kickoff meetings, create or collect a literature review and competitive audit, complete stakeholder interviews, interview subject matter experts (if available), and complete user (and customer) observation and interviews.
In our Interaction Design I course, the deliverable for the Research and Modeling Phases is a Research Report. This report, a design object in its own right, demonstrates student abilities with research. Additionally, a “walk through" of the Research Phase can be viewed on Miro.
Kickoff Meeting Worksheet (Miro)
A kickoff meeting is a typical feature of project-oriented businesses. The goal of this meeting is to get everyone oriented in the same direction as it relates to stakeholder vision and product demands.
Since this project was produced in a classroom setting there were no stakeholders and, thus, no kickoff meeting. To keep somewhat consistent with a “real world" scenario, I imagined a hypothetical kickoff meeting -- What might stakeholders want out of Opus? Using a Kickoff Meeting Worksheet I created, I crafted a Problem Statement and listed some assumptions I had about the business and users. You can read the full problem statement on the Kickoff Meeting Worksheet picture to the right.
In summary, I decided that executive stakeholders wanted some type of mobile app prototype in the iOS ecosystem that focuses on helping college students organize their lives. They believed that existing EdTech products fail to create frictionless integration of siloed data and this will be our core value proposition.
To Cooper, designers do a lit review to better understand “the product and its domain" (2014, 38). This review can include: marketing plans, brand strategy, market research, user surveys, technology specs, usability studies and metrics, customer support data, user forum archives, industry journals, independent user forums, blog posts, social media discussion.
Since the hypothetical stakeholder goal is to help students get organized, I decided to research the broader field of productivity, which encompasses time management, organization, and motivation. Additionally, I researched student privacy as it relates to EdTech developers and third party providers. You can read the full lit review in the Research Report.
Key takeaways from the lit review were:
iStudies Pro
A competitive audit is done to understand better the opportunities and constraints for your product as it relates to other competitors.
The productivity industry is wide, encompassing calendars, note-taking software, distraction-blocking software, communication tools, timers, and team organization tools. I focused the audit on tools designed for the EdTech market: iStudiez Pro, myHomework, MyStudyLife, and Studious. I found that all of these tools fell short in many areas. Some of the tools even felt abandoned by their developers. While each app had some good features, there’s significant room for improvement in terms of features and execution.
I also investigated task trackers and project management tools not aimed at the academic market (e.g., Asana and Todoist) to learn where EdTech tools fall short. I found these tools to be superior as it pertains to usability and information architecture. I focused on learning from them for potential design patterns that could be utilized with Opus.
Stakeholder meetings are an opportunity for the design team to get more information from decision makers. These meetings should be done after the team has completed research..
Just as I did with the kickoff meeting, I used statements from a Kickoff Meeting Worksheet completed in class to imagine what stakeholder meetings might be like. I used assumption statements from the Kickoff Meeting Worksheet to elaborate on what I thought stakeholders might want. The full Kickoff Meeting Worksheet can be viewed over on Miro.
From these hypothetical meetings, I surmised that a range of stakeholders wanted to target incoming students but aim for wider applicability. Furthermore, Opus should be a “constant companion” in students' lives and be interoperable with data from schools and popular platforms (i.e., Google, Apple).
After all this research and hypothetical meetings, I shifted toward user research to see how stakeholder goals aligned with potential user goals.
To understand potential users, GDD uses ethnographic observation and interviews similar to Hugh Beyer and Karen Holtzblatt's contextual inquiry process. (Note: no observation happened because of the Covid-19 pandemic.) According to Sam Ladner, a noted applied ethnographer, “the ethnographic enterprise is to understand people, their beliefs, attitudes, norms, and behaviors. Your role as a data analyst is to make the connections between what participants do and say, and what your stakeholders want to know about their products" (Ladner 2016, 141-142).
Persona Hypothesis (Miro)
GDD suggests that designers complete a Persona Hypothesis to identify likely participants for research. This is a “first try at defining the different kinds of users for a product" (Cooper 2014, 46).
I imagined two main users, both in the same user role (i.e., performing the same tasks within the product). I hypothesized that Opus would have “high knowledge" users (detail-oriented and already use some type of organization strategy) and “medium knowledge" users (no coherent organizational strategy, but will find value in our ease of use). I decided to leave out “low knowledge" users because these students would most likely need some type of extra apparatus to be truly successful (first-year studies class, advising, etc). In the process of user research, I need to either verify or complicate these assumptions.
After receiving user research approval from Kennesaw State University's Institutional Review Board (IRB-FY21-393), I posted recruitment messages on Reddit pages associated with schools in the University System of Georgia in the United States.
I completed 8 remote user interviews using tools like Discord, Google Meet, and Microsoft Teams. Participants answered questions about their lives as college students with a particular emphasis on organization. They ranged from early to late in their college experience. Among other things, they discussed how organization fit into their daily lives, their organization rituals, and how they felt about their school's methods for disseminating information. Some lamented how long it took them to become better organizers while others shared their highly personalized strategies for keeping up with classwork.
User research participants
While students in Interaction Design I use affinity maps to tentatively “make sense" of user interviews, without a team, I used a conceptually-ordered matrix as a way to organizing information from user interviews. This type of matrix, used frequently in applied ethnography, organizes participants along one axis with key concepts related to research along the other (Ladner 2014, 153). I categorized each participant in terms of:
These categories helped me engage with interview notes with a critical eye and was the first step in seeking dominant patterns in interview responses.
Upon reflection, these participants were not ideal because many of them were highly organized students who had clear opinions on organization (which most likely attracted them to the recruitment post in the first place). While they taught me a lot, Opus will be more focused on students less advanced than many of these participants. I discuss this dilemma more in the Modeling Phase.
In this phase, designers synthesize research to seek patterns, define user goals, and create representations of research for the design team and stakeholders.
Designers do this by creating personas, which are “composite archetypes based on behavior patterns” uncovered during research (Cooper 2014, 62). Put another way, a persona is a shorthand explanation of research that encapsulates behavior patterns seen during interviews. At the core of personas are user goals with a focus on end goals, or what the users want to be able to do with the product. Personas are not only valuable for the design team (to stay focused on user goals), but help stakeholders and others in the business understand the logic behind the design team's decisions.
With that said, let’s meet Patrick and Marsha:
Primary Persona (Research Report)
Secondary Persona (Research Report)
Patrick is my Primary Persona, or the embodiment of dominant patterns seen during user research (i.e, the need for nudging to stay on track and a frustration at knowing how long work will take). Marsha is my Secondary Persona, or residual-yet-important patterns seen during user research (i.e., using organization to achieve greatness and a desire for rewards for completing tasks). As per Cooper, I’ll focus the design efforts on satisfying the Primary Persona's goals. That said, I believe that I can satisfy many of Marsha's goals without harming Patrick.
How did I create Patrick and Marsha? Personas are not fictional creations from the designer's mind; rather, they are based on evidence. Following GDD, I identified behavioral variables that I witnessed during observation. The variables are notable patterns concerning interviewee activities, attitudes, aptitudes, motivations, and skills. Cooper suggests 15-30 variables for each user role. I looked at my conceptually ordered matrix to seek behaviors. Once these behavioral variables are set, I mapped my interview participants to the variables along visual continuums.
I then looked for clusters of answers to seek dominant patterns. That said, not all interview participants were the same. While they were all the same user role, they often had differences that made them incommensurable. Why? Based on my observations and variable mapping, I noticed that I had 4 relatively organized individuals that often clustered together (interviewees 2, 3, 4, 7) and 2 more disorganized individuals that clustered together (interviewees 5, 6):
Behavorial clusters (Miro)
I acknowledge that I had an issue in my data. Because a lot of highly organized people responded to my study (see the “Organization skill" continuum), my data is skewed away from people who might most benefit from Opus. And these are precisely the people stakeholders are seeking. Thus, I made the counterintuitive decision to make the smaller cluster (interviews 5, 6) my basis for a Primary Persona. Why? This aligns with stakeholder goals and I hope that, given the opportunity to collect more user data, these two participants would still be reflective of the needs of less organized college students.
Cooper suggests fleshing out behavior clusters with “brief bullet points" describing characteristics (e.g., frustrations, attitudes, aspirations, skills, capabilities) identified in continuums above. For instance, for the Primary Persona, who represents the behaviors of interviewees 5 and 6, a behavior cluster of “frequency of organizing" transforms into “might take breaks from organizing" with added detailing such as “loses track of organizing from time-to-time because things come up." These added descriptions were based on behaviors identified during interviews and not made up by me.
Using lists of behaviors and descriptions for the personas, I identified 3-5 end goals (what a user wants to do) and a life goal (who a user wants to be) for each persona. Goals for the Primary Persona related to effectively estimating task sizes for school work, being able to adapt to changes in his schedule, and using organization to get back to other things that matter. Goals for the Secondary Persona related to having a long term view of her schedule, being rewarded for completing tasks, and using organization as a way to strive for excellence.
Finally, names and a brief narrative description focused on behavior are added to tell a story and to help identified user goals make narrative sense.
In this phase, the goal of the design team is to define what's required to be in the product to help personas achieve their goals. As Cooper notes, requirements are not features (although they'll be transformed into features later). Designers need to think broader about requirements, imagining requirements as the data and functional needs of your personas, qualities of the product/service, potential constraints, etc. All this happens by putting personas in a Context Scenario and then extracting requirements.
Problem/Vision Statements (Miro)
Cooper suggests defining requirements by starting with problem and vision statements formulated from “user goals and frustrations" (2014, 110). A problem statement defines stakeholder goals. A vision statement is “an inversion of the problem statement that serves as a high-level design objective or mandate" (2016, 110). If a problem statement is business-first, a vision statement is user-first. These remind designers of stakeholder goals and help craft what direction these requirements should be headed. You can think of these statements as two different ways to state a problem.
The next step is to brainstorm how Opus might manifest. Cooper says that, even though we focus our designs on our personas, it's impossible “to avoid having developed some preconceptions" about your designs (2016, 111). Goodwin, a long time Cooper employee, says that “many of the ideas that come up in brainstorming are built on flimsy foundations, personal biases ... getting these written down early makes it easier to set them aside and clear your mind for a more data-driven approach" (2004, 308). That said, some of these ideas might be beneficial later so I kept them in a “design graveyard" on Miro.
Persona Expectations (Miro)
After brainstorming, I identified persona expectations. Designs need to align with user mental models and, if not, it'll be difficult for users to achieve their goals. As Cooper says, “people's expectations about a product and how it works are highly informed by their mental models" (2014, 112).
Expectations for personas are built from: attitudes, experiences, aspirations, and how users think of basic units of data. I looked to my persona narratives for inspiration. This process takes some imagination on my part because the app has not been built yet. So, I'm hypothesizing based on my research. I broke these expectations down into data and functional needs.
Context Scenario - Patrick (Miro)
Next, I put my personas into Context Scenarios, or: narratives that should establish the “primary touch points" that personas have with Opus (2014, 113). This narrative is told from the perspective of my personas and should should focus on high-level actions. I imagined a “day in the life" for both Patrick and Marsha and how Opus might be integrated into their college experience. For Patrick, I imagined how notifications might be used to keep him engaged and how information learned from other students about changes in a class might be input into Opus. (Patrick's Context Scenario is listed here; you can find Marsha's on Miro.)
Finally, using these Context Scenarios, I identified requirements for Opus. Cooper lists requirements as actions, objects, and contexts. For example: Call (an action) a person (an object) directly from an appointment (the context).
Requirements List (Miro)
I went through scenarios seeking potential requirements. For instance, does an action in a sentence from a Context Scenario need to exist so that my personas can achieve their goals? If so, I include it in hte template that becomes my Requirements List.
In addition to requirements defined by persona goals, I need to list other business, brand, and/or technical requirements. While GDD is focused on user goals, it understands that user goals exist alongside business goals. This will give a good idea of what needs to be built. Finally, I reordered my Requirements List by entries with the most important at the top.
In this phase of GDD, designers focus on laying out a low-fidelity wireframe before shifting to high-fidelity prototypes. Wireframes lay out the basic high-level structure of by focusing on “flow, behavior, and organization" (2016, 121). Using these wireframes as guides, designers then shift to high-fidelity prototypes that can then be refined through usability testing.
GDD creates wireframes through a Key Path Scenario and Validation Scenarios. A Key Path Scenario is identifies the most well worn path your Primary Persona will take through your product. Validation Scenarios are screens and flows that are less frequently used and fall outside the Primary Persona's most well-worn path. These include things such as alternative scenarios (i.e., less frequently used tools), necessary-use scenarios (i.e., actions that must be performed, but infrequently), edge-case scenario (atypical situations that the product must nevertheless be able to handle), and use case that may satisfy my Secondary Persona without harming my primary persona’s experience.
The wireframe can be viewed here or Miro:
Wireframe including Key Path (pink) and Validation Scenarios (light blue) (Miro)
Wireframing is not a linear process; I built it on Miro bit-by-bit until I felt it was complete. I did not fully follow the steps outlined by Cooper because, in this instance, form factor, posture, and input methods were pre-defined by the assignment prompt and I already defined many functional and data elements in the Requirements Phase.
Rather, I jumped right to the Key Path Scenario by adding requirements to the wireframe and crossing them off the list. I did this by asking, “What screens would my Primary Persona use the most?” I stated with the Task List cluster and worked out from there. This process was messy and iterative, moving back and forth between the Requirements List and my ever-expanding Key Path Scenario. Building this piece-by-piece, I asked, "Is there anything else in Patrick's Key Path?" Once I felt it was complete, I marked the Key Path with pink interaction arrows.
I then added Validation Scenarios into the same wireframe as my Key Path Scenario and marked these with light blue interaction arrows. When considering the needs of my Secondary Persona, I asked “Would adding this feature/tool harm the experience of the Primary Persona?" When it didn’t, I added it. In the end, I had one Key Path Scenario and many Validation Scenarios overlaid to form a complete wireframe.
The final wireframe effectively expressed the Primary Personas goals through the implementation of a task list organized by category, task sizing tools, and a stats feature to track progress over time. However, some requirements did not make it into the wireframe. This is part of the messy process of translating research into frameworks — I’m making educated guesses based on data to make sure that the wireframe is focused on helping personas achieve their goals. Elements will be added, subtracted, and perhaps added again - this is okay.
Original Onboarding Screen
I then transformed the wireframe into a high fidelity prototype in Figma. This process allowed me to test the feasibility of the wireframe by seeing differently how a user might flow through screens.
The original high-fidelity prototype effectively kept the focus of the design on user goals. Information was laid out in a clear and consistent manner across screens. Screens were designed on a relative 8pt grid and tappable areas followed iOS guidelines for size (minimum 44 x 44 pts).
The design focused on creating a neutral app (i.e., black and white) design to accommodate school partners' ability to populate with their school colors as an accent color in Opus. This would allow schools to make our 3rd party software more visually consistent with their brand.
Over time, this created many issues. The goal was for schools to add one of their school colors as an accent color, but what about schools that used very dark shades or very light tints of a color? These would create potential color clashes and accessibility issues. Consequently, I chose to not change the design yet and waited for feedback from usability tests during the Refinement Phase.
Three usability tests were carried out with participants from the Research Phase. These tests were moderated (i.e., I introduced the test, they answered queries, and I asked follow-up questions) and remote (via Discord and Google Meet). I focused on having participants walk through the prototype while explaining their experience. Their feedback included:
This led to the painful but necessary decision to redesign Opus. Here are the original vs. the updated Figma files:
Opus Task List - First Iteration
Opus Task List - Second Iteration
The core of Opus is the Task List suite of screens so I'll focus my discussion of design changes there. First, I completely eliminated the school color integration concept and focused on a cleaner, dark mode-style interface:
Opus Task List - First Iteration
Opus Task List - Second Iteration
Other changes include:
Updated Stats Screen
The process of design is messy and iterative; many things need to be taken into consideration from user goals to business goals to the feasibility of implementation of both. In the sections above, I've clearly demonstrated the process of applying GDD to the creation of the hypothetical product Opus.
You can see a commitment to never losing focus of user goals, a hallmark of GDD. From the Research Phase to the Refinement Phase, all design decisions were considered relative to the harm they might do to persona experiences.
Cooper, Alan & Robert Reimann, David Cronin, Christopher Noessel. 2014. About Face: The Essentials of Interaction Design, 4th Edition. Hoboken, NJ: Wiley Press.
Goodwin, Kim. 2009. Designing for the Digital Age: How to Create Human-Centered Products and Services, 1st Edition. Hoboken, NJ: Wiley Press.
Ladner, Sam. 2016. Practical Ethnography: A Guide to Doing Ethnography in the Private Sector, 1st Edition. Abingdon: Routledge.