GrowUp provides an interactive tutorials to help young adults learn essential "adulting" skills that are often overlooked in traditional education, such as paying bills or changing a tire. This enhances their proficiency and confidence in handling real-world situations, and helps them feel more prepared.
UI Designer
Figma, FigJam, Google Docs, Teams, and Discord
September - November (8 Weeks)
Team Lead
Product Designer
UX Writer
UI Designer
We wanted to create a tool that would help young adults feel more prepared and better equipped for their transition into independent lives. As a team of young adults, we wanted to create an app that would be beneficial to us and our peers on our varying levels of independency. We began by brainstorming ideas and problems that we may not have been taught but problems that are vital to adult life. We explored varying problems from how to do laundry to how one would go about filing their taxes for the first time. From this reoccurring problem of confusion, we solidified the beginning foundations of GrowUp.
For this class project, our team used Lean UX, an adaptation of Scrum and Lean Startup. Lean UX helps to "bridge the speed of Agile and the need for design in the product-development life cycle" (Gothelf & Seiden, 24). This allowed our team to focus all our attention on the functionality of the app, without the heavy reports and documentation used in other design methods.
Our work in the beginning of the project was based entirely on assumptions made towards what the users would want. As our entire team fell within the target audience, we were able to use some personal insight into the problem to have some foundation for our assumptions. As we moved through testing, we confirmed or changed our assumptions to fit the needs of the users.
Our project was fit into two, three-week sprints. This fast-paced environment forced us to work quickly and prioritize the most important aspects of the application. We used one of these weeks to work through the business model for the project, or the Lean UX canvas, and listed our product and sprint backlogs to keep track of what we would be covering within the sprint. The next two weeks would ultimately cover specific features, and a minimum of six usability interviews per sprint.
For the first design sprint, our team focused on the foundations of our project: the UX Canvas and the research for our problem space. We completed the UX Canvas and used our created assumptions to build proto-personas that would take the place of who we assumed our idea user would be.
In Week Zero, our team focused on the Lean UX Canvas. The Lean UX Canvas organized the process that our team used tobrainstorm the basic assumptions and ideas of their application (Gothelf & Seiden, 76). With this, our team was able to have open communication with each other to work through many of the early start up problems of figuring out what our app would do, and what would make it stand out.
We took a lot time to form our hypotheses, trying to assume the most accurate information for our problem space. Hypotheses were formed by the format of "We will achieve [business outcome] if this user [proto-persona] can achieve [user outcome] with [feature]. "
These proto-personas were created to take the place of an actual user, giving us a potential user that would be using our application, based on the assumptions our team had formed.
Aanya is a very independent woman that has just recently moved out form her parent's home. She is now looking to make a life for herself, thriving in her newly independent life. She is extremely ambitious and wants to prove herself to doubtful parents that only want to help.
Shane lives to impress. However, he is willing to take the easiest path to a solution. He works to support himself through trade school and the needs of his girlfriend. He was well taken care of as a child, but sometimes spoiled and pampered, leaving him searching in his first few years on his own.
Beginning the design weeks, we gave ourselves less tasks to do in Sprint One to give us more time to figure out some basic design rules and themes that we wanted to stick to. These would help us stay cohesive with the wireframes and prototyping screens that we would be making.
We began the interviews in Week One with a questionnaire, collecting general interest about the app and exploring potential features that our target audience would want to see. This allowed us some early validation about the assumptions that we had formed in the previous week.
After the interview sessions we began building wireframes of the features we wanted to complete in Sprint One. The work was divided evenly amongst the team. Many of the design iterations we worked on this week were basic pages that we knew we would include regardless, such as the home and search pages. We focused heavily on A/B testing for these pages, trying to determine a layout that our users liked best. Some of our early testers complained about a lack of color, and while we explained that it was due to the low-fidelity state of the screens we decided to some small hints of color for the users.
Entering Week Two, our team was more warmed up to how a sprint worked and everything that needed to be accomplished within the last week. We turned our focus more to building screens and getting MVP's to the users on Thursday when we would test. Many of the screens made in this week were based upon feedback from the interview, and edited from the original designs we made in Week One. We also began making mockups of the different popups, overlays, and notifications that would be included in the final product. Both of our assumptions included reminders, and we wanted to test that hypothesis sooner rather than later.
After each interview, our team completed an affinity map. We would take notes during the interview, and then immediately afterwards list out the main points on sticky notes in FigJam. This allowed us to find commonalities in what we heard and list them as general points to take into consideration as we moved forwards.
At the end of the Sprint our team completed a Retrospective. We took this time to walk back through the work we had done, looking for any minor changes that we could make based upon the knowledge we had gathered from our usability tests with users.
We also evaluated ourselves as a team, taking time to go over what was working, what wasn't, and how we were going to fix those problem next time. We learned through this first Retrospective that we were still having trouble prioritizing tasks and making sure that everyone was on the same page when it came to our to-do list.
Moving forwards, we worked to fix this issue by creating to-do lists that were updated with every meeting that we had. Design comparisons between the team members became more frequent, and worked to improve our cohesiveness.
Moving into Sprint 2, our team moved our focus onto solving problems. We went through a process of revalidation, based on confirmed or disproven assumptions we collected throughout Sprint 1. This process gave us a clearer focus on how to design our application to cater towards our proto-personas and eventually our users.
The next design sprint was a repeat of what we did the first time through. However, this time we were much more familiar with the process and the speed that we needed to work at.
During this time, our team walked back through our Lean UX Canvas and went through a process of revalidation. Section by section, we walked through our sticky notes, outcomes, and hypotheses; comparing them against what we had learned in our interviews with users. This allowed us to confirm many of our assumptions, and remove several others to make sure that the users remained our main focus.
After revalidating our Canvas, we also went back over our proto-personas to revalidate them as well. However, as far as we were aware at this time, our personas were still accurate in their assumptions and few changes were made to them.
One of the main changes that took place within this sprint was the upheaval of our reward system. Many of our users said that a reward system would keep them returning, however they disagreed on how it should be handled. Formerly, we had assumed a "Trophy Room" would be enough for users, where they collect achievements based on varying principles and had a room to "showcase" them.
From our interviews however, many people brought up that rewards would be better, a way to track progress or even gain rewards. Based upon our business model, we did not want to include physical rewards as a part of the app, as there was not a feasible way to validate that people were truly completing tasks versus checking many things off all at once to get money out of it.
We did however change the achievements system into a leveling system that would give our users a visually appealing way to track their progress and share with their friends. This took several iterations throughout the Sprint, but we were finally able to achieve something that the users enjoyed and fit with our brand.
Once we had completed both Sprints, our team was given a final week to refine our product. We used this time to set a style guide, and I worked on aligning the screens to the iOS standards and an 8 point grid system. Our team decided collectively that we wanted to do a final usability test to confirm our assumptions made in our final UI refinement before submitting our project.
At the end of both Sprints, our team had a few weeks for final refinements. It was during this time that we solidified a style for our app, defining a color palette, typography, margins, and spacing. I took a heavy role in refining the layouts of the page and aligning them to the grids that we had established, running the final checks before we moved them into the space for the final prototype.
I also worked a lot with the tutorials themselves, writing the content for the steps and making the drop down tabs work properly. My main area was working with Auto Layout, Styles, Components, and Transition types.
Though not required for the class project, our team felt it necessary to do at least one final usability test on our application before submission. We contacted two of our former interview participants that were willing to go through the tasks again. This allowed us to find final details that needed fixing to end up with a better product overall.
GrowUp started as a simple instructional app, meant to teach young adults common tasks that may not have been taught at a younger age. By using Lean UX we were able to expand on the idea of "adulting," make it fun to learn these topics, and create something that would speak to our intended audience. In the end, our team produced a high-fidelity prototype that we are all proud of and worked hard on.
This project allowed me to practice Lean UX, helping to expand my skillset with different design methods. It helped me to think faster and more effectively about the design process and how to prioritize different tasks.
With no formal report to give us research, we had to rely on the information provided by our interview participants. This was invaluable information to us to help show just how important it is to design for users and how much information they can provide.
Though not required for the class project, our team felt it necessary to do at least one final usability test on our application before submission. We contacted two of our former interview participants that were willing to go through the tasks again. This allowed us to find final details that needed fixing to end up with a better product overall.
Final PrototypeOur team had the opportunity to learn several new skills that we can now utilize in our future work. Here are some of my key takeaways from this experience:
