Ironhack’s Prework: Dave Ostergren_Challenge1.

This piece is a product of course pre-work that I have completed as part of my admission to Ironhack Miami’s UX/UI Bootcamp in Miami beginning on June 8th, 2020. I’ll be posting future coursework here on Medium during my attendance in the program. To any reader with experience in User Experience Design: any tips, feedback, and suggestions on my process or prototyping are warmly welcome.

UrbanGo, a transit-tech company based in Silicon Valley, is seeking to simplify the public transit experience by providing riders with an intuitive trip planning mobile application. The marketing research team at Urban Go has found that a significant amount of their users experience a shared pain point: many trips require a rider to purchase multiple transit passes from separate agencies in order to travel on the various transit options available to them such as busses, trams, and trains. If a rider is unaware of the numerous passes required to ride, they may find that they’re unable to complete their trip without an unexpected trip to a local pharmacy or convenience store to purchase another transit pass. If time is a factor, this user may instead turn to competitors such as ridesharing apps, and may even avoid taking public transit altogether in future trips.

When I read the outline for this challenge, I was pretty excited to get to work on it. I recently visited San Francisco and experienced basically the same scenario I outlined above. (Remember back when traveling was still a thing? For those of you reading this from the future, I am referring to the time before the Covid-19 crisis — which I can only assume you know as “the beforetime”). Few things inspire like reality, I suppose.

My first task of this challenge was to do some introspection. Since I am a human and this is a human-centered design activity, this felt like a pretty good place to start. The challenge guide came with some prompts to get me started thinking about the nature of the problem, what potential solutions could look or feel like, and who might encounter these issues (re: my target audience).

I imagined that there would be three users/use cases for this product:

  1. Commuters: daily/regular users of transit — likely take multiple trips on the same line each day
  2. Students: regular users of transit — likely take multiple routes in a given week
  3. Tourists: likely to be heavily dependent on transit and rideshare options. Unfamiliar with local transit routes.

I made the assumption that regular users like commuters and students would probably know the transit system in their area of residence fairly well, so I decided to focus on tourist users. (I know some people commute out of town/state for work quite regularly. Let’s just pretend they fit neatly within the commuters or tourists profile for convenience’s sake)

With my target audience identified, I put on my product owner hat and wrote a user story to capture the challenge I was solutioning:

As a tourist transit user, I would like to know what transit tickets/passes are required for the trip I am planning so that I can be confident that I will reach my destination on time.

With the story written the value add seemed pretty clear: simple trip planning with intuitive fare purchasing options. I was almost ready to start wireframing a solution, but so far I had been painting a picture from my perspective alone; It was time to get a second opinion … or five.

All in all I spoke with five transit users who, at one point or another in the pre-pandemic world, fit the tourist user demographic I mentioned above. I asked each of them the following questions:

  1. Do you have any public transit nightmares?
  2. How do you track the fare value of your transit passes while planning trips?
  3. What is an ideal public transit trip for you?

I chose to ask these questions because they are open-ended and would hopefully get a conversation going on the topic without fixating on the challenge I was solutioning. I decided to take the approach of asking for worst-case/best-case stories and sandwiching in a quick question related to the topic of managing multiple transit passes. As you might imagine, these questions kicked up some pretty good conversations. After the interviews were done, I noticed two themes that each person brought up:

  1. Keeping track of transit pass value (the current balance on the pass/card) is hard enough with just one ticket — it’s much harder when there are multiple tickets involved.
  2. Planning a trip in a city you are unfamiliar with can be tricky — clear and concise signage was considered a must-have for ideal travel by everyone I interviewed in overcoming this.

With a bit of extra context and the underlying problem to solve now verified it was time to start thinking about solutions.

Common advice for designing product solutions is to begin with “The Happy Path,” or the best-case scenario for the most robust version of the solution. In this case, I envisioned a feature called OmniPass available within the UrbanGo app. OmniPass would leverage QR code technology to allow transit users to use one pass for all transit options directly on their smart device — a sort of omnipotent travel pass if you will.

OmniPass sounds cool enough, but there are actually a busload of barriers and most of them are squarely outside of the control of UrbanGo. For instance, suppose that you tackled the task of integrating with all of the payment processing systems used by the various transit authorities, there is still the question of hardware (do all busses/trams/trains come equipped with barcode/QR code reading turnstiles? Probably not …. At least not yet anyway). So I took a different approach that, while not as flashy as virtual tickets redeemable on every transit option, does manage to solve the problem.

Here’s what’s happening in that paper prototype:

Step 1: User selects desired destination and starting point.

Step 2: User selects preferred trip route.

Step 3: User is presented with required fare (fare is itemized by the unique passes required).

Step 4a: If the user does not need to purchase a pass, the user selects “let's go” — proceeds to trip-tracker.

Step 4b: User selects the “need to buy a pass?” option.

Step 4c: User selects desired pass vendor and is navigated there via their preferred map application on their device. (Trip data is saved when the app closes/enters into background state).

Step 5b: User is presented with a trip-tracker displaying stops, transfers, and estimated arrival/wait times.

Steps 4b & 4c are where the problem gets solved — the user is made aware of the need for multiple passes and given a quick and easy way to find nearby transit pass vendors.

I had a blast putting this prototype up together. I learned quite a bit while attempting to capture and communicate digital experiences on paper. It was a challenge to think about how I could simply and effectively message to the user that there would be multiple passes required without interfering with the main objective of their in-app experience: to plan and track their trip.

Please feel free to share any questions, tips, or feedback on the process or my prototyping in the comment section, and thanks for reading!

Product Designer — Coffee Drinker. Let’s create together:

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store