dylan cooper
UX Designer
Byxe
Crowdsourced Bicycle Routes For New Commuters
Role
Tool
Duration
Product Designer
Pen and Paper
Figma
Google Forms
May 2022 - July 2022
Cyclists in the community know what roads are safer and more efficient than others, how can others find that out too?
Learning to use your bicycle to commute in a new city can be difficult. You need to balance your ability to look for signage and remember directions, while also trying to remain safe and efficient.
Byxe helps new resident cyclists by providing crowdsourced data on safe and efficient bike routes.

Heat map of routes recorded by cyclists measured by their average ratings
Simple comment system with built in translation for inclusive community engagement



Turn by turn navigation
Minimalist rating system to compliment 'on the go' tendency of cyclists
?
?
?
Why Byxe?
?
?
?
I rode my bicycle to my campus every day while I attended university, but seldom saw any one else on my route. I often wondered how I could share this "hidden" pathway to encourage its adoption of a dedicated cycle route. With that in mind, Byxe was conceived. The challenge was to make an application and website to encourage others to take it as well. The solution is to provide a map for those who are interested in using their bicycle to commute and to communicate the paths in a simple and effective manner.
.png)
Research
.png)
Ideate

Hi Fi
.png)
Iterate

Evaluation
Survey
Task Analysis
Competitive Audit
Radio Interview
Crazy Eights
Pen and Paper
Layout
Visual Design
Flow
Prototype Testing
Product Drawbacks
Next Steps
Research
Research for this project was extensive. The design had to be grounded in the conscious and subconscious needs of a cyclist that would be inclined to use their phone prior to or during a bicycle commute.
Survey
The survey had to be carefully thought out. I needed not just what people thought, but how they felt, which is not easily done in an un-moderated format. Luckily, the opinions people have about riding bicycles are varied and passionate.
Overview of the survey
What was necessary to fully understand the user was to get the most holistic idea of ones feelings towards a bike. However, the challenge was to also associate biking + phone use without inputting too much bias and/or inciting immediate discontent, as would be expected since biking + phone use is associated to risk of injury or an experience that takes away from the freedom of riding a bicycle.
Through a mix of social media, word of mouth, and posting to Reddit, my survey generated 41 responses.

I synthesized the responses into common themes and insights to provide a condensed version of the information.

The most important comment I received
Persona Development
The development of a persona came naturally. The survey generated such a plethora of information that a user could be easily imagined.
That being said, intended to narrow my focus on the responses of new comers to a city, specifically new immigrants, as their main means of transportation at first are typically public transit and bicycles.
Keeping these needs in mind allowed me to build the design from an inclusive and accessible perspective, which would mean all who use it would benefit from these considerations.


Task Analysis
The next step was to determine what my personas were currently doing to plan/conduct a bike ride using their phone.
Based on the survey responses there is a polarized view of bike riding: you either go on your bike and leave feeling satisfied and confident of your route not using a navigational tool or you use a navigational tool, such as google maps, but typically do not feel the confidence of a route given.
This was reflected well in the responses to the questions about riding on a sidewalk. Some were adamantly against it and some felt it were safest option. I found this question essential to ask, even though I would likely not be designing a product intended to navigate on sidewalks, because it gave me insight into what people thought was safe and acceptable.
Most importantly, whatever cycling felt like to the respondent, the theme of simplicity and a freeing feeling were most present in the responses.
Competitive Audit
The competitive audit proved to be extremely valuable.
Though there are many "crowdsourced" bike route applications and website currently online and on web stores, they all appeared to be directed at users who are already comfortable commuting by bicycle.




Some notable comments:
bikemap.net: may have been the closest competitor in terms of product offered, however the routes were targeted toward simply an arbitrarily enjoyed route shared by other users, not a network of cyclists helping one another be safe.
bikemaps.org: Essentially the same idea as mine, but it is perceivably more of a research and analytics tool than a navigational system. The heat map gives the user an idea of where incidents occur, but does not provide real time guidance.
Radio Interview
In the midst of my research, the local national news network for Saskatoon, SK (CBC Saskatoon) caught wind of my survey and initiative to create a crowdsourced bike route map. After a couple of questions, they asked to have me on during prime time morning airing of their program on June 13, 2022 to discuss further.
After the interview, my survey generated a few more responses and provided me a chance to practice the designs presentation.
You can listen to the interview here:
Ideate
Crazy Eights / Pen and Paper
With the preliminary research completed, I started to sketch ideas of potential layouts, experimenting with digital drawing (to measure its efficiency vs. paper and pen) and paper drawings.

Digital drawings using a Wacom Intuos

Paper drawings for each page
Layout
To determine the layout, there had to be some special considerations, of which some have been mentioned concerning simplicity and accessibility.
Making us of multiple lo fidelity wireframes and ordering and reordering their flow was how I was able to land on a final design flow.

Multiple lo fidelity wire frames were made for each page. Some ideas obviously would not work, but they helped immensely to decide what would.
Hi Fi
With a well defined and interested user base and the basic layout decided, I was able to begin creating a first run of ideas for the Hi-fidelity design.
A couple points I had to keep in mind:
| The mobile application would typically be used outside, so there needed to be high contrast in the visual design to account for sunlight
| Most, if not all, functions of the app need to be accessible with a thumb as a cyclist is on the go, or may have one hand on the bike
| It had to be as minimal as possible to entice users to use it as part of their routine. If the idea is to crowdsource cycle routes, then I am relying on the user to provide their time and energy, so the least I can do is make that experience as smooth as possible
| I needed a system to determine the effectiveness of a comment system. If a comment is useful or not and if there is a threshold for a 'bad' comment or its lifespan on the map (if a comment that is 1 or more years old, is it still relevant?)
| Lastly, much of the design would be reliant on API's, most likely google maps, as well as a weather application. Knowing this, the design was constructed with an idealized aesthetic, however in practice I can concede that there would likely be challenges to overcome.


Initially, the settings menu was transparent, with the intention to put the focus on map, but affordances of menus an an application shouldn't be hidden, so I changed it to a higher contrast.
All the foremost functions are accessible and readable in a single location. No need to scan the entire screen to find the purpose for being there.
The ability to hide certain UI elements is P0 for some users. This option is located in the settings menu, however the comment drawer is easily hidden at the tap of a finger (not a slide as the map is controlling the main scroll option).

I wanted to keep accessibility in mind for all users, especially marginalized communities whom use bicycles much more frequently than most realize. With this I included the option to choose the language you desire to comment in and providing a translating API to promote visibility within the communities of cyclists.



A user can determine for themselves if they want to record their ride for various reasons.
Commenting is limited to 60 characters. This is to promote quick communication. Most information derived about commuting by bike is by lived experience, but a quick line of information, whether a 'heart' for a pleasurable experience or a 'caution' for non-pleasurable is enough information for cyclists to derive what they need to know: "Will I like this or not". Cycling and perceived safety is a suggestive experience, to minimize the clutter and risk of information overload, the user will have only the important facts of a route available.,
When a route is inputted into the navigation, a simple scale is displayed that gives an average of perceived safety and efficiency, based on users' recorded data, of which the application will determine a route with the data. The user can use this data then to decide what the best course of action to take.
Once a ride is finished, whether the user recorded their own or used turn by turn navigation, the user is presented with a screen asking to evaluate the ride. This information is the critical backbone of the application. I quickly realized there would be an issue determining the safety and efficiency of all parts of the trip in an easy to understand and use feature. I came upon the conclusion that a drag feature in a mini map selection portions of the ride would be best (with a quick onboarding explaining the process). This decision does present some possible issues with complex road systems and overall accuracy, but until further real world testing can be conducted, this solution seemed the most effective for now.

As mentioned, there is a possibility that my vision of a navigation UI may be determined by what API is available. That being said, I am aiming for a minimal display as there must be a balance with display vs. voice guidance. I conducted third party research in scholarly journals to determine the safety of cyclists + phone use and it is generally agreed upon that voice guided navigation is safer than a cyclist looking at their phone. The option must still be there.

During a recorded ride, the map updates a line travelled in real time, while providing your current location.

A small detail, however I want to place importance on the user providing the data for everyone else to use, so a thank you from the application I think is necessary to convey that.
.png)
.png)
At this point you may be wondering, "I see the features complimenting the main function, the safety and efficiency routes, but how can I see that?"
These are the preliminary approaches so far. Using a colour scheme with a slightly radiating hue, the colours are contrasted against the default dark map. However, there are colour considerations to remain accessible to those who perceive colours differently. Clicking on either tab will provide the average of ratings riders measured in the area.
Limitations of Figma prevents me from providing a zoom feature which would provide the user with a better understanding of the roads and paths taken, as well would make for an easier read map.
This is the area that will require some of the most real world testing to determine what type of colour schemes can be used on the map (generated by SnazzyMaps), combined with road safety and efficiency indicators.
Web Pages
The idea was to not just create an application, but also a web page that can run congruently with the application to gather data as well.
The frames that were created were representative of their features that are determined whether you were on your phone or your desktop.


The option is available to those who choose to use their web browser for navigation on their mobile phone, however due to the possible inaccuracy of information due to complexity limitations of the programming, recording your ride is not available, only the navigation system. It would need to be tested to determine if even this would be provided due to safety concerns.

As for the desktop, the UI remains consistent, with all the necessary information in place (this time with WIP name and Logo).

Inputting directions will give you the same safe and efficiently determined route, with the option to push to your phone.

Does it Work
?
?
?
?
?
?
(How can I test it?)
.png)
This is admittedly a major road block.
The product is a navigation application and without any real world experience, it is hard to determine if feedback from usability tests are providing much insight.
Regardless initial feedback was that the design was easy to interpret, but the map was overwhelming without a zoom feature, as mentioned before.
As well, relying on user data was a concern for a participant in my feedback of whom manages complex technological problems at work. Their suggestion was at a certain point, hiring a data scientist to manage the amount of data will eventually determine the best routes.
Despite the drawbacks, some optimism was incited on the project when the local cycling advocacy group in my city of Saskatoon expressed interest in collaboration with a similar product they have in development. The potential for real world testing got closer!
Evaluation
Product Drawbacks
Throughout the presentation I mentioned a handful of drawbacks that will have to be addressed before and during development. Here are a few more to consider:
1. Aggregate data is required to initially run the application. Applying any other algorithmic data defeats the purpose of the application (to use real users' experiences). This does however run the risk of inputting too much subjective data and not providing real trustworthy data.
2. Due to the complexities of other major cities' roads and paths, this applications effectiveness is largely in question. To overcome this problem, I will focus on the application to provide data for my city of Saskatoon, SK Canada as it is is highly navigable city, but is small in population and spread. If there is success here, it may be scalable elsewhere.
3. Lack of account creation was something I intended. This makes the application much more accessible to all, as is needed to amass data. However, I will need to determine how to ask users' to consent to their data being tracked without being intrusive or unsafe. Also the app can't save routes, such as Home or Work. To many this will be in inconvenience and I may have to consider adding this feature in the future. That being said, once users know their preferred routes, it is unlikely they will change them during a regular commute, so my intention is to provide a reference, not a necessity.
Next Steps
My next steps are to continue my collaboration with Saskatoon Cycles
With their support, data, and access to interested developers, the product is sure to go through many phases of ideation and development to make a useful product for the prospective commuters of Saskatoon.
From there, the application has potential to be scalable, but its ability to provide safe routes must be determined first and foremost.
As for the design, careful thought needs to be put into the default map, map options, and route display to provide the most accessible experience for all.
Real world testing will determine much of the applications direction!
Thank you!
d c
References that Guided the Project
Colin Ferster, Trisalyn Nelson, Karen Laberee, Meghan Winters,
Mapping bicycling exposure and safety risk using Strava Metro,
Applied Geography, Volume 127, 2021, https://doi.org/10.1016/j.apgeog.2021.102388.
(https://www.sciencedirect.com/science/article/pii/S0143622821000047)
Cognition, Technology & Work (2018) 20:377–388 https://doi.org/10.1007/s10111-018-0478-y ORIGINAL ARTICLE Bicyclists’ adaptation strategies when interacting with text messages in urban environments Sara Nygårdhs1,2 · Christer Ahlström1 · Jonas Ihlström1 · Katja Kircher1,3 Received: 19 December 2017 / Accepted: 21 March 2018 / Published online: 16 April 2018 © The Author(s) 2018
https://www.analyticssteps.com/blogs/how-do-google-maps-work
Bouwer, Anders & Nack, Frank & El Ali, Abdallah. (2012). Lost in navigation: Evaluating a mobile map app for a fair. ICMI'12 - Proceedings of the ACM International Conference on Multimodal Interaction. 173-180. 10.1145/2388676.2388712.
https://www.thedroidsonroids.com/blog/how-to-develop-a-gps-navigation-app-like-waze