The Smart Bar:
Developing a innovative IoT technology to improve the safety and experience of bike commuters
The Problem
Biking is a source of transportation for many people. Ann Arbor has been named a Gold-Level Bike-friendly community with over 90 miles of bike lanes.
Despite this, bike commuting can still be dangerous, and many people still feel unsafe biking.
After preliminary research in the biking commute space, my team saw a huge opportunity to augment the biking experience to improve both enjoyment and safety. The Smart Bar aims to bring enjoyment and peace of mind back into the biking experience
Timeline
September - December 2023
Role
Primary Researcher and designer
Student in Pervasive Interaction Design
Skills
Contextual Inquiry
Interaction Design
Usability Testing
IoT Development
Tools
VS Code
Photoshop
Figma
Qualtrics
Research Plan
Problem Space Research
My team engaged in an extensive process of brainstorming, iteration, research, and selection of an audience and environment to focus our efforts for this semester-long project with an end goal of creating a useful and innovative Pervasive Interaction Design.
Pervasive Interaction Design is the process of leveraging ubiquitous computing to create technology that positively augments aspects of daily life.
My team individually generated 20 ideas each, upon further contextual inquiry and analysis we ultimately arrived at a single final concept: focusing on bike transportation.
Bike transportation was particularly salient to us as students who commute primarily through biking or walking in the particularly friendly town of Ann Arbor, Michigan. Despite biking and walking being a primary source of commute for many people in Ann Arbor, there are still many issues in bike commuting infrastructure and safety.
Research Methods
Diary Study
Rationale
To understand Ann Arbor bikers’ daily routines and practices, which provide the challenges and emotions in their biking experience, we recruited five users to record each of their biking experiences over the course of five days.
Research Challenges
Our very short 2 week timeline to recruit and conduct study
Academic break was over this period of time: meaning many students were out of town or not as active biking as they typically were
Freezing rain filled 9 of 14 days within these two weeks, making biking challenging for participants
Some Image Artifacts from the Diary Study
A bike parking location and the pre-biking survey
Key Insights
Safety was the largest overall stressor among participants
People are very prepared for the weather elements
People rarely feel prepared for safety while biking
Helmets were not often worn by participants
Survey
Research Challenges
Very short 2 week timeline to recruit and conduct study
Formulating a survey that gathers quality data from such a wide variety of stakeholders
Making sure survey logic splits were in the correct places
Recruiting enough particpants for significant results: disseminated on Reddit, with University internal networks and more
Rationale
Having gathered qualitative data from the bikers perspective gathered in the diary study, I found it important we were also backing up the identified qualitative pain points with quantitative data. To maximize our understanding of the problem, the focus of our survey was bike commuters, as well as people who typically utilize other forms of commute, such as cars, buses, and walking.
Some Image Artifacts from the Survey
Sample survey questions on phones
Key Insights
There is a lack of knowledge from all parties about right of way laws
Most respondents, regardless of whether they are bikers themselves, think it is helpful to have bike lanes
Bikers feel anxiety around cars, and cars feel anxiety around bikers
Empathy and Journey Maps
With the data from the diary study and the survey empathy and journey maps were created to better empathize and understand our key user: the bike commuter, throughout our development process
Solution Ideation
Armed with our data and pain points, our group took some time to diverge in our thinking again.
Brainstorming different solutions for the identified pain points. I explored differing levels of augmentation of the bike riding process, that is, how future facing and how significant of a change to the environment our ubiquitous computing solution would be.
In order to visualize these ideas, my team worked together to complete a design matrix; a small section of this matrix is pictured here
A Design Solution Matrix with some of the explored solutions
I pitched user enactments as a means of testing reception and market desire of our ideas. User testing in this setting acted as usability testing for a digital product, as it enabled us to create a quick, low-cost, and low-fidelity litmus test for product feature reception.
We conducted numerous different user enactments with our most accessible audience, (which in this case were our classmates who were generous with their time) to test the user enactment procedures before we launched to a wider audience.
User enactments require a large suspension of disbelief and some “Wizard of Oz” technique research as well- making it important that the enactments are well rehearsed and the user has a smooth experience.
User Enactments
Enactment 1
Focused on Bike parking augmentation
Enactment 2
Focused on safety prepartion
Enactment 3
Focused on object detection
Prototype Development
Because of technical limitations and only four weeks left in our project timeline, these features were developed to various levels of completion. We used a variety of different sensors to take inputs from the environment (Including a Neopixel Ring and Motion Sensor) , repurposed an old PVC pipe to serve as our handlebar base.
Development required a mix of programming and “Wizard of Oz’ing” skills. The navigational assistance was the feature that required the most work to develop a convincing version of it in the product. Blindspot detection and object detection were developing leveraging different sensors and lights in tandem with haptic feedback on the grips of the handlebar we produced.
For three iterations of our navigational assistant, we had it as a voice-only feature. However, recalling our original research, I remembered that bikers are often distracted by road noise or other stimuli that make it difficult to hear—while this feature would have sounded cool (and we had already written code for the navigational assistant), having a voice-only assistant was not a useful feature for our users—we needed to pivot. I found the clearest way to display navigational assistance in its future state was through physical representation: compass-like arrows attached to the handlebar that theoretically used haptic feedback and lights to direct users. Time constraints and technical limitations inspired very creative development, as our navigational assistant was eventually shown to audiences with an arrow on a stick controlled by a team member under the table.
There were many points in development where we prioritized the user identified needs, over what looked “cool” or seemed like the flashiest features. In addition to the current state development, future-forward development documents were created showing the ideal functionality of The SmartBar.
Feature Selection
Based on reception from the user enactments, as a team we decided to develop three features informed by major research insights:
Blindspot Detection
Research Insight: Not knowing the location or action of cars on the road makes bikers anxious
Navigational Assistance
Research Insight: Motor skills needed to ride bikes make it difficult to use screen based navigational aids
Obstacle Detection
Research Insight: Obstacles in bike lanes make bike commutes dangerous and arduous
Demo Presentation
The final demo started with a pitch presentation of our product that I created and delivered, imparting our research insights and the value of our product.
In order to make The Smart Bar feel like a product that anyone in the audience could use in their daily lives, I made a video to accompany the demo that featured a POV-type view of a bike ride around Ann Arbor, and became the “wizard” (the narrator) for the demo. I guided our audience around the streets of Ann Arbor, while one team member (wearing a helmet) held the smart handlebar, another user sat under a table turning the navigational arrow, this allowed users to feel as if they themselves were the ones biking.
Our product and pitch were awarded “Most Likely to Attract Investors”
Practicing our Pitch and my team with our award
In Reflection
The SmartBar was the first physical ubiquitous computing product that I have ever worked on developing. I am very proud of the immense work that went into the creation of this handlebar within the short 12 weeks my team had to make it. However, there are many limitations to what we created.
Some of these originate in the research stage. Though we did conduct a diary study and a survey, our sample size was limited, and if we were to continue with the development of The SmartBar, I would like to do more comprehensive research with larger sample sizes to ensure that The SmartBar does solve identified problems
Though our product was very well received after the demo and pitch presentation, it is not fully developed. I believe developing an MVP (informed with feedback from the prototype) would better display the future value of The SmartBar.