Low Fidelity Mockups for the app

Reimburse: The design process behind the app

In November 2016, our team of 3 Information Systems majors came together to build an iOS app that we knew was going to add value to hundreds of Carnegie Mellon students, including ourselves.

All 3 of us held executive positions in at least one student organization at CMU and as part of our roles, we were required to fill out multiple reimbursement requests for expenses we incurred on behalf of our organizations. We all dreaded the current manual, paper-based system and instantly realized this was a huge area of opportunity for a mobile app.

I was the UX Designer and a developer for the project, and after we decided on a timeline for the coming 6 weeks, I began working on the design process for Reimburse, the app we wish we had ages ago.

The Current System

Student organizations host several events a year and also have different expenses to incur. In order to pay for these expenses, CMU allocates a certain amount of money to each organization every year. So, whenever a member of the organization wants to buy something using this budget, they must first pay for it using their own money and then fill out a reimbursement request. The CMU office of student activities (named SLICE) reviews these requests and sends checks to the senders if the request is approved.

SLICE office at Carnegie Mellon University

Students submitting requests need to fill out a long form, attach physical copies of their receipts to the form and submit it in person during work hours. (According to our research, this whole process can take an average of 5 working days.)

SLICE officers are always overwhelmed with reimbursement requests. There are 1000+ student organizations on campus, all of whom submit several reimbursement requests throughout the year. Larger organizations tend to submit about 100 different requests in a year, several of which are for large sums. This is the primary reason why it takes them so long (about 1–2 months) to process these paper requests.

The Design Process

I used Thai Lam’s fantastic article on his design process as a reference when planning out my own process. Knowing how much value a product like this would add to our potential user’s lives, I knew I had no room to cut corners in the design process.

User Research/Interviews

We identified 3 key users of this application:

  1. Students responsible for filling out reimbursement requests.
  2. Student leaders nominated as authorized signers. An organization can have up to 2 authorized signers at a time. A request must be signed by one authorized signer before it can be submitted to the SLICE office.
  3. SLICE officers. Members of the CMU administration responsible for checking all reimbursement requests for valid information. They have the final say in whether the request is approved or denied and are responsible for sending the checks to the students who submitted approved requests.

I interviewed 6 different users of varying roles and asked them to describe their process of handling reimbursement requests. I then asked what they liked and didn’t like about the current system and how challenging each step of their process was for them.


Armed with a deeper understanding of the users and their perspectives, I designed 3 different personas based on my notes from the interviews.

Identifying Pain Points

Unsurprisingly, all 6 users I interviewed shared our dread for the current system, but there were some common themes in all their complaints. Therefore, after some planning, I identified the following pain points:

  • Filling out and reviewing redundant paperwork is tedious and way too time-consuming
  • Its difficult to keep track of the paperwork since it changes hands so many times
  • Students often lose track of paper receipts, especially in larger organizations
  • The SLICE office hours often conflict with class times, so students often struggle to find time to submit requests

Based on this feedback and given that our personas are tech-savvy and always busy, we set out to make an app that would allow users to submit requests quickly and reliably. The design solution we came up with was focused on these 2 core ideas.

Our Vision

Our app turns the long, redundant paper-based system into a quick, mobile form that users can submit as soon as they have their receipts on hand.

It was immediately clear to us that the mobile space is perfect for this app. Not only does a mobile app allow users to submit requests quickly, it has all the tools they need to submit the request reliably. Using their mobile camera, users can submit a request within 5 minutes as soon as they have the receipts in their hand. A huge improvement over the the average 5 working days with the current system!

In order to ensure the information is as reliable as possible, we decided to use the APIs provided by CMU that contains basic information for all CMU students and organizations (name, CMU ID number, address, organization details). Since this information is provided by the university, we can be confident that it will be accurate, thereby drastically reducing the time SLICE officers need to spend fact-checking redundant details.

The 6 key features of the mobile app that make the reimbursement process quick and reliable, as promised.

Wireframes and Prototypes

I went through multiple design iterations involving paper and low fidelity wireframes. I did some quick A/B testing to determine which designs were the most intuitive and which most effectively reflect our goals for the app.

Final prototypes for the Member’s Dashboard
App color scheme

The app’s color scheme was inspired by the CMU Student Activities website, that already had a well-established color scheme. I wanted to keep things as consistent as possible.

User flow diagram for the proof-of-concept version of the app


By the time I was finished with designing the final prototypes of the app, the team had already begun developing some working back-end code. All we had to do now was incorporate the designs with the code as best as we could. It was all hands on deck for all of us. I was working with Swift, Xcode and Ruby on Rails.

Database for the Ruby on Rails API. It neatly stores all the information about the users, organizations and reimbursements, so they never have to submit the same data twice.

We linked the app to our Ruby on Rails API that is pre-populated with all the information about users and organizations, so users don’t need to supply this information themselves. It also stores the reimbursement-specific data that the user enters each time they submit a request.

The Results

We pitched our presentation to panel of designers and developers from Captial One. The panel consisted of recent graduates from CMU, many of whom had held leadership positions in student organizations. Like us, they all wish this app existed years ago. We were competing with 16 other teams but our app won the “Best Value for the CMU Community” award.

In 6 weeks, we managed to design, develop and test a working prototype showcasing the immense design potential for this app (and our iOS development skills). We then passed on our work to another Information Systems team so they could complete it during a semester-long project.

UI/UX Designer. App Developer. Board game geek.