The Opus App

Case Study

A mobile app prototype aimed at helping college students better organize their lives. The goal of Opus is to encourage and track realistic assessments of time to complete tasks.

Summary

Opus is a mobile app prototype aimed at helping college students better organize their lives. Focusing on the EdTech (i.e., educational technology) market, Opus' distinguishing feature is the ablity to encourage realistic assessment of time to complete tasks. This is accomplished through notifications to the user, Streaks (a tool used to encourage correct estimations of task completion), and a statistical dashboard to monitor progress over time.

Goals

  • Use Opus as a teaching resource to aid students taking an interaction design method class online during the Covid-19 pandemic.
  • Design something that effectively demonstrates a connection between user goals, business goals, and aesthetic implementation.

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)

Introduction

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 methodology. 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 using GDD. 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 what a process page might look like.)

Opus was created as a teaching resource to help students taking Interaction Design I online during the Covid-19 pandemic better understand the GDD process. Students had access to my Miro whiteboard and were able to follow alongside my work and ask me questions via Discord, a messaging app. While the bulk of the 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.

A Word on Method

Opus was created using Goal-Directed Design (GDD) as its guiding method. (Note: GDD was modified to fit the parameters of a 16-week class.) GDD resulted from the work done at the Cooper design agency, founded by Alan Cooper. Cooper believed that interaction design would help solve many software issues. “Persona" as it relates to design, was created at Cooper. 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.

In this class, we taught the following phases of GDD:

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.

Research Phase

In short: In the Research Phase designers do research. This phase is important for GDD designers because it allows them to better understand the product's users as well as the 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 Interaction Design I, the deliverable for this section 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 over on Miro.

Kickoff Meeting

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 report 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 created a Problem Statement and listed some assumptions I had about the business and users.

From this exercise, 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.

Literature Review

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.

The goal of this review is to learn more about your product domain and to use this information as a basis for developing questions to ask stakeholders more pointed questions later in the Research Phase.

I had to create a research strategy because this is a new product for a hypothetical company. Since the 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.

Key takeaways from the lit review were:

Competitive Audit

An audit of competitor strengths and weaknesses is technically part of the lit review but is often broken out into its own category. A competitive audit is done to better understand 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. While each app had some good features, I think there’s significant room for improvement in terms of features and execution.

Because of this, I also investigated task trackers and project management tools not aimed at the academic market (e.g., Asana and Todoist) to better understand where EdTech tools fall shorts. 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 Interviews

Stakeholder meetings are an opportunity for the design team to get more information from decision makers. These meetings are done after the team has completed research into the context of the company's agenda.

Since there were no stakeholders on this project, there were no stakeholder interviews. 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 imagined stakeholder elaborating on their goals for this project. 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. 

User Research

To understand potential users, GDD uses ethnographic observation and interviews similar to Hugh Beyer and Karen Holtzblatt's contextual inquiry process. The goal of this research is to get a better sense of user lives, behaviors, and potential goals. (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).

To begin the user research process, a design team needs a sense of whom they might research. GDD suggests that they complete a persona hypothesis to identify likely candidates. This is a “first try at defining the different kinds of users for a product" (Cooper 2014, 46).

I imagined two main types of 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 persona hypothesis 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 staying up with classwork.

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.

With research complete, I now turn to the Modeling Phase to make sense of user interviews and synthesize all research.

Modeling Phase

In this phase, designers model (i.e., synthesize) research to seek patterns, define user goals, and create representations of research for the design team and stakeholders.

In the Modeling Phase, designers create user personas, which are “composite archetypes based on behavior patterns” uncovered during research (Cooper 2014, 62). Put another way, a persona is a narrativized, shorthand explanation of research. 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:

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.

Identifying Behavioral Variables

But how did I create Patrick and Marsha? Personas are not fictional creations from the designer's mind; rather, they are based on evidence. I will now show how I completed the process of synthesizing user interview information that I started in the Research Phase when I “predigested" interviews using a conceptually-ordered matrix.

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 said 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 the incommensurable. Why? Based on my observations and variable mapping, I noticed that I had 6 relatively organized individuals (interviewees 1, 2, 3, 4, 7, 8) and 2 more disorganized individuals (interviewees 5, 6). I used these two groups to organize two separate pattern clusters:

As stated above, 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 that 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.

Defining User Goals

Now I defined persona goals and characteristics. In addition to randomly generating names, Cooper suggests “brief bullet points" describing the characteristics of the behavior identified in continuums above. This might include descriptions of frustrations, feelings, attitudes, aspirations, skills, capabilities, frustrations, and/or their environment. For instance, for the Primary Persona, who represents the behaviors of interviewees 5 and 6 and is now named Patrick Little, the behavior cluster of “frequency of organizing" transforms into “might take breaks from organizing" with added detailing that Patrick “loses track of organizing from time-to-time because things come up." Marsha Daniels was also built out as the Secondary Persona, representing interviewees 1, 2, 3, 4, 7, and 8.

I identified 3-5 end goals (what a user wants to do) and a life goal (who a user wants to be) for each of personas. I'm doing this by looking at Patrick and Marsha's lists of behaviors and descriptions. Goals for Patrick 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 Marsha 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.

After crafting a narrative description of Patrick and Marsha, I now move to defining requirements for Opus.

Requirements Phase

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 them 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.

Defining Product Vision

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.

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.

Creating Context Scenarios

Next, I crafted a Context Scenario, a narrative that should establish the “primary touch points" that my personas have with Opus with emphasis on user motivations, needs, and goals (2014, 113). This narrative is told from the perspective of my personas and should should focus on high-level actions. To Cooper, “it is important to map out the big picture first so that we can systematically identify design requirements" (2014, 113). 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 scenarios, I identified requirements for Opus. Cooper gives us a template for how to list requirements as actions, objects, and contexts. For example: Call (an action) a person (an object) directly from an appointment (the context).

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 persona can achieve their goals? If so, I include it in my action-object-context 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 comprehensive idea of what needs to be built. Finally, I reordered my Requirements List by entries with the most important on the top.

Frameworks Phase

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 a product service by focusing on product “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.

Flows, Behaviors, and Organization

GDD creates wireframes by focusing on creating Key Path and Validation Scenarios. A Key Path Scenario is task-oriented and 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:

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.

Shifting to Figma

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.

That said, I chose to not change the design yet and wait for feedback from usability tests during the Refinement Phase.

Refinement Phase

During this phase, designers refine the prototype -- anything related to the interface, behavior, information architecture, idioms, widgets, etc. Evidence for refinement, in this instance, came from usability testing.

3 tests were carried out with participants from the Research Phase. These tests were moderated (i.e., introduced the test, answered queries, and 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:

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:

Other changes include:

Conclusion

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 (an adaptation of) 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 the experiences of Patrick, my Primary Persona, and Marsha, my Secondary Persona.

Lessons Learned

Works Cited

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. 2014. Practical Ethnography: A Guide to Doing Ethnography in the Private Sector, 1st Edition. Abingdon: Routledge.