An innovative physical and digital e-bike interface that incorporates
level 3 autonomy for an improved biker experience.
As a team of 5, we created a simple yet powerful solution that would
revolutionize the e-bike domain.
Role
UX Researcher
Project
Interaction Design Studio
Timeline
Six Weeks
Tools
Figma, FigJam, Miro
Overview
Our project is focused on exploring new controls and paradigms for an
automated Ford electric bike. Level 3 automation can require a human
driver to take over quickly, in ambiguous or dangerous situations. At
the start of the project, we research existing conventions for bikes
and transportation dashboards, building a frame of reference for the
digital aspects to be integrated into. We focused on specific tasking
items that were relevant and realistic for typical use cases:
prioritizing user interaction with turning on and off auto mode,
checking the speed of the bike, and being able to safely navigate.
Design Process
We used the double diamond process to help guide us throughout the
project timeline
Research
Guerilla Research
To begin preliminary research, we conducted Guerilla Research at two
POGOH E-Bike stations.This involved us walking to nearby strangers or
those who were parking and taking bikes from the station
This gave us critical insights into the bikers' inner thoughts
Affinity Diagram
Pain Points
○ " I want the digital interface to include navigation "
○ " I would like physical feedback from the bike itself "
○ " I want to feel safe when biking "
○ " The dashboard can display more items "
○ " I want the app to give me more direct feedback "
○ " I don’t ride the bike for too long "
Task Analysis
Our task analysis involved us first listing out the necessary components
for Ford’s Level 3 Autonomy. We then ranked these tasks using a bullseye
diagram to determine the most important tasks (bullseye of the target)
This challenged us as we felt constrained by the little space we had in
the bullseye. We reflected on our own experiences, our interviews, and
the background research we performed on the bikes.
From those insights, we were able to communicate about where each task
should go
All of our work culminated to storyboarding flows to demonstrate how our
users would interact with our proposed solutions. We showed possible
processes through showing the context, problem, our solution, and the
resolution
Prototyping
Over the course of four weeks, my team and I brainstormed, prototyped,
user tested, and refined our different prototypes of the physical and
digital interfaces of the E-bike
The Physical Prototype
We first sketched a physical prototype of the E-bike with appropriate
measurements based on the Semi-Autonomous Vehicle Requirements.
Based on these measurements, we began building our physical prototype.
There were several requirements we had to meet for our prototype.
However, throughout our process, the general shape of the physical
prototype stayed the same
From our usability testing, we improved the following features
for our final prototype:
○ Added more user-friendly brakes
○ Adjusted the Power-on/off buttons to make them more noticeable
○ Added an icon to the physical bell to illustrate its function
○ Replaced the confusing physical microphone with an icon presented
on the dashboard that aligns with the camera
○ Removed physical buttons for auto mode ( presented directly in
the dashboard)
The Paper Prototype
We made our initial paper prototype based on the requirements outlined
for us in the given assignment. During user testing, we received
a lot of feedback:
○ It was confusing to go from the on state to the off state of Auto
Mode because it didn't make sense to click "Auto On" to turn it off
○ Users don't know what to do next after the system reports an
error.
○ “When I see the error reported, I don't know what else I'm
supposed to do but stop.”
○ Users didn't notice the turn signal function / didn't know what
the two arrows were for
○ The users thought the arrows would take them to another screen
The Digital Prototype [Default Manual Biking State]
Durning this stage of our process, we converted our paper prototype
alongside the feedback we received into a digital prototype
○ Used a grid system to organize our layout
○ Prioritizing the automode on/off feature
○ Limiting dashboard functions to discourage users from
interacting with it unnecessarily during rides
○ Exploring notification displays for slowing down
The Digital Prototype [UI Choices]
○ We used orange to indicate that automode was turning off
to indicate to the user that they needed to manually take control.
○ We used green at the start screen to indicate that the
bike was good to use and also when a system error was resolved (to
resume riding).
○ All other parts of the dashboard were monochrome so any colored
notification would stand out immediately.
○ Note: the physical prototype includes speakers that can audibly
notify the user
The Digital Prototype [Revisions]
3 Main feedback points from usability testing:
○ Orange indicator is alarming: users initially thought
this meant there was a system error
○ Phone stand is too far for user to see phone screen:
leads to lack of navigation ability
○ User check on the right side is
unnecessary since it it grey and static most of the time.
Given the feedback from our usability test, we implemented the
following:
○ Blue (Ford brand) colors for slowing down indication
○ Navigation system similar to apple carplay
Including a navigation system inevitably added another layer of
complexity to our screen
Since we wanted the map to be enlarged for readability at certain
points of navigation, we also had to incorporate changes for the rest
of the layout of the screen.
Some of the questions we had before our second round of usability
testing was:
○ When should the map be enlarged?
○ Should manual vs auto-mode correlate with expanding the map?
○ Or should navigation vs non-navigation?
○ Should users be able to interact with the map during a ride or
only able to start/exit navigation?
The Digital Prototype [Second Revisions]
From our second usability test, we gathered:
○ People prefer large maps all the time while they are biking.
○ Even if they are in the auto mode driving, they want the map to
stay larger.
We then made the following changes to our navigation system:
○ The map will be the same size for both auto and manual driving
conditions.
○ Users will not be able to adjust the map's size while biking
due to safety concerns.
We also changed our error check mark on the screen since users tend
to get closer to the screen to see the reported error.
○ Initially, we kept the error reason like “Damaged brake” under
the red rectangles.
○ After revision, the error configuration process will be shown in
the red rectangle so the user can see how the system checks the error.
This can eliminate their panic as well.
Our last change was displaying the turning signal because of the
added navigation.
According to the second user test, people will focus more on the
dashboard since they must look at the navigation.
○ Initially, the turning signal will directly be the button itself
by blinking.
○ After the revision, the turning signal will be added to the
dashboard so that people don’t need to pay extra attention to the
turning buttons. They only need to focus their attention on the
dashboard.
The App Homescreen Prototype
○ Initially, we approached the home screen by thinking of the
e-bike as a shared bike. Therefore, we value the “Map” feature more
than “Profile” since users need to look for shared bikes to use.
○ After group discussion and evaluation of Ford company, we
decided to consider our bike a personal bike that would only be used
by the person who bought it. Therefore, we value the “Profile” feature
more than other features so that users can always be clear about the
general setting of their bikes.
○ As a result, we made the profile page the app's home screen
instead of the map page. However, users can still get to the map
section by switching to the map icon at the bottom.
Throughout this assignment, I learned about more user research tactics
(guerilla research, task analysis, etc.) and different types of design
principles (Gestalt principles, information architecture, unity, etc.).
The process of doing research and further making a physical product with
interactive components gave me valuable insights that I can use in
future projects.
I would like to thank the instructors of Interactions Design Studio for
supporting my team throughout this process. I'm most thankful for my
teammates for their dedication and hard work they put into this project.
Without them, this would have not been possible.
