Streamlining Access to Cycling with Spoke
A centralized tool that connects users to bike shops in the US based on their needs, while earning discounts and rewards.
Figma
Having worked for a kid’s bike company for two years, I noticed the barrier to entry for cycling can oftentimes feel confusing and expensive, especially as a family. Bike maintenance is critical to safety and longevity, but adds to the already steep cost of bike ownership while renting depends on accessibility.
Spoke is a concept app that aims to connect riders to bike shops in the US based on their needs, making cycling more financially accessible by incorporating loyalty perks.
I designed and prototyped Spoke from start to finish, confirming validity by conducting competitive audits and several rounds of usability studies.
What made the barrier to entry so high?
Disjointed options create a fork in the road
Users have to weigh pros and cons of two disjointed options varying in affordability, accessibility (location dependent) and reliability.
Renting
vs
Purchasing
Not a one-stop shop
Users with an array of needs are faced with piecemeal processes-- finding, sifting through, and consulting multiple retailers in varying locations all to purchase and maintain or rent their bikes.
Online retailers improve accessibility, but introduce shipping constraints that make at-home assembly a requirement. Novices are left to consult local experts for proper assembly and the likelihood of missing or malfunctioning parts increases.
Improve longterm participation in cycling by presenting users with clear information in a convenient, trustworthy, and unified tool with financially accessible options.
Mapping the route
The starting point
Since the goal was long term participation, I started with shopping and loyalty flows, identifying four core tasks that needed to be considered.
Find a bike shop
Add a bike to the cart
Check out
View rewards
Designing with ambiguity
With no existing product or clear starting point, I utilized the design thinking framework and referenced mapping, loyalty, and booking tool patterns to create prototypes users could easily understand that could be tested at an early stage.
Putting it to the test
2 unmoderated usability studies reveal one major barrier
I documented click paths and assessed time on task, error rates, task completion, and verbal feedback on both low and high fidelity prototypes, but consistently encountered 3 pain points and 1 significant barrier.
Duplicate features
Redundancy created a high interaction cost
Users confused “Shops” with “Shop”
Redundant components
Duplicate features
Redundant filters in search and filter menu were confusing
User Control
Lacking user control
Checkout lacked edibility and backward navigation
Map lacked interactivity that could provide an additional layer of context
Checkout
High risk tasks happened too quickly
Checkout happened too quickly
Finding Shops
Disjointed search not functional enough for users advanced needs.
No filters for task type, bike type, gear, parts, or demographic category
Recent and favorite not relevant for new users
Not obvious search is intended for location purposes only
Search was the biggest barrier to using the app
I originally intended search to be used for location purposes, but placeholder text lacked context that might imply use. I also thought filters would be the best way to refine results, but research revealed most users interacting with new products utilize search to complete tasks.
80% of users tested actually wanted to use search to refine results.
Pump the brakes
I began re-working search, but realized half-way through that I only considered the shopping flow and my goal was to create a centralized tool
I needed to consider flows and queries for users seeking maintenance and rentals as well.
How would someone search for a service provider?
What about a rental?
Should these be separate flows?
A full tear down
Switching to a database model
I initially implemented a traditional hierarchical model commonly used in retail, but it became too complex when adding in maintenance and rentals.
Since this was a new product, I had the luxury of scrapping the information architecture completely without the heavy lift and resources that might be required to rebuild an existing product.
By switching to a database model, users would be able to refine queries and connect with shops based on their unique tasks with a single unified search.
One search for all
A contextual, unified search accommodates flexible queries with high-quality results and clear use
The primary search invokes a full screen menu, forcing users to slow down and make intentional decisions while pre-filled functional data provides context for zero-query results. Collapsable forms imply progression while maintaining visibility and edibility throughout the process.
“Shop” is the default menu as this is the entry point for most new users.
Dynamic results
Implementing dynamic results screens based on the user’s task provided the opportunity to add more relevant filters within each flow, increasing the likelihood of a successful search.
Shop, Service, or Rent flows
Users can bypass the primary search and enter a task-specific flow with segmented searches or browse content relevant to their task.
Returning users will find “Favorites” and “Recents” on these screens if applicable, without distracting new users in the primary search.
Interactive map
Applying widely used interaction patterns like selecting pins to reveal store details and pulsing “current location” pins allow users to orient themselves and make sense of results.
As the app evolves, I imagine negative space on store detail bottom sheets could be utilized to inform users of time sensitive sales or reward opportunities to drive traffic.
Service tabs
Service tabs communicate each store’s unique services without navigating back and forth deep within a flow.
Intentionally added friction & user control
Intentional friction was added to the checkout flow with confirmation screens and loading states to build trust. Collapsable and editable menus provide a sense of progression and allow users to confirm details at any stage.
What I learned during this process
Click paths
While testing, I found user actions often differed from verbal feedback.
This forced me to rely heavily on click paths that were able to capture user errors and thought processes I might have otherwise overlooked, ultimately proving to be the most impactful indicator measured in my research.
Apps vs web
With a background mostly in desktop and mobile web, designing a mobile app forced me to get creative. I had to deeply understand user journeys in order to simplify screens and break tasks into multi-screen flows that felt intuitive.
I learned to be more intentional with interactions, using friction to my advantage while also considering less traditional information architecture models.
Advanced search
Users have extremely high expectations of search tools to solve a wide variety of problems, requiring designers to create flexible solutions to assist users more than I realized.
In the future I’ll need to consider what problem search is solving, plan better for all use cases, and understand how different search patterns might help solve these problems.
Collaboration
I love designing as a team, gaining valuable insight from peers and leaders, and understanding problems from a different vantage point.
Working on a concept as a side project on my own was a challenge, but I learned to rely on community.
Consulting a design community after wrapping the project up helped me to refine the visual design and remind me of things I overlooked like updating values to better convey realistic depth in 2D.