UX Case Study: School Project 2

Abide App for Android: Live Better with Roommates

Obligatory pop culture reference

WARNING: This case study is very long and tedious—it was one of my first. Instead of rewriting it, I’m working on newer projects that will actually be built. Instead of deleting it, I’m leaving it up because I’m proud of the effort and result.

This is a case study and reflection of a three-week team design challenge while attending the immersive UX program at DevMoutain.

My team did a great job on this project. Although we each chose a different direction for the final visual design, those final steps would not have succeeded for me without all the patience and detailed work we put in together at the beginning—especially with the story maps. Thanks guys!

The Team

Evan Gardner (me), Brandon Chappell, and Matt Gummow

The Challenge: Better Roommates

  1. Design a mobile product experience that appeals to young single professionals looking for a safe way to find roommates in any city.
  2. Also, consider what this product can do to make the roommate experience better over the long-term.

Spoiler Alert: Our final product only addresses the second part. Research suggested that improving any roommate relationship was a better opportunity than trying to find the one “perfect” roommate.

Five Stages of Our UX Design

Our process for this project focused a lot on the early research and thorough ideation. That strong foundation helped us with good ideas through design iterations and paid off with very positive user tests.

The final steps of the visual design were done individually to showcase our unique takes on the project. Because of the solid insights we already understood, I was able to take on a very challenging design direction that taught me a lot.

This case study is broken down into five main sections

  1. Breaking Assumptions Through Research
  2. Analyze Opportunities
  3. Project Scope and Compromise
  4. Design Iterations and Information Architecture
  5. Visual Design Challenge

1. Breaking Assumptions Through Research

Initial Research — Finding Smart vs Living Well

During our first meeting as a team, we laid out everything we knew, or thought we knew, about roommates. We also identified potential people to interview that might provide good insights. It was a good way to jump-start our thinking and direct our research.

Why is it that the first idea people have about how to find good roommates is using an algorithm but the last place they want to look is a website?

My first step in the research was an attempt to digest everything Google could provide on roommates — where to find them, how to pick a good one, how to live with difficult ones and how I can be a good roommate to others. 40 or so articles later and all the info seemed to condense around the same five principles. From those principles, each article tried to add a unique insight or approach. Below are the five main themes:

  • Where to Find - There are already plenty of places to find roommates —online and offline…
  • How To Choose - Interview multiple candidates before choosing, be detailed.
  • Be Safe - Run background checks and meet in public spaces.
  • Set Expectations - Communicate and set reasonable house rules early.
  • Be Clean - Negotiate a cleaning schedule that everyone agrees on.

As we considered these insights we divided our project into two distinct user goals: “Finding Smart” and “Living Well.” Eventually, we decided these two had different enough workflows that they would be better off as separate apps. Still, we kept the “Finding Smart” features in our story map late into the design process to help us remember the proper context around our app.

Survey and Interviews

For our survey, we wanted to understand a little more about people’s experiences with their roommates. We wanted to know how they ended up together, what made the best experiences good and what made the worst experiences so bad. We also wanted to verify the value of setting house rules and cleaning schedules.

Interviews became even more important because our survey questions focused on only the best and worst experiences. We used these interviews to understand more about the roommates that fell somewhere in between. We also probed for more details on what made for good roommates and how to improve bad relationships.

What I saw were a lot of missed opportunities as many people expressed a desire to be more deliberate and organized. They had some understanding of what they should do but rarely took the time to do their due diligence.

“We had a loose set of house rules. More clearly defined house rules would have helped a lot more, I think.” — Survey

As we discussed these findings as a team I began to advocate for a solution to help each roommate be their best. A big part of that went back to establishing a shared common ground that set clear expectations and fostered better communication around trouble areas.

2. Analyze Opportunities


We built our persona around the long-term roommates we had talked to in our interviews and Carrie became our stand-in for many of the decisions we had to make. This was especially important as we developed our information architecture and prioritized information on the dashboard.

As the homeowner, Carrie is driven to take ownership of every roommate interaction. We also wanted the app to be useful for a primary renter who wants to take control as roommates come and go.

Stress Testing our User Story Map

With our persona completed, we chose a particularly ugly wall and began covering it up with sticky notes.

We organized our story map around Carrie’s complete journey of finding, choosing, living and even letting go of a roommate but spent most of our focus on only three areas. By including the whole journey, we could consider how app onboarding would flow no matter where in the process it began.

The three primary activities (or user goals) ultimately ended up as:

  • Onboarding
  • Living Well
  • Management (including settings)

While the first version took a few days to get settled, we continued to make adjustments all along. I even invited a few outside people to look it over and challenge us on our thinking. This focus and stress testing helped us develop a tight set of features and a very thorough understanding of each.

I really enjoy this part of the process —the teamwork, thinking creatively, defining strategy and then stress-testing to make sure it holds up against our research and constraints.

With the total project laid out on our wall for easy reference, it played an important part of keeping everyone unified on what our goals were throughout the rest of the project. It also helped us divide the work in ways that made sense.

3. Compromise and Building

Once we began to feel pretty confident in our story map we looked at what features were most essential. Since development wasn’t a constraint for us, a few features stayed in our feature set to present a more complete vision of the app’s potential.

Cutting Out “Find Smart”

As I mentioned before, we held onto features that helped find roommates in our story map even though we didn’t expect to keep them around. It was at this point we finally pulled all finding features from our designs. We did see potential in this area but decided to save that project for the future.

Most other features stayed — credit to our very thorough discussions early on.

Message Board and Digital Keys

There were two features that had been questionable draft picks for the first round — messaging and digital keys. We decided that a simple public message system could be integrated into system notifications. Digital key management was also pretty easy to integrate and was a step in the door for future home automation features.

“One day he just skipped out. He even took my big coin jar…We had to pay to rekey all the locks.” — Interview

Feature Complete and Profitable

Ultimately, we recognized bill payment and roommate management as the biggest draw for users. House rules, chore lists, and messages are tough sells on their own but make for very valuable second tier features.

It’s kind of like sneaking in spinach to a fruit smoothy.

To make the app profitable, we envision it as free app with a subscription upgrade. Allowing free access to all the features needed to manage the home and roommates lets the user try out and set up everything needed.

Subscribing for $10/month allows other roommates to sign in and connect. This opens up easy in-app payments and payment histories, messages, and digital lock management. Making it safe and easy to pay rent is our main driver for subscriptions.

NOTE: Though we considered what would be needed for the roommates, we only designed the fuller version of the app for the main, managing roommate.

Ultimately, our app focused on the following five key parts, listed by usage priority:

  • Money management (including in-app payments, rent and utility tools)
  • Roommate profiles (including contact info, payment histories and digital key management)
  • Chore list with automated rotations
  • Message center (simplified, public message board)
  • House rules viewer
Abide is a free app with a $10 subscription which enables easy sharing with roommates.

Information Architecture

In organizing our features, we decided on the app opening to a main dashboard for a quick overview. Navigation to other features would be available through a bottom tab bar.

With a limit of five destinations provided by the tab bar, we hid the house rules in the settings to open a spot for the home dashboard. We assumed that house rules would be the least accessed and, ideally, printed and posted somewhere in the home.

Figuring out navigation. Five key landing pages, each only one click away at any point through a tab bar.

Our main destination pages were as follows:

  • Home Dashboard
  • Roommate Profiles — current and former (including Current payment details, payment histories, digital key, emergency contact info)
  • Complete Billing Details (for managing roommate view only)
  • Chore List (automated rotations with views for next and previous weeks)
  • Messages (combined app notifications and roommate message board)
  • Settings Menu (including the House Rules)

As we began our 10x10 sketches we split responsibility for each of the sections. Each section had two team members assigned to it except the dashboard. Because of the dashboard’s importance, everyone contributed ideas toward it. I was responsible for the Billing, Chore List and Settings.

Dashboard Difficulties

For the dashboard, we initially had decided to include roommate payments and an input for monthly utilities. We went back and forth several times over the next few days and even tried to get some insight through user testing-though it was inconclusive.

I was an advocate for including the utilities in the dashboard as I considered it the feature most in need of regular attention. Eventually I was outvoted and I focused on making utility input a priority section on the billing page — one tap away from the dashboard.

After the app is set up, the only input needed to keep the system working is the timely input of monthly utilities. I prioritized simplifying that process above all else.

I held out hope that as we moved to higher fidelity designs we could still include the utilities in the dashboard in some way.

4. Design Iterations

User Testing a Prototype

When building our testable demo, we included real(ish) numbers and info so that we could test around specific tasks. These tasks included:

  • Finding how much a roommate roommates owes for the current month
  • How much another roommate paid last month
  • Whose turn is it to clean the hall bathroom next week
  • Printing a copy of the house rules
  • Notify all the roommates of when the plumber would arrive
  • Entering the gas bill

Our testing results were pretty positive. Unfortunately for me, they were still vague on the best placement of the utility entry. My suspicion was that the idea still wasn’t being evaluated in the right context. Potentially, at the higher fidelity stages the problem with focusing too much on what the roommates owe would become more apparent and we could reevaluate it then.

What became very clear was that our app worked really well, overall. Our time spent on the early story map was paying off. The testers were impressed overall and only stumbled over some little things we felt we could address through wording and visual hierarchy.

One pattern we noticed was that for all the roommate tasks, users went back to the home screen and tried tapping on the roommate names instead of using the bottom tab bar. That didn’t seem to be a problem if we made that part of the dashboard a link, but it did influence a later decision to fully reimagine the dashboard.

Removing the Tab Bar

With the positive results from the user testing we began to look at higher fidelity designs. We opened a collaborative mood board for colors and design ideas. We were concerned with the prominence of the text and square boxes and were looking for ways to break it up with color, shapes and animations.

One of the samples we liked was a card-based dashboard without a tab bar I found on Dribbble. It had some nice colors and subtle gradients that we started testing in our builds. We also considered adding profile pictures.

With this new direction, we looked at getting rid of the tab bar for navigation and having all navigation go through tapping relevant cards. This meant we had to include a card for every main feature on the dashboard.

Design Inspiration from Dribble

I was hesitant about changing something so drastically that had already tested really well. That was a change that would need to be tested and we were running short on time.

We had already planned on splitting off onto our own final designs and this point marked a good point to take what we had learned and finish on our own intuition.

5. Visual Design

From the HIG to Material.io

Up to this point, I had been referencing Apple’s Human Interface Guidelines while building some of my screens to make sure I had consistent interactions. I ran into problems with finding an input method I liked for the utilities and went to Dribbble for some inspiration.

I saw some potential with what I attributed to Material Design and that tipped me over the edge for the transition. Unfortunately, what I had seen was only a custom interpretation of Material Design and I didn’t realize my mistake until I had already committed to a very strict redesign of the whole app.

The switch to Material became a huge rabbit hole that sucked me in for days with sporadic unanticipated insights that made me rethink almost every aspect of the app.

Trying to fit the features into Google’s design language was a huge headache and a lot to learn in a very short amount of time. Sticking to such a strict guideline was extremely frustrating but somehow felt worthwhile as an exercise and learning opportunity.

Unfortunately, with so much to learn, I didn’t have time to fully test the new organization of the app. I had to rely mostly on the intuitive understanding gained from all our research efforts. As many problems as I had with Material Design, it did help me find the final answer I needed for the dashboard.

What’s in a Name?

In the middle of the redesign, I took a break to work on the app naming problem we had —our working title was “Chum” and it was creating a lot of weird looks from people…

Spurred by an idea while talking with my wife, I spend some time on an online thesaurus and stumbled across “abide.” It had a good tone and meaning, it was unique, and even had a beautiful symmetry that made for a nice word logo.

Merriam-Webster Dictionary

Even though our team had split directions by now, we still ran a lot of ideas back and forth. I shared the name and concept logo with them and they were excited for something better.

Brute Force Design

While working through my designs I had the desire to hold close to established conventions around interactions and interface elements. The idea was that if I could keep early designs pretty standard, than adding the fancier flourishes later would help with development time and cost — maybe like a storyteller, knowing just when to (sparingly) break the language rules to magnify impact.

First, I had to better understand the rules. Because Google had laid them out so thoroughly, Material.io became my rulebook for this project.

I quickly discovered how much I had taken for granted before and began a long slog understanding how every pixel interacted with the next. The biggest challenge was understanding the right interaction concepts — what really is a “card” and what kind of interactions are allowed within it? — then fitting my project within those constraints.

In what I initially supposed would be a simple act of color-by-numbers design, I was forced to brutally consider what my priorities were for everything in the app.

The final piece of the design puzzle came together through the typography. By not using any pictures, the typography had to really work. Figuring out how to make the dashboard look good required me to really understand what users wanted.

Talking again with a few of the people I had interviewed helped solidify the hierarchy and identify the single most important aspect of each feature.

The solution is only as good as the understanding of the problem.

The result is a pixel perfect Material Design version (as far as I know so far…) of the app that I am very proud of. All the later struggles really benefited from the work we put in early to deeply understand what our research was telling us.

Dashboard views showing common notification changes over time.

Showing it Off

Showing off the completed screens got a very positive response from just about everyone. Feature-wise and organizationally, it seemed like a solid offering and the design feedback was very flattering and welcome.

This was a fun challenge to work on and our team was really excited about the final results. Because of depth of many of our discussions, several early drafts of this case study topped over five thousand words (over a 20-minute read!), so please feel free to ask me about any aspect of this app — I’d love to tell you more about it.

If you want, leave a comment below or reach out directly!

User experience and design thinking professional. Curious—with a love for technology, the social sciences and understanding nuance in counter-intuitive ideas.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store