I can bet that anyone who has lived with roommates has found pain points in their cohabitation. It makes sense! Two or more people who grew up in different households with different cultures, rules, ways of communication, etc., coming together and meshing their lives under one roof.. of course there would be challenges! With this in mind, I worked with three other UX designers to design a product that would help roommates get on the same page. We considered task check lists, task reminders, personal libraries, and a bill splitter, but after research we found that most roommates needed an application that would help track chores, break down bills, and set house rules.
When my team first got together we set a calendar schedule with weekly goals leading up until the due date. We had approximately six weeks from discovery to high fidelity prototype, and we wanted to spend our last 3 weeks primarily focused on user testing (along with user testing throughout). We did this because we wanted time to test, make iterations, test again, make another iteration, etc. until we simply ran out of time or until our product lacked major user pain points.
Define
When my team first got together we knew that cohabitation was difficult among roommates, but we didn’t know the specific pain points. First we defined what we knew, then discussed what we wanted to know more, then used both to guide our research.
To find answers to our assumptions and questions and validate what we already knew, we set out on the task of research. We sent out a survey to all of our networks and were able to pull in around 100 responses. In addition, we interviewed multiple people to hear first hand unique personal experiences.
The interviews were great in verifying the information we found in the surveys. The surveys were perfect for quantitative data, but the surveys allowed us to gather qualitative data that we would not have found elsewhere. In interviews is where we discovered WHY the users made the choices they made and felt the way the felt.
We gathered a wide variety of pain points, but three that repeated with almost every user were communication in setting boundaries or rules, an even assignment of chores, and a transparent breakdown of bills.
We also tried out other “roommate” type apps, but found that they were either stress-inducing by the chaos of colors, or they lacked necessary features. We wanted our users to use our mobile app and have all major pain points addressed.
With that, our persona was born.
Persona
Meet Stephanie Brown, a young professional living with roommates and frustrated by the lack of communication, chore delegation, and the confusion behind splitting bills.
Stephanie was on the forefront of our minds throughout all of the design and testing.
User Journey Map
Knowing the three key features (house rules, chore chart, and bill breakdown), we wrote out our journey map. We knew the users needed a place to login and see, create, and share activities with roommates in order for everyone to be held accountable, so after user on-boarding we led users to a “user home,” or dashboard. From the dashboard users are able to add house rules, add and delegate chores, and add and see a breakdown of the bills. Within the bill breakdown, users were also able to charge and pay each other. We added the payment feature to keep users within the app, rather than forcing them to go to another app and return upon completion.
From dashboard to completion of task, users are never more than three clicks deep. My team set a goal to design an app that addressed the three key features but had one really awesome, well designed aspect, but we delegated parts of the product in such a way that the whole thing came together really well. I took ownership over the Chore Chart, and it was so fun to take it sketches to prototype.
Sketches
Starting with lo-fi sketches, my goal was to throw as many ideas onto the page as I possibly could, then work with my team in designing a layout that would flow consistently with their features. Key aspects of the chore chart included the ability to add a new chore, then select which roommate(s) to which it was assigned, pick a start date, whether or not they wanted it to repeat, and if so, how often, then also set a reminder.
Once my team and I decided a rough sketch layout, I moved to Sketch to create wireframes. This part of the process is always so fun for me. I love seeing rough hand-drawn sketches start to come to life with true shapes and copy. My ideas behind the content stayed the same, but user testing showed that “Frequency” needed to be changed to “Repeat,” as you will see in the high fidelity prototype below. Under repeat, the selections also changed to show less upon the first click. I was inspired by the Alarm feature on the iPhone, with certain changes to reflect a chore chart.
One noticeable thing with my low fidelity wireframes is there was no way to return to the dashboard. My group went back and forth regarding adding a footer plus a FAB(as displayed in the yellow Chores wireframe below) that would allow users to move around the application quickly and access every other part with one click. Our decision was difficult because we knew we were mixing different parts of Material Design and HIG, but we also wanted to maintain our goal keeping everything three clicks deep and easy to navigate.
We did a small amount of user testing that suggested some sort of FAB was necessary, but it wasn’t until we did a LOT of user testing with unfamiliar users after prototyping that we decided to make it a permanent part of the application.
My team member Fernanda created a UI kit for us to use. Having the UI kit early on in our process was amazing because it kept our designs consistent despite all having different features! One bit of feedback we received early on in a design review was to keep the background white and only use the colors as accents. In the end we decided to feature only two colors, as shown in our prototype, to keep the theme consistent. We decided to stick with blue and salmon, as both colors made users feel calm and organized.
Protoype
Our prototype came together nicely, partly due to the consistent UI among the different features! I did all of the prototyping using InVision.
Upon opening the application, a user would onboard, first by either adding themself to a house or creating their own house (then inviting others). They would then be led to their dashboard/profile where they would see notifications informing them of payments owed to roommates, a summary of bills, and upcoming chores to be completed. They would also be able to mark that they finished a chore in the dashboard.
From the dashboard, users could navigate to House Rules, Chores, Payments, or click on the FAB, which would pop up the option to create a new rule, chore, or payment.
The first two screens above display how a user would add a new chore, then move through the options to designate a roommate, select a start date and how often they want it repeated, then set a reminder.
The screens below show that a user has created three chores: sweep, take out trash, and wash dishes. If they were to click “sweep,” it would drop down to show all the selections previously made in the add/edit mode.
One thing that we tested frequently were the buttons. We found that users needed a consistent text button color in order to know that it was a button, so we chose the blue-green to stick with our theme.
Conclusion
In the end, I am so proud of my team for pulling off our mobile application, Roomease. We had limited time, but through effective communication and TONS of user testing, we designed an application that was not only usable, but also helped users to change habits and improve their living situations.
I learned just how important user testing is. We debated back and forth over whether or not we needed to use the FAB but we received our answer once we started asking users. They wanted the fab and felt that the app was easier to navigate with it. User testing also helped us determine colors and buttons.
One of the difficulties with designing Roomease was when and how we would get users to utilize the app. Would the strict roommate force everyone else to sign up after tension had blown up past repair? Would the roommate responsible for paying rent require others to join as they moved in? Or would the app only thrive in a utopian society where all roommates had equal standards of cleanliness and ambition? Obviously not the last, but our target market would start with the roommate responsible for rent encouraging others to join upon move-in.
If we were to take this mobile application past MVP, our V2 would likely feature a rental management portal for rental managers to be able to communicate with tenants and for tenants to pay rent. This would encourage renters to use our app upon move-in.
In the end, I am confident that Roomease would alleviate common roommate pain points, specifically problems regarding house rules and communication, chore delegation, and breakdown of bills. If I could summarize the project in two words they would be:
