qPOP! Mobile App allows employees in the Quicken Family of Companies to quickly and simply report facilities issues via their smartphones.
The first thing we did was setup a workshop with the facilities support team. This gave us a chance to deep dive into what problems they were facing on a daily basis. One of the biggest issues for the facilities support team was the quality of ticket data. Both the type of issue and location of the issue on the support ticket.
We conducted two focus groups with five Quicken Loans employees each. The goal of these focus groups was to get feedback on the current work ticket submission process and to try and identify pain points for the user.
Our initial sketches were platform agnostic and focused mostly on the user experience and user flow based on the research and interviews we had completed. As we increased the fidelity of our prototype, we began using separate UI elements for android and IOS based on each platforms conventions and best practice’s.
Scenario #1: First-time user submits a popular ticket, without editing
Scenario #2: Returning user creates a new ticket
Scenario #3: Returning user re-submits an old ticket (& updates their floor)
Scenario #4: A new or returning user submits a phone call
Scenario #5: Returning user updates their info (i.e. phone #)
Scenario #6: Returning user submits a ticket from an unknown location
Scenario #7: Returning user submits a ticket w/ notes
Scenario #8: Returning user submits a ticket w/ a photo
We first tried solving the location issue by using GPS to track where the ticket was being sent from. We setup a test app where we quickly discovered the location data and the attitude data wasn’t as accurate as we had hoped. The Quicken loans campus is spread out among 15+ buildings in downtown Detroit all occupying varies floors and spaces so location/ altitude were important for determining location.
We then conducted research into Bluetooth beacon technology for indoor wayfinding. Bluetooth beacons send out information to any phone in its vicinity. With this method we were able to detect whenever the app came in range of beacon. The biggest caveat to this method was making sure it could scale to all of the Quicken Loans locations as it requires a beacon for every space. We decided we would stick the high usage areas mainly conference rooms and kitchens.
Now that we figured out how we were going to pin point the location of the ticket we moved on to how to incorporate it into the UI of the app. We decided to use the home page as the place where we would first show the user their location if we detected it. If the user submits a ticket while in range of the beacon the building, floor and location fields will auto populate with the location data.
One of the issues that came out our workshop with the facilities support team was the way different issues were described from user to user. This caused a number of issues on their end, so we looked for ways to standardize the way issues were described by users. Our solution was a quick tickets section that lists the most common issues. When the issue was tapped the ticket was pre-populated with the issue title. In our user testing we found that users were using the quick tickets 80% of the time as opposed to creating a custom ticket. This made the tickets easy to categorize and understand for the facilities support team on the other side of the ticket but also gave the user the education on what types of issues the facilities team can assist with.
During our initial user interviews the concept of real time ticket tracking came up with both focus groups. Having transparency and visibility was important to the user. We did research into the current ticketing system the facilities team was using to see if we could communicate with our app. Unfortunately, the current ticketing system API did not support this two-way communication with the app. We considered building a secondary system to track ticket progress but adding another application for the already extremely busy facilities technician would not deliver a great experience for the technician or the user.
We knew we wanted a way to save some common information that could be used in other areas of the app. We thought about creating a user name and password account feature. We wanted to keep things simple from an implementation standpoint and from the users perspective. Making the user create another login separate from their company SSO would not be a great experience. We decided that we would prompt the user with a simple profile to fill out the first time they open the app instead of creating an account. This profile data would then be saved locally to the device.
After the initial sketches/wireframe, we began to focus on the specific UI requirements for working in IOS and Android. Because we were building an IOS and an android app, we wanted each version of the app to share the same visual language but follow the best practices and conventions specific to each platform.
The IOS version uses a tab bar at the bottom for navigation and features a "create a ticket" icon in the top right corner following the IOS guidelines and common convention. The android version follows the material design framework, which means its "create ticket" icon is floating between the quick tickets and the location display.
2,000+ downloads of IOS/Android Versions in first 3 months.
Although we had initial success when launching the app, we quickly ran into issues because of the way the app needed to be distributed. The app was needed to be downloaded from our internal site and not an internal app store or one of the official app stores. This meant we couldn't push updates to the app without requiring everyone to head back to the site and re-download the APK. When designing a service, app, or website is important not only to think about the product, but also think about the experience for users to obtain or maintain the product.
Interested in working together?
Send me an email at email@example.com