Arts People Ticket Scanner
iOS app that scans patron tickets upon arrival to theatre's event
Role: UX/UI Designer
I work for a company that provides ticketing software to small venues around the nation. A large part of the ticketing industry revolves around the act of scanning patron tickets as they arrive to an event.
For years, my company relied on a third-party app that interfaced with our system. It wasn’t a perfect solution, but for a company with limited resources it served a purpose. Over time the app became outdated and unusable, which meant it was time we began investigating our own proprietary solution for users.
We found that roughly 180 clients relied on our system to check-in patrons to events. It was imperative that we release a product quickly to get clients up and running.
I connected with stakeholders to define the minimum viable product and gain clarity on the first iteration. These guidelines would help us stay on track in hopes of releasing an app in as little time as possible:
Minimum Viable Product Guidelines:
- User needs to be able to log in using existing login credentials
- User can scan a barcode
- Reflect scan success or failure
- If a failed scan, indicate reason
- Log out
- iOS only (develop for other platforms later)
Research & Planning
My research began with a few guiding questions:
1. What caused frustration with our previous scanning solution?
Our company’s Help Center contains over 110k requests from clients and is full of valuable data relating to our previous scanning solution.
A few common pain points:
- App setup was too confusing; required an involved setup guide.
- Camera scanner was too slow; required an external laser sled to increase speed.
- Outdated interface
The above items were areas I would place extra focus on when designing the app
2. How many performances do our clients have on average per day? How about per week?
Our database search queries let us know that most of our clients have 1 performance per day, as well as only 1 performance per week. This data would help inform the way our app presents available upcoming performances.
3. Are there any development limitations to be aware of?
I worked very closely with the acting developer on this project. We had daily check-ins and set a public timeline to help achieve our goals and hold us accountable.
It was decided that we’d utilize Ionic’s framework to create our app. This would not only allow us to produce an app in a shorter timeframe, it would also help us quickly release a version for other platforms down the road.
The Ionic framework did come with one design restraint:
In order to scan a barcode, the application would require a user action. This means it would be impossible to leave a camera open, offering continuous scanning. The user would need to tap a button in order to scan each new ticket.
UX Strategy Blueprint
- Create a design that facilitates fast scanning, considering the limitation with Ionic’s framework.
- Keep it easy and straightforward
- Scan tickets reliably in a variety of lighting situations.
- Let the user’s content be the star of the design. Clients spend time creating custom show images and logos to represent their company.
- Keep the minimum viable product guidelines in mind at all times. First iteration cannot afford “feature creep.”
- Number of returning users (using google analytics)
User Flows & Sketches
I began by creating a simple user flow for the app to outline the various user pathways:
Then I sketched a rough wireframe to get a better idea of component placement and process:
Using Sketch, I created hi-fi mockups for the first iteration and used InVision's Craft to prototype the mockup in preparation for user testing.
Testing & Iterations
I conducted in-person usability testing with 5 individuals. Testing didn't require any special equipment. I was able to setup a fully-functional user testing station with a MacBook Pro running the Reflector 2 app and Quicktime app. I also set up an iPad and an iPhone to record the user's hand movements and facial responses.
From this usability testing, I learned:
- The "X" icon used to indicate a failed scan was consistently misread as a button to clear the scan result.
- The graphic ticket on the login screen was distracting and drew too much attention.
- The "Scan" button wasn't placed ideally for left-handed users.
The testing proved there were some areas we could improve, so I set out to make the following changes:
- Instead of using a red "X" inside of a circle to indicate an unsuccessful scan, I investigated other options that would look less like an actionable button.
- Since there was plenty of space available, I decided to extend the "Scan" button across the bottom of the screen to make it reachable no matter the user's dominant hand.
- I decided to simplify the login screen to keep the focus on the action at hand: logging in.