Project Type: Case Study
Length: 2 weeks
My Responsiblities: Research Design, and Presentation
Team: Hann-wei Chang, Tian-yu Li, and Christopher Sayas
Deliverable: E-Ticketing Prototype
SUMMARY
The Boring Company builds tunnel systems underground that can ferry commuters though an underground rail system to avoid surface road traffic. Although the service itself is not yet available, as soon as it is launched there will need to be a way for commuters to interact with the service to buy tickets.
1.RESEARCH
Research began with understanding what functional value an E-ticketing system would serve for commuters.
A Business Model Canvas was created to understand the companies Value Proposition, a Comparative and Competitive Analysis was performed to see what transportation generally feature, and user interviews were performed to identify what are the feelings associated with a rush hour commute.
METHOD
Business Model Canvas
KEY RESULT
Established Value Proposition
I built a Business Model Canvas to get an understanding of what The Boring Company does as a business and what kind of Value can be delivered to commuters.
The Value Proposition created was to "Provide a safe and quick option that saves everyday commuters from the horrors of rush hour".
METHOD
Comparative and Competitive Analysis
KEY INSIGHT
Identified common E-Ticketing functions
Research began with a Comparative and Competitve analysis to understand what standard functions should be considered. Three categories appeared the most essential: Time Tracking, Partners, and Payment options
The research phase identified that commuters are having a painful commute regardless of whether they drive themselves or take public transportation.
This insight was identified by observing the Business Model Canvas and understanding what solution The Boring Company wants to deliver to commuters, conducted User Interviews that confirmed what the problem is with the current commute, and my Affinity Mapping identified the values associated with the problems in the current commute experience.
2.DEFINE
The next step was to take the research and live the commuter experience. I did this by creating a Persona to represent the user and creating a Journeymap that tells the story of what happens when a commuter deals with current rush hour traffic. Finally a User Flow was created to consider how the Persona would use our E-Ticketing service and guide our future design.
METHOD
Journeymapping
KEY INSIGHTS
Negative experiences compound
Users multitask during commutes
Journeymapping considered what kind of commute experience Janice might encounter.
The Key Insight observed was that Janice's one delay in her commute can compound her negative rush hour experience. There was also the realization that commuters may need to multitask while traveling.
METHOD
User Flow Mapping
KEY INSIGHT
Featuritis risk
I created a step by step map of how Janice would interact with our service. Due to the number of steps involved with this User Flow there was a risk of trying to do too many features with limited time. This forced us to prioritize what we would (and would not) be including in our design.
After converting research insights into observations, I understood what had to be focused on to deliver a desirable solution our user, Janice. The value that had to be delivered was oriented around empowering Janice with more control of her time.
That sense of control would give Janice the opportunity to use her time efficiently if she had multiple tasks to accomplish and needs the option to have more time to accomplish tasks more effectively.
However, the rush hour commute as it is currently completely contradicts this sense of control when it creates more problems for Janice.
3.DESIGN
To begin the design phase I relied heavily on our Comparative & Competitive Analysis and User Interviews to guide what functions should be included and what users expect in a transportation application.
This began with a sitemap to identify the type of Information Architecture that would be required, and a collaborative Design Studio to build our Low-Fidelity Prototype.
METHOD
Design Studio
KEY RESULTS
Identified key menu functions to include
Collaboratively designed initial home page
To guide the initial prototype design, each team member drew out a low fidelity concept for our home page prototype and we picked out which elements we agreed would be useful to Janice.
METHOD
Low Fidelity Prototyping
KEY RESULTS
Functional Low Fidelity Prototype
User Heuristic insights
I sketched out a low fidelity prototype which was tested with live users. Usability feedback impacted design choices by highlighting what users expected such as permissions access for location tracking.
The Design phase of this project integrated more user interactions with our assumptions. The concept product was created collaboratively with my team, the I tested this concept with real users, and the results of user testing clarified what would be effective to include in my prototype.
The result was a Wireframe that established all the screens that would be need to create a prototype.
4.DELIVER
After establishing what type of screens would be created. The High Fidelity Prototype was created, this began to integrate more of the rich media, colors, and typefaces that would be meant to represent what the final product could look like. The objective was to demonstrate what a functional version of the E-Ticketing service would look like.
METHODS
High Fidelity Prototype Design
Developer Review
KEY RESULT
Developer Feedback
Once the High FIdelity Prototype was built, I reviewed the Prototype with development professionals to understand what challenges there may be in the development phase of this project.
The result of our High Fidelity Desgin was a functional prototype of the E-Ticketing system. The entire design was guided with user feedback to conceptualize, refine, and design the actual prototype. This design emulates a product completely based on users like Janice.
FUTURE STEPS
There will be further steps to create a true Minimum Viable Product (MVP), but it is important that features and tasks are prioritized to keep users like Janice in mind.
A Web Application would increase the accessibility of the service. Based on the current design, the ticket is QR code based which could also be printed at home if needed.
One big risk for users of this application is also the complete dependency on the Mobile App for ticketing. If Janice's phone battery ran out before boarding, she would not be able to access her ride unless she happened to print out the ticket.
To address this risk, it would be beneficial to consider developing a vehicle plate scanning on the transit system that would make the experience completely hands free for Janice.