General Assembly UXDI: P1 Retrospective
HOT FARES: A Rapid Prototyping Project by Nate Kushner
Introduction
In this project, I was tasked to discover a pain point related to my users’ travel experience. Through a series of user interviews, I identified an opportunity to make price-conscious fare shopping easier for a certain type of customer, and created a series of prototypes in an attempt to address the issue.
Initial Interviews
On the first day of research, I had 10-minute conversations with three different potential users in quick succession, taking notes on each, but also taking an audio recording for future reference.
Participant #1
Trying to ignore any personal pre-conceived pet peeves about my own personal travel experiences, especially after I had just unloaded them as Participant #1’s interviewee, I started the conversation with an open-ended question: “What are some places that you like to go on an out of town trips?”
From this interview, I learned about the subject’s experience as a semi-regular bus passenger, using one of a few competing carriers, including Greyhound, Megabus, and Boltbus, for frequent trips to Boston to visit her parents. Since these trips tended to be spontaneous and bought with 2–3 days’ notice, her continuing uncertainty about what kind of fare she’s about to pay, and her inability to check those fares in one place, was an obvious pain point that made the most sense to address. I still wanted and needed to confirm this with further interviews.
Participant #2
Though I started my second interview with the same opening question, this subject confirmed in an adjacent way that the opportunity was there, just by being someone who already has robust price checking resources for air travel that happened to be similar in intent to the bus-related ones I had begun to imagine, and gets spectacular results from using them.
Participant #3
I had begun to shape a problem I could solve, but didn’t want to be satisfied with two data points, and so I opened a third lengthy conversation with another interviewee. I used the same opening question, and it fortuitously led, once again, to stories about taking buses from New York to DC to visit her parents. Only at this point did I feel right in steering her conversation to questions related to the imagined bus fare app for the first participant, and confirmed that there was definitely an opportunity to help these two users with such adjacent needs.
I enjoyed this user interview process greatly, and though I know it will almost never be this easy again, still felt an immediate confirmation of the interview as a powerful research tool when done in a non-leading, open-ended way. I look forward to refining my technique further.
Initial Sketches
Once the opportunity was identified, along with some inspiration for a way to deliver the notifications that would make it effective, I started to sketch some initial concepts for what it would look like.
(left: first sketches of profile, standard search screen, results output. right: sketch exploring alert creation)
This was a little bit of a mess, of course, being an attempt only minutes removed from my first instruction in UX sketching, but it was illuminating. It was in the lower right-hand corner of the second page of sketching that I had the idea that became the “hot fares” alert.
My thoughts became a little more organized once I’d learned how to make user flows to organize the steps of a task. But those started out too ambitious and needed to be reigned in as well.
User Flows
The biggest difference in clarity came after a suggestion from Ryan to organize my ambitions for the options on the input screens somewhere other than in the user flow. With simplification, I boiled it down to the following:
I wanted to give my user the power to create an alert that would create regular text alerts according to requested parameters, with the capability to complete a purchase within a few taps of getting it. With the instructors’ gentle guidance that most projects should consist of about 5 screens, that was the flow I most wanted to prototype. I found the user flow process harder than I possibly should have, due to my known tendency to add too many steps to simple processes. I think I will partially alleviate this problem in the future by organizing my thoughts in a text list before going to the visual, knowing that it helped in this case.
Prototyping
From here, I went to paper, creating a few screens for the task I wanted to enable:
Make an alert called “Weekend at Home:” that sends you a text message if a round-trip fare from New York to Boston drops below $59 at any point in the next month. You will need to leave on a Friday and return on a Sunday.
My earliest tests had things missing from that verbiage, which will be addressed later.
This is based on Participant #1’s specific need to take weekend trips to Boston, but even at this stage, I wanted it to work for users across the country, who will all have different needs regarding pricing and timing. I even have my own frequent bus trips to eastern Pennsylvania that have their own quirky considerations to contend with, but tried to compartmentalize those needs from the interviewee’s.
Here’s a scrolling profile page that allows a look at past trips, access to a fare search (and presumably a fairly traditional path to purchase), functionality to create alerts for fares matching your needs, and a place to store payment information, to speed up the purchase process for those who need to lock in a fare before it jumps up (Megabus passengers in particular have to contend with a fare structure that is much cheaper for those buying the first handful of tickets for any departure, and climbs as more seats are sold.).
This is the “Create Alert” Screen, which I made in hopes of addressing the needs of both my first and third interviewees.
To accommodate someone who has a specific idea of the day of week they want to travel, but a vague idea of which week or month they want to take the trip, I made a long, scrolling menu full of parameters based on time, amenities, and price.
I felt at the time that more options to control the frequency of alerts were needed, and hypothesized that Participant #1 who cited that she tends to buy her ticket 2–3 days before the trip, would specifically want a notification on Tuesday or Wednesday, and would want not to be bothered at other times, so I tried to prototype for that specificity.
This is what I drafted for the text of the SMS output. “Designed” would be a strong word, since I don’t have any input into the UX of Apple’s or Google’s SMS app besides the copy we send. Future prototypes corrected the oversight of not making “Click here” an underlined link. Those links would take you to one of these two other screens.
Testing
The first test was with my third interview participant, who taught me a lot about what might be muddled in the design, including the verbiage of my task as originally written.
https://goo.gl/photos/YepbPPJQdfkCfG9b8 (video of that test)
Once we both understood each other, the test proceeded reasonably well until we stumbled at the point where there were 2 places to input fares, and the difference between them was unclear. Otherwise, I got some helpful ideas about how to make the screen more logical, including some word choices to make the screen more conversational, and a suggestion to put all the pricing options together before the amenities are even mentioned. Once I was able to show the format of the text messages she’d be receiving, she felt very warmly about the convenience it could afford, and wanted only a means to stop the alerts, which I hadn’t considered yet. She liked the “HOT FARES” alert and thought it would encourage her to purchase quickly, due to the capital letters that are early enough in the message to show up in the lockscreen notification. That inspired me to add it to the Alert Creator to make it more distinct, and to set it as a working title of the project.
The next test was not captured on video, an error in organization that I will try to mitigate in the future, along with my inconsistency in setting the task, by way of running checklists on myself before all tests, at least until the habits are ingrained. This tester provided a suggestion that used a radio button to designate the choice between daily notifications and the more infrequent weekly/hot fares choices. She also wished that the dialog box to save the alert had the name “Name This Alert”, since the word “save” was already there.
Second Paper Prototype
In the hours remaining, I felt that my testing had accomplished its goal: I’d learned enough to know that despite success with Participant #3, there were serious problems (without a single user yet who followed 100% of my expectations), and had received actionable suggestions for those problems. Pride might have led me to try more users in search of more favorable results to soothe my ego, but I decided instead to use the time to prototype again, incorporating all suggestions from my first users. Almost all changes had to do with the Create Alert screen. I observed no trouble with the profile screen, so left it almost unchanged (pink contrasts were an aid to help me sort my first prototype from the second one when it came time to organize the paper at the end of the night.). The copy of the SMS output now featured the addition of a capability to unsubscribe by replying.
Testing
In the minutes before class was kicked out of the building, I got some quick and dirty tests of the second prototype in. Two brand new testers were both tasked with the same task, and both immediately went for the “Fare Search” screen. I had thought that a task to create an Alert would lead most people to the “Create Alert” screen. Once corrected, the users completed the task with a little less difficulty, but the two failures in a row probably means there’s something wrong with the design. If the only variable between the two prototypes is my addition of color contrast, then scientifically, I must explore that as the cause, but intuitively, these users believed that the topmost option was what they were supposed to do. I must also therefore explore putting the alert-based fuctionality above the fold. One user also went straight to “HOT FARES,” when it was the conventional fare alerts that would have accomplished the task, citing that the seam where two paper slips were spliced together made it seem like a special section that he was supposed to click. That was a valuable lesson to be mindful of paper seams in future prototypes.
These are initial observations based on informal tests on tired people trying to go home for the night, and not taped. Though I believe that even under ideal testing circumstances the problems would remain, I would nevertheless still want to re-run this testing to make sure it was scientific and reproducible before acting. Pending that, my initial instincts for a new iteration are to flesh out the home screen, add a screen confirming the one-click purchase, and to iterate even more on the word choices. Paulo also asked if it was feasible to purchase via an SMS reply, and I’d be interested in exploring that.
Live Presentation
I enjoyed presenting this work live, and felt engaged and lively, and proud of the work I’d done, though as always, the act of performing makes the minutes go by too fast. It is my tendency in presentations to overwrite on the slide, but to still use mostly my own extemporaneous words, and so I felt better about what I spoke than I did about what my slides showed. I believe the feedback reflected that. I also paced the information badly, compressing the most important parts at the end once I received the one-minute warning. My past life performing comedy has left me ingrained with a respect for what we would call “the light.” That’s when the show runner waves a candle at you, and it has the same function: telling you that you have a minute left, and it’s time to nod, acknowledge the communication, finish your thought, and say good night. Others took liberties with that, and if I had, I would have had more articulate things to say about the differences between one prototype and another. I will practice my pacing in the future, using a timer as I used to do in that past life, and also simplify my slides so I can let my speech carry the weight, as it seems to be what people responded to.
Marvel and POP both malfunctioned on me in turn at critical points in the hours before the presentation, in each case causing me to lose work and making me unable to include a live demonstration. In POP, it was a crash of the app while trying to save my work. In Marvel, it was an inexplicable inability to access my account, even after two password resets to make sure I wasn’t crazy. These links are to the primary app in POP, and to a second POP prototype that represents what happens after a text message is received.
Final thoughts
I enjoyed this challenge despite failing at times. The major thing I learned was that while I didn’t find bus fares a particularly “sexy” subject matter, I found the mindset to be excited about the execution of this process, and to address the need I saw, rather than the need I wanted to see. I hope this bodes well for my future in the profession. I had some frustrating moments of disorganization, sometimes caused by important slips of prototype paper becoming misplaced, and I didn’t film as many of my tests as I should have, but I have ideas to address these.
Overall, I think I had a little more success than failure. My solution to the problem has the potential to be helpful, if not original, and it will remain on my mind as I learn in the near future some of the visual and interface techniques that could have presented the proposed functions more pleasurably.
