The ask: Create a mobile app experience which makes it easier for people who are splitting expenses to manage the hassle of settling the bill.


Mission Statement

When I came on board, the team was missing some key tools needed to keep our design decisions user centric. We needed to do a bit of catching up, so we kicked it off by working together to create a mission statement.




Next the team crafted a few personas, we had fun brainstorming. I facilitated, using the 4 quarters method with a focus on wants and needs.




I also facilitated an exercise to create aligned goals. We talked about what we saw as business goals and user goals, and looked at how they aligned. This was helpful in making sure the product we were making made viable sense.


Top Use Cases


We also decided on some high level use cases: 1) Splitting an expense once. 2) Edit a prior expenses & adding to it. 3) Adding several expenses at once. We decided on these based on our empathy research. When we talked to our target audience we learned these were the high level use cases.


Take A Break From Sprinting

We decided to take a break from our sprints and do a quick audit of what we currently had. We printed out each screen and built the flows on the wall. This way the team could look at the product holistically. From there we worked together to map our new personas and goals to the existing and future feature list. We took off any features that weren't servicing our goals, plus we made decisions about which flows we should work on and test with users.


User Testing


We started a cadence of 2 week design sprints that included user research. (Design stayed 2 sprints ahead of the engineers.) There were also 2 tracks. The "big rocks", and the "small rocks". The big rocks consist of a new flow or feature that need a "gut check" with users several times before moving it into grooming. We would put printouts or clickable prototypes in front of a minimum of 5 users and look for patterns around what was working and what wasn't. If we had time we would iterate and test it again with 5 new users. Small rocks consist of new discoveries or unknowns that were missed or need immediate attention.


Design Track 1


Track 1 would handle areas where we had the most questions or unknowns. We would share these ideas both with users, and then later with the engineering team during a "pre" grooming session. This allowed us to give the team a heads up of what we were "gut checking" so they knew what might come their way but it was not part of the backlog yet. Another benefit of working this way was the design team could get input from engineering early, and it allowed the team to lead with user centric design.  


Design Track 2


Track 2 worked on supporting any questions or issues that came up while designs were being implemented by engineering. We would adjust the design if needed and make suggestions or improvements within the stories. 




Regular retrospectives helped us shift if we needed to, but mostly a great way for the team to bond and realign goals.


Example Of A Small Rock


The team decided the first use experience needed some tweaks. We had made sacrifices in order to get it shipped quickly, but now wanted to make improvements. So we kicked it off with a white board sketch session. This was high level. Together we determined what was possible this sprint. We referenced existing heuristics, then we got more specific with a wireframe of the proposed flow. Design screens were created by a visual designer, we used those to conduct a quick user test in a coffee shop using a paper prototype. Within a week, we moved it into grooming, stories and the backlog.


Examples Of Large Rocks

The proposed new friend feature affected several other features and screens which is why this was considered a big rock. We kicked it off with a white board session between the leads for each of the three disciplines (design, dev, product). Together we determined what we could do technically and what would be best for the user based on existing heuristics. We conducted some in person interviews with users using a clickable prototype, looked for patterns, and brainstormed solutions to any issues. We iterated, refined the design, did more in person interviews. We did this until we felt good about the approach. Eventually it moved into grooming, stories and the backlog.




The app lived in the Apple store for 3 months before it was decided by the leadership team that it wasn't a viable product for the business.