Jordan Scavo
Our team created a plant care app that incorporates all the essentials of the everyday plant owner:
I have what is known in the plant community as a “brown thumb.” Pretty much every plant that has had the misfortune of being in my care has died despite all of my efforts. I tried different watering schedules, internet advice, and sunlight levels, but it all was too much to handle on my own. What I really needed was an app that had all the things I needed in one place: somewhere to make a schedule that reminds me when my plant needs to be watered, access reliable information about my plants, and ask questions if my leafy friend is looking a bit sick.
That was what excited me about Watering Day; all of the tools I needed to keep my plants healthy would be easily accessible and organized. My team made a prototype of an app that allows the user to set care schedules/reminders, log plant care, make to-do lists, communicate with other plant lovers, and access helpful information about their plants. This prototype was created as a class project for our Interaction Design I course.
In order to create such a prototype, we employed the steps from Alan Cooper’s About Face in a process that is called Goal-Directed Design, or GDD for short. Its purpose is to provide a framework for creating products that fulfill the needs of the target users. There are five major stages to GDD: Research, Modeling, Requirements, Frameworks, and Refinement, which I will be outlining in more detail in the following sections.
During the Research Phase of GDD, the design team must gather expectations from stakeholders, do research on the current market for the intended product, and learn potential users’ goals, values, and issues. The ultimate goal of this phase is to provide a foundation for the design team to formulate personas, a process explained in depth in the Modeling section.
The Research stage can be broken up into six steps that address these requirements: the kickoff meeting, literature review, competitive audit, stakeholder interviews, subject matter expert (SME) interviews, and user interviews. For the sake of time, our team bypassed the SME interview step and simulated the kickoff meeting and stakeholder interviews.
To read more in depth about our research process, take a look at our research report.
At the beginning of the GDD process, we would start with a kickoff meeting where our stakeholders would introduce the project to the design team and inform us of the goals and requirements they have in mind. Again, because we completed this project for class, we simulated this step by discussing as a group what our stakeholders might expect from us, using our kickoff worksheet as a reference.
The next step would be the lit review, where the design team would research information that relates to the future product or whatever domain it is in. Doing this helps us as designers to better understand the context of our product and develop questions for our stakeholder interviews later on. Because our intended users would be plant owners, it was essential for us to learn more about what constitutes indoor and outdoor plant care. The biggest things we learned from the lit review were to keep sunlight and watering details in mind when creating our app prototype because they are integral to any type of plant care.
Next was the competitive audit, where we evaluate our competitors’ products and their features. This step is important to the GDD process because it provides context for the designers and allows them to see what features do and don’t work in preexisting apps. For the competitive audit, we looked at other apps’ abilities to create watering schedules, send care reminders, connect with the plant community, contact experts, identify plants, keep a photo log, and complete a to-do list. What we found is that while some of our competitors’ apps contained some of these features, none of them had all of the features. We created a chart that displays which features competitor apps have.
After that we conducted our stakeholder interviews. Were we conducting the stakeholder interviews in a real business setting, our team would create a list of questions to ask key stakeholders in order to further understand and clarify the expectations for the project. Some questions we would have asked stakeholders would be expectations for budget, timeline, business goals, preferences, and more. Since we completed this project for our Interaction Design I class, we simulated this step by coming up with some assumption statements based on the stakeholder interview worksheet we were given.
The last section of the Research phase is the user interviews. Interviewing potential users is incredibly important to the GDD process because it helps the designers to get a sense of the goals of the user so they can design the product accordingly. This is an essential step in the procedure because it is what makes GDD unique; it is “goal-directed,” as it says in the name.
Our first step was to use the research and knowledge we had gathered to create a persona hypothesis of who we think our target user would be. We believed that we would have one main type of user: people who own and care for plants. We needed to differentiate, though, between different subcategories of this main user type. We identified ten subcategories in our Research Report, but the most important ones turned out to be: Plant Beginners, Plant Intermediates, and Plant Experts.
At this point, we conducted our user interviews. We interviewed five people who in some way fit the criteria of our target users we identified previously. Our team held the interviews online due to the COVID-19 pandemic and used both Discord and Zoom, social applications that allowed for voice and video calls between our group and the interviewees. In each interview, one group member moderated (asked questions) and the other four facilitated (took notes).
Immediately after each interview took place, our design team gathered on a virtual whiteboard (Miro) and did affinity mapping based on our notes. We individually wrote virtual sticky notes and then discussed while placing alike sticky notes together on the board. Some of the sticky notes didn't end up making the cut because there weren't several that could be grouped together. For the sake of visibility, these have been omitted from the photos of the affinity maps below.
From here, our design team moved on to the Modeling phase, where we would analyze our findings and formulate a persona based off of major user behaviors we identified.
The next step in the process was the Modeling phase. In the modeling phase, our team created a primary persona as well as a secondary persona. According to Alan Cooper, “User models, or personas, are detailed, composite user archetypes that represent distinct groupings of behaviors, attitudes, aptitudes, goals, and motivations observed and identified during the Research phase” (Cooper 2014, 62). Our primary persona is the hypothetical user that we will focus on designing our product for because they exhibit most of the patterns we found during user research, and since most of the secondary persona’s needs will be met by satisfying the primary persona.
Next in GDD is the Requirements phase. We used the personas we created in the previous stage to develop a context scenario, or a fictitious “day-in-the-life” story of our user. This is an important step in GDD because it brings our persona to life and allows the designers to more fully flesh out the persona’s needs and goals.
Building off of our context scenario, we formulated a list of required features that would fulfill our persona’s needs. Requirements are paramount to GDD because it informs how the Frameworks phase will play out. Below are our context scenario and finalized list of requirements.
At this point in the process, we moved into the Wireframing portion of the project. Referencing our list of requirements to guide our design decisions, our team essentially created a “rough-draft” of screens on our app and showed paths the user could take in the app in what are known as key path scenarios and validation scenarios.
Key path scenarios are the typical path the primary persona would take on the application, whereas validation scenarios are additional possible paths.
Our refinement process consisted of two major steps: prototyping and usability testing. Prototyping is essential because it is the final product that will then be translated into an actual coded app. It is therefore crucial to make a prototype that helps the persona reach their goals and is easy enough to navigate. Usability testing is helpful because it points designers to problems their prototype may have.
Relying on our wireframes as a framework, our team used Figma to prototype our application. We met twice a week to work on the prototype and discuss any ideas and issues with one another. At the end of this process, we created a sleek, modern design with organic shapes and natural colors incorporated throughout.
Our final step was to conduct usability tests to see how our prototype worked and what needed fixing. While conducting more tests would have been ideal, we only had time to carry out two. One of the participants was someone we previously interviewed. The tests were administered online on Discord so we could view the participant’s screen while they navigated the app. They talked through their thought process which allowed us to see where we may need to make navigation clearer.
The GDD process is essential in the interaction design world and led us to making a successful product. In utilizing Cooper’s Goal-Directed Design, our team was able to create a well developed prototype of the app Watering Day. Conducting extensive research, modeling our personas, laying out requirements, setting up frameworks, and refining our prototype evidently set us up for success. However, while GDD is a good foundation for designing, it wouldn’t have been possible without our incredible team of talented individuals.
