Modeling

After concluding the Research phase, we moved on to the Modeling phase. We started by identifying major behavioral variables we noticed during user interviews and then placing each participant on a scale based on their behaviors and opinions. Several of these scales gave our team great insight into what we focused on in our prototype, like prioritizing customization and giving users the ability to both browse broadly and within specific categories.

Once we identified the major behaviors of our user base, we created our primary persona, who is the hypothetical user that we will focus on designing our product for. We based this persona’s demographic traits and goals on the behavioral patterns from the previous step.

Requirements

The following stage is the Requirements phase. We used the persona we created to develop a context scenario, or a fictitious “day-in-the-life” story of our user. This is an important step 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 because they inform how the Frameworks phase will play out. Below are the context scenario and finalized list of requirements.

Frameworks

Once we identified the requirements of our persona, we moved into the Frameworks phase of the project. At this point, our team created a wireframe, or a “rough-draft” of the screens of our kiosk app. This wireframe shows paths the user could take, whether they be key path or validation scenarios. Key path scenarios (marked in red) are the typical path the primary persona would take, whereas validation scenarios (marked in purple) are additional possible paths. Click the image below to see the details of our wireframe.

Refinement

The last step in the process was Refinement. It consists of two major steps: prototyping and usability testing. Prototyping is essential because it is the final product of the design phase that will then be translated into an actual coded app.

Prototyping

We started by developing a clear visual style for the app based on typical styles used for boba shops. We chose some colors to represent the Koala Tea brand as well as typography that could be used throughout.

Referencing our wireframes, our team used Figma to prototype our application. Mekayla and I, being in charge of the individual product pages, also used advanced prototyping techniques to make certain functions more fleshed out, like price calculation and adding items to the cart. We used things such as expressions, conditionals, and boolean properties in order to accomplish a more high-fidelity feel. The following is an example of the interactions we attached to buttons like the add to cart button so it would update the prototype accordingly.

Usability Tests

We finished the Refinement phase by conducting two usability tests to see how our prototype worked. The tests were administered online on Microsoft Teams 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 they hit snags or got confused. After the tests, we fixed any errors and streamlined the prototype into the final product.

Screenshots from usability testing

Conclusion

As we went through, things did not always go the way we expected, but we persevered. One important thing to note is that some of the advanced prototyping we included relies on Figma features that are still in beta, so they don’t always work properly. However, to the best of our ability, our team came up with solutions to get around this, creating a sophisticated and high-fidelity prototype that we can all be proud of.

• Back to Home

Sprint 1

Design Week 0

The Business Problem

For this section, the question we had to address was “From the business’s point of view, what problem are we trying to solve?” We answered these questions in the form of a business problem statement which went as follows:

Business Outcomes

The next thing our team needed to think about was business outcomes. What would indicate to us that we had solved our business problem? We laid this out in a flow chart and started by thinking about the desired impact from the business side: revenue, profit margins, retention, and customer satisfaction. Then, we discussed what lagging outcome metrics (behaviors of our users) could indicate that we have succeeded in these impacts. After that, we considered what would lead to our users exhibiting these desired behaviors to reach our intended impact.

Users

After establishing a consensus over the business side of things, our team next needed to focus on the group that is most important to Lean UX when it comes to shaping our product: the users. We started off with a team discussion about the different kinds of potential users that might be interested in our app idea. After narrowing it down to two types, we made two “proto-personas,” or rough guesses of our average users. The point of the proto-persona is to make assumptions and get the idea of our user base quickly so we can begin interviewing and see if our guesses were correct.

User Outcomes

After creating our proto-personas, we next needed to think about the wants and needs of these hypothetical users. In order to do this, we answered five questions centered around our users’ goals:

Solutions

The next course of action was to think about what solutions we could offer so the users could achieve their goals. The team worked individually to brainstorm ideas and then reconvened to discuss what we had come up with. We then categorized our solutions by similarity in an affinity map.

Hypotheses

After that, our team needed to connect our desired business outcomes with the assumptions we made about our users’ goals. We then hypothesized what feature would help in achieving the intended business and user outcomes using a hypothesis table. Once we had listed out our hypotheses, the next order of business was to place them on a chart to rank their level of perceived value and their level of risk. This would help us to know what to do with these hypotheses and whether we needed to test them, ship and measure, or discard.

The Most Important Thing We Need to Learn First

Looking at the risk level of our hypotheses on the hypothesis prioritization canvas, our team then decided what the most important things were that we needed to test. We then discussed what particularly about these hypotheses would make them riskier than others. Pictured below are some of the features we decided were the riskiest and would thus prioritize.

Minimum Viable Products (MVPs)

The last part of our planning was to figure out what the least amount of work we had to do was to deliver the feature that would help the business as well as the user. After determining this, we also had to figure out how we would test these features and how we would measure our level of success. These would be our MVPs.

Sprint 1 Week 1

With our team on the same page regarding MVPs, we set up a product backlog detailing all of the features we wanted to make for our app. We kept it in order of risk, starting with the highest risk things we needed to test. Then, we decided which features we wanted to complete during Sprint 1.

Our team split up what we wanted to finish during the first week of the sprint and assigned certain tasks to individual team members. The features we focused on during week 1 included the database for common gut issues, the page for prescriptions and treatment info, the products page, and the doctor consultation screens. We worked on these prototypes on our own and then merged them together before our first round of interviews.Once we had built our assigned features, we devised some interview questions and interviewed 3 potential users. One of the team members would moderate the session, or ask the questions and keep the interview rolling, while the others would facilitate, or take notes. The following are screenshots from interviews 1-3.

Screenshots from sprint 1 week 1 of interviews

Once our interviews for the week had concluded, we jumped into affinity mapping. The team individually wrote our thoughts from the interviews on sticky notes in an online whiteboard and then grouped our thoughts into various categories. Categories included things like lifestyle, health, and prototype experience.

After gathering our thoughts, we figured out what worked with our prototypes and what didn’t. Most of the issues had to do with icons not being clear or links not working. We then adjusted our features to be tested alongside the new features we would build during week 2.

Sprint 1 Week 2

At this time, the team continued working on our assigned features from the sprint 1 backlog and made changes based on what our interviewees said. We then interviewed 3 more people to learn more about our user base and get their thoughts on the features we had just altered. The following are screenshots from interviews 4 and 5.

Screenshots from sprint 1 week 2 of interviews

After interviewing, we gathered our thoughts using affinity mapping. By this time, we were starting to get a better idea of what features potential users would want that we hadn’t thought about, as well as ones that we made that they didn’t want. Some features we decided to add based on the input from our interviews include an option to add conditions when logging a bowel movement and making an interaction that allows you to “favorite” products. Some features we decided to change were getting rid of the confusing “New Arrivals” section on the products page, making a clearer call to action button for scheduling appointments, and clarification of the “duration” part of the logging feature.

As the first sprint drew to a close, we conducted a retrospective meeting to devote some time to thinking about what was going well and what we could improve upon. One thing that our team decided to work on was devising task-based scenarios to guide the user through the prototype instead of just throwing them in the deep end. By telling them tasks to complete, we could better see where the issues are in the prototype’s flow. Another major thing we wanted to change up was our styling. As we moved into higher fidelity prototypes, we wanted to have a cleaner and more sophisticated look, so we decided on new color styles, fonts, and standardized elements (like buttons and headers).

Sprint 2

Design Week 0

Now that we had learned more about our potential users and what we wanted the app to look like, it was time to take a look at the Lean UX canvas again and alter things that no longer fit. Some of the boxes from the canvas stayed the same, like the business outcomes. A few boxes were relatively similar with some features discarded and new ones added. Initially, our plan was to prototype a way to log pre-existing health conditions, a feature that offers tips and advice, tracking/calendar capabilities, and a goal-setting feature. We discarded the goal-setting due to lack of interest and added 3 new features we felt would be important to our proto-personas: a profile page, a clear onboarding process, and a way to access articles about gut health.The biggest changes we had were the business problem and the proto-personas.
For the business problem, we had a few realizations after our first two rounds of interviews. The first was that there wasn’t much of a demand for goal-setting when it came to gut health; the majority of the user base was simply curious about the topic, not seeking self-improvement. We also realized that our users were not necessarily health-conscious people just because they were interested in their gut health, which ultimately also led to some changes with our proto-personas. With these changes in mind, our business problem could be restated as follows:

Additionally, after having interviewed 5 different people (one of which we interviewed twice), we were getting a clearer idea of our potential user base and had to rethink some of the assumptions we made about our proto-personas. We decided to reevaluate our proto-personas to account for what we noticed during the interviews.

Sprint 2 Week 1

The first week of sprint 2 began with team members again splitting up the features from the backlog to be merged before the interview period. This included the tracking feature (with added informational tips and advice), onboarding, the profile page, and an informational articles section.After building the features, we conducted another 3 interviews. The interview process looked a little different during this sprint given that our team intended to give the interviewees scenarios to go through the prototype. This yielded far better results and more specific feedback on ways we could improve flow and location of important elements.

Screenshots from sprint 2 interviews

The affinity mapping process was also different from the first sprint because we had more specific thoughts about features rather than just on the overall prototype. That being said, we split the prototype experience into smaller categories depending on which tab on the navigation bar the feature resided: logging, medical, products, or user profile.

At the end of the first week, the team yet again looked at the general consensus gathered from our interviews and adjusted our prototype accordingly. Along with changing the features to be more intuitive, we also adjusted our styles to continue working towards a sleek, high-fidelity look.

Sprint 2 Week 2

Week 2 of Sprint 2 was spent continuing to alter the prototype to fit the interviewees’ expectations. It was at this time that big, overarching things behind the scenes needed to be addressed, like standardizing all of text sizes, placing consistent navigation bars on all the pages, and making sure all links and buttons worked.We conducted our last 3 interviews using the task-based scenarios to guide our interviewees through the prototype. With the feedback we got from these interviewees, we made final edits to parts of the flow that users had difficulties with. Our final affinity mapping went about the same as the previous weeks with the same categories being used to organize thoughts from the interviews.

The team concluded sprint 2 with a week of refinement in which we made some last changes regarding styles and location of features. We decided on exact measurements to make the screens consistent, like distances between headings and text or between separate elements on the page. Some features were discarded at this point for simplicity since we couldn’t get consistent feedback on them, like the products page and the calendar on the home page. We also decided to eliminate our male proto-persona because the men we interviewed were outliers of our user base. With some final tweaks to our other proto-persona, we had a finalized version of our estimated user base.

During this period of refinement, one of the changes I made was streamlining the onboarding to better match the user’s mental model by allowing the user to pick from options instead of having to type them out and worry about misspelling. I additionally added little interactions that would aid in making the prototype feel more real, like buttons being highlighted when clicked and an Apple Pay pop-up when signing up for the premium service. I also updated little things with the changes my team members made, like the pictures in the tutorial, to match the most current design of the app.

Conclusion

After 8 long weeks of hard work, my team completed a prototype for a gut health app that we could all be proud of. The process was difficult; everyone on the team had different levels of experience and different ideas of what our product should look like. There were times when we had conflicting ideas, but we discussed these issues as a group and settled on a compromise. We also learned a lot from each other. Because of our different levels of experience with prototyping and interviewing, we could share our knowledge with our group members to help them grow. I learned a lot about prototyping and interviewing working with this group.There are a lot of things I would’ve liked to do with this project if I had more time. I would’ve fleshed out more of the details that bring the prototype to life. I also would have liked to find a way to incorporate the features we got rid of. I believe these features would have been useful in the product but unfortunately, we had to cut them due to time. I hope that perhaps I can revisit this project in the future once I have a bit more experience under my belt.

• Back to Home

Kickoff Meeting

At the beginning of the GDD process, the first step would be 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. 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.

Literature Review

The next step would be the lit review, where we would research information that relates to the future product and/or its domain. Doing this helps us as designers to better understand the context of our product and develop questions for our stakeholder interviews later on. The biggest takeaway from the lit review was to keep sunlight and watering details in mind when creating our prototype because they are integral to plant care.

Competitive Audit

Next was the competitive audit, where we evaluate our competitors’ products and their features. For our 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 to-do lists. What we found is that while many of our competitors’ apps contained some of these features, none had all of them. We created a chart that displays which features competitor apps have.

Stakeholder Interviews

After that we conducted our stakeholder interviews. If we were conducting the stakeholder interviews in a real setting, our team would create a list of questions to ask key stakeholders to clarify the expectations for the project. These might include budget, timeline, business goals, and other preferences. Since we completed this project for our class, we simulated this step by coming up with some assumption statements based on the stakeholder interview worksheet we had.

User Interviews

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 users’ goals so they can design the product accordingly. This essential step is what makes GDD unique; it makes it “goal-directed.”Our first step was to use the knowledge we gathered to create a persona hypothesis of our target user. We believed that we would have one main type of user: people who own and care for plants. Within that broad category we identified 3 important sub-categories for our user base: 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. Our team held the interviews online due to the COVID-19 pandemic and used both Discord and Zoom for voice and video calls. 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. The following are our affinity maps from the process.

Modeling

The next step in the process was the Modeling phase, in which our team created a primary and secondary persona. 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.

Requirements

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. These are our finalized requirements.

Frameworks

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 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 paths that a user might take.

Refinement

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. Usability testing is, of course, helpful because it points designers to problems their prototype may have.

Prototyping

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.

Usability Testing

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. The tests were administered online on Discord so we could view the participants’ screens while they navigated the app. They talked through their thought process which allowed us to see where we may need to make navigation clearer.

Conclusion

Goal-directed design is overall a helpful process in the interaction design world and allowed us to make a successful product. Our team was able to create a well-developed prototype of the app Watering Day by conducting extensive research, modeling our personas, laying out requirements, setting up frameworks, and refining our prototype. However, while GDD is a good foundation for designing, it wouldn’t have been possible without our incredible team of talented individuals.

• Back to Home