Transit durations varies significantly between departure times. Current time-pickers are used as input-output of information without any additional help. Users (until now) accepted a slower trip without knowing a faster one was close by.
1
Problem defintion
2
KPIs & Objectives
3
Research
4
Mapping challenges
5
Competitors analysis
6
Current usage analysis
7
Data analysis
8
Conceptual brainstorm
9
Data structure
10
Define functionality
12
Low fidelity wireframes
13
User Testing
14
UI design
15
Dev review
16
Implementation
17
Pixel perfect QA
18
Gradual deployment & A/B test
19
A/B test analysis
20
2nd iteration improvements
21
Full deployment
💿 Sporadic Data Public transportation doesn’t always have a linear data, there can be trips in 30 / 50 min, and than 2 hours with no trips. 🖌️ Visually Communicating data Potential data points had to be prioritised in order to communicate the value 🛜 Server-calls overload Each day can have a many time-slots, we needed a way technically handle all this calls 🤔 Awareness problem Most users were not familiar with the problem, in our reviews only 2 out of 11 people were familiar with the problem
Improving feature’s Engagement (by adding user-value) Improving Retention (by adding user-value) Improving Subscription conversion (business value)
Core value of control
Core value of time-saving
Core value of reducing-friction
Old UX had high-friction flow
Users need to go through 4 screens - before any valuable data is shown. Having a regular time-picker “input-output” of interface modes (define time > view results) added a lot of friction
Future-time data analysis
Analysis by how far ahead the “future-search” is.
Depart at VS Arrive by
Majority of future-search is between 6:00 - 9:00. There are 2 options to search, by “arrival time” or “departure time”
Hours searched by percentage
ℹ️ Mid-point insights
🗓️
Insight 1 Most future-searches are for the same day, within 12 hours.
📊
Insight 2 Search peaks 06:00–09:00, with a second rise 15:00–17:00.
🚶♀️
Insight 3 The closer the time-search is, the more likely users pick "Depart at."
📍
Insight 4 The further the time-search, the more users use "Arrive by."
❗️ No other competitor provided such value for users. All apps provided a “static” time picker as input/output of information - with no additional value
⭐️
Major Opportunity This was an opportunity to not only provide users with added-value - but also to be a key differentiator between the competition
❗️ Apple maps
❗️ Google maps
❗️ Citymapper
❗️ Transit
Defining the data and data-manipulation (ie: functionality)
ℹ️
Information Departure time Arrival time Duration Date
🤳
Actions Change time Change date Change time modes (arrive depart)
I’ve tested multiple iterations and approaches, each one providing its own advantages and disadvantages
After many iterations and user-testing
Time-mode selection
Selected time
Day selection
Origin / Destination are visible to create
Additional state
Main CTA
⏱️ Skeleton loader, data takes average of ~700-900ms to load
Results
Friction to value - overview
Change Arrive/Depart menu
Date menu
After 1st gradual release, the feature had a lot of positive impact. However we noticed that the “depart / arrive” data showed a significant change from what users used to search like - this indicated an unexpected change. In addition, the data showed users used much “day changes” than the “time-mode change”
❗️ Iteration - 1
✅ Iteration - 2
✅ 1.️ Depart / Arrive easier to use and more discoverable ✅️ 2. “Day change” is more in use. Updated copy to accommodate all chips
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim
Users got added sense of control therefore added value, The added value resulted back in business value and added conversion
🎯
~% Increased Engagement More engagement of users who experienced the feature
📊
~% Increased Subscription Retention More subscription-retention of users who experienced the feature
💵
~% Increased Subscription Conversion Significant increase in business value
