RiderLink
CLIENT
private
RELEASE
sept 21, 2020
INDUSTRY
motorcycling, social media
PRODUCT
mobile app
the challenge
​For many motorcycling hobbyists, riding is a social activity. Unfortunately, linking up has not been so easy. Many riders flock to existing social media platforms, like Facebook, and make posts in motorcycling groups about spontaneous joy rides. Oftentimes, people see these posts too late or the posts are not targeting users within a reasonable distance. Coordinating with local strangers has not been easy, causing riders to choose to either ride alone or plan outings ahead of time.
​
RiderLink's founder, a motorcyclist himself, saw this as an opportunity to bring a new idea to the market - a solution he called a one-stop-shop for motorcycling. With the help of my design team, he aimed to build an app helped motorcyclists connect with other riders and plan events in real time using geo location navigation.
my role
For this project, I focused primarily on the user research, analysis, and application of our findings to the initial low fidelity designs.
​
I worked with a team of two other designers - our lead designer, who was in charge of project management, and another UX/UI designer, who supported the research and focused on the app branding and high fidelity designs.
.png)
the research
Due to the strict project timeline, the design team made a game plan and split up our responsibilities of this project. While one designer focused on creating the new branding and marketing website for the app, I started our research efforts to test and validate our design assumptions from initial client meetings.
survey
Using Google Forms, I created a survey to send out to motorcyclists. The questions were framed to understand the users’ riding styles, if they ride with other motorcyclists, and their current methods and frustrations when it comes to connecting with groups. I also provided a few open ended questions for riders to provide other thoughts or concerns we may have missed.
The responses largely supported our initial assumptions. For example, most respondents stated they have been frustrated by wanting to spontaneously connect with other riders but were unable to do so. Of these riders, over 80% have used text messaging or their current network to organize a group.
The survey responses also brought up some additional concerns, including safety. While a majority of riders stated they preferred to ride in groups, they were not comfortable linking up with complete strangers. Instead, these riders would typically connect with friends of friends or connect with other riders they shared some quality with, such as age, riding style, or safety habits.
As a result of these findings, our direction for the project slightly shifted. The core features remained the same, including the real time locations and event functionality, but moving forward, we emphasized user safety and privacy in our design direction. RiderLink needed to be able to connect riders based on shared attributes and build a sense of trust that would help users feel safe.
we returned to the drawing board and incorporated the following features:
-
A more robust profile, with relevant fields to help match compatible users
-
In-app messaging to help riders build relationships before meeting
the competitive research
Going into this project, we were aware that there were other competitors already in this market. These other apps already had substantial user bases, so I conducted an in-depth audit of each to identify RiderLink’s value proposition.
The competitive research combined both generalized company research, including funding amount and ratings, with a breakdown of each app’s features and functionality. I collected this data within a spreadsheet to help me quickly identify areas where RiderLink can have an edge in the market.
Based on the competitors' current features, it was clear that RiderLink would be unique with its social environment. While other apps had similar functionality, such as hosting events, RiderLink could cater to more spontaneous riders through its real time location data and its in-app messaging, which most other apps lacked. However, it became clear that we would need to prioritize features for our MVP deadline, so we split our features into a list of ‘need to haves’ and ‘nice to haves.’
the market research
To ensure I covered all my bases, I also spent time conducting market research by looking into other studies done on motorcyclists and industry trends. This data was used to support the other research we found in the previous steps. Through this, I found that while the general demographic of motorcyclists is aging, younger riders are also on the rise. Of younger riders, women make up 20% of this growing demographic. This is something we kept in mind, especially when it came to emphasizing safety features.
The market research also showed that our location in Maryland would be beneficial. Pennsylvania, our neighboring state, had the 5th largest motorcycle demographic in the US, making it an ideal region for the initial roll out of the app.
the analysis
protopersonas & personas
During initial client meetings, I had created protopersonas based on conversations and his experiences with motorcycling. This helped outline our assumptions about the target users before starting research.
​
Using the survey responses and findings from the market research, I created updated personas with our validated findings. I was able to confirm that there is a market interest for RiderLink and that social motorcyclists struggle with coordinating groups. I also identified the need to match riders based on compatibility, not just location, and highlighted the need for safety features. The data also provided a new persona (50+ years old, high discretionary income). My team then used this second version of the personas to drive our design decisions in the next stages of the project.
red routes & user flows
The findings from my research also drove our red routes and user flows. I outlined the core features and tasks RiderLink will need to provide to meet user needs and base functionality. This list was then organized into red routes to help my team prioritize features for the MVP.
​
I next used the information provided in the red routes to create a list of user flows, which is where we started to see the app structure begin to take shape. After a few iterations and restructuring, I identified critical flows and optimizing the structure.
information architecture
Using the user flows, I next started to structure RiderLink's information architecture from a feature standpoint.
The first version was rather complex - I broken down sections of the app into Epics to help our developers and then detailed all features that can be found within the main and subpages. This version was used internally by my design team to ensure that all proposed features would fit within the scope of our project.
​
The next version of the information architecture that I created (below) was much simpler. While it still reflected the more robust architecture, which we continued to use throughout the design process, the condensed version helped us understand the core features of the app and was used to more effectively communicate the structure of the app with the client.
the design process
low fidelity wireframes
While our other designer focused on creating RiderLink's style guide and creating the marketing website, I took the lead on the low fidelity design process. I used the design deliverables I created above and began making wireframes for each page highlighted in the information architecture using Sketch.
The low fidelity designs helped my team visually communicate features and flows to the client, who was involved at every stage of the project. Although some proposed features needed to be sidelined for the next app iteration, we optimized the design and incorporated features unique to RiderLink, such as showing real time location of friends. Nearby riders were presented in list view rather than by geolocation on the map, which helped protect user locations from strangers. To help users link to events based on compatibility, fields were built out to show some of the most important characteristics riders look for, such as route type and riding style.
After creating four iterations of low fidelity designs and ensuring the client's business needs were met, our concept was ready for high fidelity designs.
high fidelity wireframes
Our UI designer took the lead on this portion of the project, transitioning my low fidelity designs into high fidelity versions to share with the client and send to our developers for the app launch.
