Jordan Scavo
We created a mobile app prototype that provides users with:
The project that we worked on over the course of 8 weeks is a lifestyle app called Good Sh*t. With this app, users can log their bowel movements and access reliable information around the topic of gut health.
Most lifestyle apps these days focus solely on goal-setting and the bettering of oneself. However, when it comes to gut health, what we found is that a lot of people are more keen on the idea of learning more, not necessarily self-improvement. This is the qualm that Good Sh*t addresses; it provides users with a way to observe patterns in their bowel movements and learn valuable information about their gut health without having to commit to goals.
Because this was a class project and we only had 8 weeks to complete it, we had to adjust the Lean UX method accordingly. Lean UX is typically iterative and takes place over the course of many months, so we had to shorten the process to only include 2 sprints and a week of refinement. While technically the process we used isn't true Lean UX, we borrowed some ideas from it, like sprints and MVPs.
The way that I will lay out our project is that I will split up Sprint 1 and Sprint 2 and further break these Sprints down into Design Week 0, Sprint Week 1, and Sprint Week 2. Then, I will discuss the work that my team completed in each of these time frames. First, though, it is important to consider the methodology we used for this project.
Lean UX is a UX design method created by Jeff Gothelf and Josh Seiden and is detailed in their book Lean UX (3rd edition). It is a culmination of the principles behind design thinking, as well as the Lean Startup and Agile methods. The method emphasizes making assumptions and then testing them rather than spending months researching and interviewing.
Starting with design thinking, it is a design approach that relies on “collaboration, iteration, making, and empathy” (Gothelf & Seiden, XXIV). The way in which Lean UX utilizes this framework is that it widens the extent of the design process past interfaces and artifacts. It also stresses empathy, urging designers to see things from the user’s perspective.
The Lean Startup process prioritizes learning, collaboration, quick experimentation, and removing waste. Gothelf and Seiden assert that it draws from this in that it pushes making a product with the least amount of effort that still is able to progress the team’s learning. This product is known as the Minimum Viable Product (or MVP) and was adapted from Lean Startup into Lean UX.
Agile focuses on “shorter cycles, regular delivery of value, and continuous learning,” and mainly intends to get ideas and products out to customers quickly so they can learn from the feedback they get (Gothelf & Seiden, XXIV). The speed in which Lean UX is carried out is how it relates to Agile. A more specific form of Agile that Lean UX adapts is Scrum. Gothelf and Seiden present four major elements that Lean UX derives from this practice: working in short cycles, providing value with each cycle, holding a quick meeting daily, and having a retrospective session after each cycle (158).
The term “sprint” originally came from the Design Sprint approach and refers to a five-day period in which the team “develops ideas, builds a prototype, and tests it” (Gothelf & Seiden, 121). Lean UX adapts this by arranging for the same process to be done over a two-week period which starts off with what is called Design Week 0, in which the team goes over the Lean UX canvas and plans how the sprints will go. During these sprints, the team meets every two days and discusses the work they completed since the last meeting so they can make sure everyone is on the right track.
During this week, our team went through the Lean UX Canvas. The Lean UX Canvas is a way of setting up and conducting the Lean UX process. It includes 8 boxes: 1) the business problem, 2) business outcomes, 3) users, 4) user outcomes, 5) solutions, 6) hypotheses, 7) the most important thing we need to learn first, and 8) minimum viable products (MVPs). We talked through all of the questions to come to a consensus on goals, problems, and possible solutions. We made educated assumptions based on our prior knowledge that we would then test in the sprint.
For this section, the question we had to address was “From the business’s point of view, what problem are we trying to solve?” More specifically, what we wanted to figure out was the domain our product would be in, what this domain currently fails to address, how our company will address these shortcomings, what our user base will be, and how we’ll know we are successful. The way our team went about this was that we individually answered what we believed using an online whiteboard and then dot voted on what we felt best answered the questions. This is the business problem statement we came up with as a result:
The current state of Lifestyle and Productivity in Health has focused primarily on achieving and improving the user’s personal goals. What existing products/services fail to address is informing the user why their health is in its current state and possible health risks. Our product/service will address this gap by providing the standard gut health through informing instead of problem solving. Our initial focus will be health conscious people. We'll know we are successful when we see user activity remaining consistent or increasing.
The next thing our team needed to think about was business outcomes. In other words, what would indicate to us that we had solved our business problem? We laid this out in a flowchart and worked our way from the top down. We started by thinking about the kind of impact we would like to see from the business side: revenue, profit margins, retention, and customer satisfaction. Then, we thought about what lagging outcome metrics, or behaviors of our users, could indicate that we have succeeded in these impacts. After that, we had to consider what behaviors would lead to our users exhibiting these desired behaviors, eventually leading to our intended impact.
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 could go into interviewing to see if our guesses were correct. Details we included to flesh out our proto-personas were general demographic information, traits, lifestyle choices, needs, and obstacles they may face.
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 conducted a group discussion to come to a consensus. We answered five questions centered around our users’ goals:
1. What is the user trying to accomplish?
Users want to understand their body and how to care for it.
2. How does the user want to feel during and after the process?
Users want to feel knowledgeable and comfortable with their body.
3. How does our product/service get the user closer to their goal(s)?
Users will be able to access information and regulate their habits to where they feel comfortable with their body.
4. Why would our user seek out our product?
Users will seek out our product to improve and regulate their bowel movements.
5. What behavior change can we observe that tells us they achieved their goal(s)?
Users will show consistent activity on the app, positive reviews, and refer the app to others.
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 and categorize our solutions by similarity.
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 chart is called the Hypothesis Prioritization Canvas. It would help us figure out what to do with these hypotheses and whether we needed to test them, ship and measure, and discard.
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 first. After that, we then discussed what particularly about these hypotheses would make them riskier than others. The way we laid it out was through a Risk Table, pictured to the right. On this table are some of the features we decided were the riskiest and would thus prioritize. As you go down the list, the level of risk diminishes. In the red boxes below each hypothesis, you can see our explanations as to why they had a certain level of risk.
At this point, with our team on the same page as to what kind of features we wanted to make, we set up a product backlog, or 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.
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. Pictured are some of the riskiest features we established and how we would test them.
At this point, our team split up what we wanted to finish during the first week of the sprint and assigned certain tasks to individual team members. Janice was assigned making the database of possible common causes of symptoms. I was to make screens for doctor’s prescriptions and treatment info. Jenny was assigned the products page. Jessie would make 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.
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.
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.
After interviewing, we again 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 interviewees include an option to add conditions when logging a bowel movement, resizing the cards in the carousel so it’s clearer you can swipe through multiple options, 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 clarifying 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, what wasn’t going so well, and what we could improve upon. The biggest thing we needed to think about was how we could do better considering the fact that the next sprint was fast-approaching.
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 flow of the prototype. We also decided that instead of working on separate pages and combining everything later, we would just work on one page so it’s easier to see what everyone else is doing. The last big 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 colors, fonts, and standardized elements (like buttons and icons).
.png)
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, with our alterations underlined:
The current state of the health and lifestyle domain has focused primarily on
goal-making and improving habits for people who are worried about their health. What existing products/services fail to address is explaining why their gut health is the way it is. Our product/service will address this gap by providing a way to log bowel movements to point out patterns to the user, as well as giving the user unbiased/reliable information and tips about their gut health. Our initial focus will be people who are curious about their health and why it’s important even if they’re not necessarily health-conscious. We’ll know we are successful when we see people are engaged with the app and are willing to recommend it to others.
Additionally, after having interviewed 5 different people, 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.
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. Janice was tasked with continuing to work on the tracking feature as well as adding informational tips and advice. I was assigned the onboarding and Jenny was to work on the profile page, but our responsibilities overlapped a bit with the feature that allows the user to log pre-existing conditions. Jessie was given the task of making the articles page.
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.
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.
Week 2 of Sprint 2 was spent continuing to alter the prototype to fit the interviewees’ expectations. It was at this time that the big, overarching things behind the scenes needed to be addressed, like standardizing all of the 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 received 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's sake since we couldn’t get consistent feedback on them, like the products page and the calendar on the home page. Features like logging and the articles page were added to the navigation bar for ease of use. We also decided to eliminate our male proto-persona because the men we interviewed were more so 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. I edited it to allow the user to pick from options when inputting their information instead of having to type it 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. The last big thing I updated little things that depended on the changes my team members made, like the pictures in the tutorial, to match the most current design of the app.
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, but I also learned a lot about myself.
It's important to note that while we utilized portions of the Lean UX method to complete this project, we did not use true Lean UX. In order for it to count as true Lean UX, we would have worked with a cross-functional team of developers, designers, stakeholders, and others who might have a hand in such a project. While we didn't get to do this due to the nature of the class, I would love to partake in something that allows me to work with team members of all disciplines at some point in the future.
There are a lot of things I would’ve liked to do with this project if I had more time. I think 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.
