It all starts with a problem.
While talking with family members about the UI & UX for Digital Product Design course I was taking at NSS, I mentioned that our focus in class would be to complete a front to back UI & UX work through of a “ticket buying” issue that was to be of our choosing (a capstone project).
My mother immediately told me about her friend Robin, who was having a terrible time getting tickets to concerts, sporting events, and other happenings. Robin is recently handicapped and must now use a wheelchair. The wheelchair isn’t really her problem in this story: every time Robin wants to buy handicap accessible tickets, she must either call in to the ticketing companies ticketing phone number(the general purpose ticketing line – not a distinct line for the handicapped community), or log in to their website and fill out a form to later receive a call back from the ticket seller.
These pathways generally lead to Robin having great difficulty or outright failure in getting the tickets she terribly wants. I thought this sounded like an issue that was begging for improvement if not an outright solution. I’m not going to honestly say I’ve provided either here, but I poured all of my effort into trying to help. The end result is an app/site/account add on that I call “AccessAble.”
AccessAble is intended to minimize the repeated trouble that the handicapped community faces when buying tickets: the telephone “verification.”
AccessAble – A User Experience Case Study
I began by trying to refine what the real problem was. A true problem statement should reflect what the true issue is, not what the researcher, the affected, or the vested parties tell you the issue is. After a short interview with Robin, a case drawing, and some initial persona sketches, I feel confident with the following problem statement:
How can we improve the process of ticket sales to the Handicap Community and their loved ones?
With this statement, I moved forward and further fleshed out the personas and completed a heuristic evaluation of competitors (as unlikely/ingrained as they may be) along with a set of SWOT observations for the main competitors. I discovered that most ticketing companies, including local venues, handled the tickets for the handicap community over the phone (or in person, but more rarely). This seems rather time consuming and “analog” on everyones part in an age where a digital path is the norm, on top of the fact that personal interaction can be costly. While not strictly applicable to my problem, this is an interesting finding that could help possibly inspire the ticketing agents to take action for the cost savings if not just for the good will.
When working with the personas, I felt that they perceived the repeated touchpoints with the ticketing agent to be exhausting. They also indicated that the fact that their ticketing experience was different at all from non-handicapped customers was upsetting, and couldn’t understand the need for a person-to-person interaction rather than the all digital paths (Smartphone app or computer). The loss of control over their schedules due to the “call-back” method most ticketers use, was troubling as well: having to wait for an operator in a phone center to call them back when they have busy schedules of their own on top of added mobility difficulties felt inconsiderate and added to their stress levels.
Draw It and Iterate
I continued to make my way through the information I was collecting and after a few paper sketches and feedback from my colleagues; I started to put together a paper “low fidelity” mockup of the app add-on I had been distilling in my head. Almost immediately I came up with the name “AccessAble.” I like that it plays on both base words and is just one letter away from the true spelling.
Initially I wanted to incorporate a small icon directly into the search bar or add a swipe left or right to play off already utilized interaction within the app (I decided to work within the TicketMaster app), but rather decided to add the whole “add-on” within the settings area of the app, and make it an opt in addition to the application.
The Low Fidelity Prototype
The low fidelity prototype I made helped me to really think out the steps I needed and to whittle out the things I didn’t. Would it have been nice to be able to coordinate travel arrangements? Yes. WAY beyond the scope I needed. Did I need to “locate” AccessAble within the App user settings or just outside of it with the other app choices? I decided to put it outside the user settings, as not everyone needs this functionality and it made more sense to me to have it where “Location,” “About,” and more lower upper level choices are made. I tested this with a few volunteers, and they agreed. Although I don’t know that this decision is really all that important to the user pathway, it is a decision I like.
Here is a sped up version of my low fidelity “AccessAble” prototype walkthrough. For a regular speed version click here.
The High Fidelity Prototype
I created the high fidelity prototype for AccessAble using Justinmind Prototyper. Using what I learned with my paper prototype made creating the high fidelity version so much easier and I saw first hand why taking the time to “show my work” paid off. Initially I thought the low fidelity version seemed like a waste of time “when I could be just making the damn thing already!” I fully appreciate this step now.
Here is a high speed run through of my prototype. If you would like to see the full video click here.
I am very proud of how everything turned out. I feel like this case study has inspired me to continue onward to making AccessAble a “real thing” and I will more than likely be incorporating it into my Nashville Software School bootcamp experience: hopefully as one, if not both, of my capstone projects.