HydroHomies
A Water Intake Tracking Application
Project Overview
What? - HydroHomies is a water intake tracking application designed with a twist so that it stands out from competitors. We wanted to design this application with a social aspect to keep users interested in sticking with the app and keeping themselves hydrated. This was implemented by adding a "Homies" section, and the ability to challenge friends to complete different hydration tasks.
Approach - Our team completed this project using Lean UX design method broken up into two different sprints, whilst studying this design method following the book, Lean UX, Designing Great Products with Agile Teams, 3rd Edition, written by Jeff Gothelf and Josh Seiden.
Duration - 7 Weeks (Oct 3 - Dec 1 2022)
Tools - Figma, FigJam, Discord, Microsoft Word
What is it?
HydroHomies is an app idea conceptualized due to the nature of most hydration/water intake tracking applications being dull and not leaving the user with a dopamine fueled reward. This idea was designed so that users would have more than simply a number that they are trying to reach on a day to day basis. It provides users with a social aspect to the application giving them more goals and drive to complete them. One of the number one driving factors of the human race in our society is competition, and we focused in on that for this application.
HydroHomies is an application designed and prototyped as a class project at Kennesaw State University.
HydroHomies was designed using Lean UX. "...Lean UX process creates only the design artifacts we need to move the team’s learning forward." (Gothelf & Seiden, XXIV.) This design method adopts a model based on experimentation and user validated learning comparatively to Goal-Directed Design. Throughout this project we divided it into two different sprints. Within these sprints, we had a design week, and then two of development/prototyping and testing. A total of six weeks during the sprints, and then a week of refinement at the end.
Sprint 1
Sprint 1 consisted of the first three weeks of this project. As stated earlier, each sprint was broken down into three different sections.
Week 0: Design
The first week of our sprints were dedicated to the Lean UX Canvas provided to us by our professor. In this week we went through and conceptualized everything that needed to be done for the following two weeks. In Sprint 1, this involved our team going through things such as creating proto-personas, forming hypotheses, and then ranking these in order of highest risk, to create our MVP's for the first sprint.
"Proto-Personas"
After discussing what our business problems and outcomes, we dove into creating our proto-personas. With the nature of Lean UX, our proto-personas were our best guess as to who is using, or who will use this application. There is no prior research to beginning this project, other than our general knowledge of this field. "The proto-persona approach ensures that everyone has the same image in their head when “the user” is invoked." (Gothelf & Seiden, 56.) This process gave our team a good image of who we are creating this product for, and what their different needs would be. Throughout this first week, we ended up with three different proto-personas, fitness enthusiasts, users with medical conditions requiring proper hydration, and those who just want to better their health. (After further user interviews and development in the second sprint this ended up being narrowed down to just two personas.)
"Forming Hypotheses"
After developing the proto-personas, we moved into discussing what the users are going to be looking for and how they are going to benefit from using our application. Another round of making sure all of the team members understood what the general idea of the application is going to be, and we can all see not only the big picture, but the small things in which make the project whole. With this knowledge, we are able to turn the earlier assumptions into more fleshed out ideas and create hypotheses to base our MVP's off of.
Taking the information we have already developed from the business outcomes, proto-personas, and the outcomes the users will be expecting from the product, we were able to ideate features that will be need to be implemented within the application. We put ourselves in the mind of our made up personas and thought through features they would be looking for to complete their goals. These were then listed in the table provided to the right. It is color coded based off of what each part of the sentence corelated to on the information we had already had. This helped us visualize who would be looking for what out of the product, as well as be able to look back if anything needed to be changed in the future.
After completing this process and producing a list of features we believe would be required, we moved onto the prioritization canvas. This allowed us to visually represent what would require the most testing and developing, versus features that wouldn't require as much work or be less intensive on testing with the users in the future weeks. The canvas is provided in the image below.
Following the same table convention as before, we took the risk assessment from the canvas located above, and moved them into another table organized by the risk order we developed. Under each feature listed, we explained what the risk involved is and how it would affect the user outcomes throughout the application. Once we understood the risk order of the features, we turned into developing our MVP's for the first sprint. We copied over the same table and instead of explaining the risk involved, we thought through how we are going to develop these features and how they will be tested once we get to user testing in the coming weeks. "When we say MVP, we are talking about a small and fast way of learning something." (Gothelf & Seiden, 88.) We thought out what the best way of developing these features quickly was, so that we could get to testing quickly. This would allow us to be able to gather valuable information from our interviews throughout the weeks without spending lots of time perfecting these features and them to not be what users are looking for.
Provided down below is a screenshot example of the full FigJam board for Sprint 1 Week 0.
Week 1: Prototyping/User Testing
Moving onto Week 1, production of the application in Figma commenced. Throughout the project file in Figma, we ended up creating multiple different version of the prototype based off edits we made from the information gathered during user interviews. Before anyone in the group started, I made what was essentially a wireframe/super rough draft prototype v1 so that when everyone started we had a general feel for the direction we wanted to go with the application. This also allowed me to get my ideas down for certain frames that we would get to in the future, so that I would not forget the idea in my head. Once my team was ready to hop into prototyping, we went over this version, and started to create what would be our first prototype that we shared with users.
Progress on Version 2 of the prototype went really well. Our team was super eager to dive into prototyping the application and ended up getting a lot more done than we had assumed we would be able to through the week. We put more focus in the conceptual ideas rather than having a functioning prototype this week. We wanted to see how people would react to the different features that would be provided rather than focusing on making each individual component being functional. This would allow us to gather information on where things need to be located and if they were comfortable knowing what each feature would do. A great example of this would have been the tracker. We wanted to test what users would recognize as the tracker, how it would showcase their intake levels for the day, as well as how they would go about adding to the number. Located below are examples of frames that were shown during user testing.
For user interviews, each week we had three interviewees lined up. Depending on which team member scheduled the interview, would moderate it, being as the interviewee would be more comfortable talking directly to them, rather than having one person moderate every interview. This also gave all of us practice leading interviews. While in the interview, we all took notes on FigJam over key points talked about, and after the interview process was over we went through and created affinity maps. This allowed us to group together similar things we all picked up on and how to move forward in the future. The beginning of the interviews started with general questions about who they are, their activity levels, and general day to day hydration, and other information like that. After the general questions were completed, we would move the interviewee into the prototype and guide them through it, without asking leading questions. This provided us with insight as to how they would navigate the application on their own, without guidance from us.
Week 2: Prototyping/User Testing
Moving into week 2 of the sprint, we gathered all of the feedback we had received during the user interviews in the prior week, and decided what we were going to focus on before the next round of interviews. We stayed within the same version of the prototype we had, and just refined things that were noticed by our users. We wanted to showcase the same relative idea to the next round of interviewers with the improvements, to see if they had noticed anything different compared to the last round. The prototype was relatively the same with some minor revisions made. This was a lighter week of development as we had already made more progress than we had thought we would have made within the first week.
Due to the nature of this being a class project, and team members having other responsibilities, our stand-ups were held in two day intervals rather than daily, and at the end of the week we held a retrospective for the entirety of the week. The retrospective was a time we shared as a team to go over what we thought had gone well, and what we could improve on in the next sprint. It was a way for everyone's ideas to be shared, and to make sure we are all on the same page with the next sprint coming up soon.
Sprint 2
Week 0: Design
Being as we have already solidified the foundation of our app and started prototyping the application, this week of design was spent focusing on revalidation of our made assumptions. One of the main things that is involved within this is going over our Proto-Personas again. Being that the people we have been interviewing have been relatively younger, we had not come across anyone with any medical issues that were forcing them to have a set hydration level. With this, we decided to negate that Proto-Persona, and focus more on the other two we had created. This allowed us to shave off focusing on edge cases that wouldn't be the majority of the userbase. In order to revalidate all of our prior thoughts, the FigJam board was copied over. This caused us to go through all of the information we had already written down, and verify all of it was still true to what we now knew. Any edits made to that are shown on the full FigJam file provided at the top of the page.
As standard procedure within Lean UX, we created a product backlog. This provided us with a visual of what had been completed, what is in progress, and what needed to be completed before specific deadlines. This ensures the whole team is on the same page, knowing what they need to be working on, versus what has already been marked as completed. All in all, saving back and forth between team members and saving everyone some time.
Week 1: Prototyping/User Testing
A lot of the feedback we had received during the interviews during the first sprint was that our app seemed to cold and clinical. Users didn't feel a warm welcoming sensation when using the app that would draw them in and keep their interest. To combat this, this first prototyping week was focused on making the app feel more welcoming, and less like something that would be used in clinical situation. This week we decided it would be a smart idea to interview the same people as we did Week 1 of the previous sprint. This allowed us to show the changes made to people that have already seen the application and if it made their experience any better. We went through our interview prompts and changed them in order to focus more on the changes made rather than the application as a whole. We believe this would give us more valuable information than people who had no prior experience
Week 2: Prototyping/User Testing
The results from the interviews in the previous week were a resounding yes on the new look. With this new information, we focused on the branding being consistent throughout the prototype. Majority of the functionality was already completed at this point, so this week was predominately visual based work. Like Week 1, we went back and grabbed all the users we interviewed in Week 2 of Sprint 1. We ended up getting the same feedback as the previous week, furthering our goal of focusing on branding.
Refinement
With the conclusion of our two total sprints, next came the process of refinement. For this course, we were allotted a weeks time to go through and polish the prototype. We met as a team and went through the file with a fine tooth comb. This involved checking the margins on every frame, ensuring all the functionality was correct, and making sure everything felt right. This wasn't a painful process as we used the incorporated style guides on Figma to make sure that everything was cohesive. We also followed a layout grid so that when we created the frames originally, they were already following consistent margins. Throughout this process, we came across a few small things, but nothing major. After all was said and done, as a team we felt that we had created a polished project, ready to showcase to our class.
Conclusion
Overall, I am super pleased with our team and how our project turned out. I believe we showed a strong understanding of the Lean UX design method, and delivered a polished prototype given the time constraints of a school project. We worked well as a team, were able to finish everything before deadlines, and had fun while doing so. The only challenge I believe we faced was a lot of our work being asynchronous. While this didn't cause a lot of issues, it caused a lot of time to be used to catch team member up on what we each had done during separate times, or occasional miscommunications about what we were going for. This was more of a issue at the beginning of the project. As the semester continued, we became better at communicating with each other and worked through the different schedules we all had. We didn't have any glaring issues throughout our sprints other than small things like our ideas not working out, or struggling to get certain things functional with Figma's constraints and capabilities. A few changes we ended up making due to the user interviews include, the overall style of the application, the display of the tracker, and the navigation bar went through a few iterations.
If given the chance to go back and redo the project, I would only change a few things. The first would be to reinforce the idea of super open communication right from the start, rather than us learning to communicate better near the end. This would save us time from having to go back and forth and we would all know what is currently happening. Another thing I would have done different is the users chosen for interviews. We noticed that a lot of the users we interviewed tended to be on the younger side. This caused our Proto-Personas to be a little skewed. I believe if we had a larger variance in the age ranges, we would have received more valuable information across the board. I do however really enjoy the process we went through with redoing the same people each sprint to get feedback on the changes we made between the sprints, so I would keep that the same, just involve more users.
All in all, I had a great experience growing with my team and a lot of fun creating this prototype together, and I'm excited to see all of our further progression
Tyler Eckert
User Experience Designer
Product Management
in/tylermeckert/
tylereckert03@gmail.com
.jpg)
.jpg)
.jpg)
