Rotate your device or view case study on desktop

How I doubled expected
registration and app
sign up in 3 months

Sprocket: A native, mobile first application for reporting missing bicycles.
sprocket hero landing image
sprocket hero search image
sprocket hero stolen bike image
how it started

The Backstory

In 2017, Ryan H., the founder of Sprocket came home one day to find his garage had been broken into and his bike was stolen.
After looking for a recovery community, what he discovered was a convoluted, intricate network of social media groups devoted to stolen bikes.
Ryan reached out to me to consult on the design of Sprocket.
UX / UI Skillset leveraged
Competitive Analysis
Research
wireframes
prototypes
Surveys
Personas
Priority Mapping
mockups
Unmoderated testing
Sketching
User Interviews
User flows
Tools Used for Sprocket
73% of bikes stolen at street level were reported locked by owners.
154,009 bikes were reported stolen in the U.S. in 2019 according to the FBI.
An estimated 80% of US bike theft victims don’t report the crime to the police.
mind maps & market research

The Client Challenge

In a time when smartphones are ubiquitous, there is no native mobile report and recovery solution for missing and stolen bikes.
I spent this phase doing market research, and gap discovery of the products similar to product.  
After an exhaustive market research, I found that the current competing products lack elements in four different areas: availability in the US, a native mobile app, stolen bike feed, and messaging capabilities.
competitive analysis
sprocket app comparison
Mind mapping is one of my favorite techniques when it comes to UX research & ideation. It gives me an early glimpse on possible application architecture(s), without heavy cognitive load.
connecting the dots
sprocket mind map
user research

The UX Process

This was a full-scope research and design project. I conducted comprehensive discovery and research including competitive analysis, interviewing and surveying users, empathy mapping, and feature prioritization.
The key takeaway is that valuable knowledge on how to prevent bike theft is scattered online and not readily available to all cyclists. This lack of awareness leaves them vulnerable:
They don't know how to check if a used bike is registered stolen
They're unsure how to report a stolen bike
They lack documentation of purchase or serial numbers
Cyclists don't know where to register their bikes
sprocket unregistered user flowsprocket registered user flow
Where research & design intersect

Iterate & Conquer

I use a "start loose, finish tight" approach when it comes to design iteration with Sprocket. I also brainstorm in, mind maps, outlines before diving into any design software, or sketching layouts on my iPad before any high-fidelity mockups.
This initial looseness lets me explore freely, change direction easily, and avoid tunnel vision. I also find that sketching is also a low consequence avenue for exploration.
After ideation, I let user testing, both un-moderatedmoderated, informed my final design choices, based on user feedback.
Start loose, finish tight design principle
design evolution through iteration
sprocket initial sketch design
sprocket low-fidelity design
sprocket mid-fidelity design
sprocket high-fidelity design
real problems require real solutions

The Solution

I helped turn the client’s vision, a comprehensive, navigable mobile theft and mitigation platform, into a reality. The end result provided a simple, unique solution for the client.
We expected 1,500 registrations and signups in the first 3 months and received double that.
We predict that getting buy-in from universities, police departments, and bike retailers helped Sprocket signup and adoption rates.
Sprocket app
Sprocket app
Sprocket app
High Fidelity screens
Sprocket app
Sprocket app
Sprocket app
Sprocket app
Sprocket app
Sprocket app
Sprocket app
Sprocket app
Sprocket app
plans are great, until they change

Challenges

project challenges
Having previous familiarity with existing bike registration applications, I had to identify my own design biases to ensure I wasn’t replicating existing solutions 
project changes
I didn’t take accessibility into account from the beginning. Some of my elements weren’t ADA-compliant, and I could have used a contrast checker to avoid wasted time and resources.