Cycling made easy
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.
The Spoke app aims to connect riders of all experience levels to bike shops in the US based on their needs and make cycling more financially accessible by incorporating loyalty perks with one convenient, centralized tool.
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?
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 provide 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, it made sense to start with shopping and loyalty flows.
I identified four core tasks that needed to be considered including finding a bike shop, adding a bike to the cart, checking out, and viewing rewards.
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 common patterns for location, loyalty, and booking tools to create low fidelity prototypes I could test at an early stage.
Putting it to the test
User testing
I conducted two rounds of unmoderated usability studies on low and high fidelity prototypes documenting click paths and assessing time on task, error rates, task completion, and verbal feedback to ensure core tasks could be completed.
The studies revealed four consistent, high-impact pain points, including one significant barrier.
Duplicate features
Redundancy creates a high interaction cost
Users confused “Shops” with “Shop”
Redundant components
Duplicate features
Redundant filters in search and filter menu
User Control
Lacking user control
Checkout lacked edibility and backward navigation
Map lacked interactivity
Checkout
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 problems
The search feature was the biggest barrier to using the app.
I originally thought filters would be the best way for users to refine results, but research revealed that most users interacting with new products utilize search to complete tasks.
80% of users wanted to use search to refine results, but I had only intended it to define location. Additionally, placeholder text provided no context conveying it’s use for location.
Pump the brakes
Losing sight of the goal
While re-working search, I realized I was only considering 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, which 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.
Ready to hit the road... or trail
One search for all
Previous iterations intended for users to utilize Search to define location and Filters to refine results, resulting in abandoned tasks, high error rates, and increased time on task.
I implemented a unified and contextual search that invokes a full-screen, tabbed menu with 3-4 relevant search forms for each key task (shop, service, and rent).
The full screen menu forces users to slow down and make intentional decisions while pre-filled functional data provides context for what a zero-query search will return. Collapsable forms imply progression and provide 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 choose to bypass the primary search and enter a task-specific flow that still allows them to find a shop or browse additional information relevant to their task.
Returning users will find “Favorites” and “Recents” on these screens if applicable, without distracting new users during 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.
In future iterations, 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 in a clear and concise manner without the need to navigate 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.