Opportunity
I love to nerd out about public transit, travel infrastructure, and urban planning. So when I saw a design challenge that asked me to create an app to solve problems with mass transit, I was more than ecstatic. |
Metropolis Transit would like to provide real-time
visibility into the status of their buses and rail trains
while riders are waiting for their transportation to
arrive.
The recommended design should provide:
1) information on vehicle capacity
2) time to destination
3) current fare prices
This is a new set of feature additions and they
are OK with this being a new portion of their
current web/interactive presence that does not
need to follow their existing design conventions.
Maximum allotted time for project: 12 weeks.
Solution
To deliver a solution on time, I scoped out the project by working backwards from the 12-week deadline date. Of course, this was purely a passion project, but if I had a team that consisted of a mobile developer, QA, and business analyst, I would envision the project to flow something like this: |
Research
To reinforce a human-centered process, I started by talking to people on Chicago (CTA) public transit on different train and bus lines and going different directions. |
As a summary of my contextual inquiry and interview process, the following personas represent the diversity in responses and data I received.
|
Personas and conversations were a great dive into the problem space, but I still lacked a richer empathy for these different user scenarios that were different from my own daily commute. So, I decided to synthesize my persona findings into a user journey for the most frequent type of rider.
First half of journey: |
At this point, I've gathered plenty of data on who the users are and what their "typical" scenarios and user journeys look like. I firmly believe that the next step is always to combine all these into use cases, which will help to determine and prioritize what the app should do.
|
To summarize thus far, the prioritized use cases based on our user research and the business requirements include:
|
1. Find nearby, upcoming arrivals
2. Distinguish between trains and buses
3. See capacity and crowdedness of vehicle
4. Estimate duration of journey
5. Calculate fares based on journey
Design
Armed with a solidified understanding and priority of use cases, I created and revised a high-level information architecture for the app. |
Next, I started sketching wireframes by starting with item 1.1.1 in the "sitemap" above, since I believe it's important to start designing at the detailed ("meet and potatoes") portion, rather than at the top level ("home page") of the app. Working "backwards" in this way helps me to envision the next steps of the user flow a bit more clearly, as well as to budget my time on the screens where user interactions carry more weight.
|
Main Activity Page for Tracker
Search function at top of screen appears when user scrolls up. Dark theme available for alternative vision requirements. |
Detail page (station view)
Capacity currently calculated by number of riders entering through turnstiles and reveals possible delays. Dark theme shown. |
Add destination and calculate fares
Business recommendation: Increase fares during rush hour for partnered taxi services in order to encourage more ridership. |
Calculate fares by journey
Business recommendation: Implement “distance fares” and transit cards to increase profit and system efficiency for all users. |
Explore line maps
Business recommendation: enable GPS tracking of trains to track performance and allow riders to plan journeys accordingly. |
Notify the user in realtime
A personal guide to instruct the rider at exact points (when and where) to board and alight. |