Company:
Bike Center
Year:
2024
Duration:
3 Months
The Challenge
When the Bike Center Zaporizhzhia team first reached out to us, they showed us their "system." And by system, I mean a beautiful mess of Excel spreadsheets, paper notebooks, and a manager named Oleksiy who somehow remembered everything in his head. "We need something better," they said. "Oleksiy is great, but he wants to take a vacation someday."
The challenge was real: 50+ bikes, hundreds of rentals per month, peak season chaos, and zero digital infrastructure. Customers were calling, walking in, and sometimes just grabbing bikes because "I booked it yesterday, I swear!" The team was drowning in Post-it notes and phone calls.
Discovery
My fellow designer and I spent a week just hanging out at the rental shop. We watched managers juggle phone calls, search through papers, and perform what can only be described as "administrative parkour."
One afternoon, we witnessed a customer argue for 15 minutes that he returned the bike "in perfect condition" while the manager scrolled through photos on his phone trying to find evidence of a broken derailleur. That's when we knew: this system needed to be bulletproof, fast, and have built-in proof of everything.
We interviewed five managers, two mechanics, and even some regular customers. Turns out, everyone had complaints:
Managers: "I can't see which bikes are actually available right now"
Mechanics: "Nobody tells me when bikes need maintenance"
Customers: "I booked online but they said they have no record"
Owner: "I have no idea if we're making money or just keeping busy"
The funniest moment? When one manager showed us their "backup system" - a whiteboard with bike numbers written in marker. "What happens when someone erases it?" we asked. "We pray," she said.
Legacy System
Before we started designing, we had to understand what they were currently using. Spoiler alert: it was a Frankenstein monster of outdated software that looked like it was designed in 2003 and hadn't been updated since.
The old system was essentially a glorified table with no visual hierarchy, confusing status indicators, and a color scheme that can only be described as "aggressive beige." Finding a specific booking required scrolling through hundreds of rows, and God forbid you needed to filter by date - that feature simply didn't exist.
The best part? The system would randomly log you out every 20 minutes. One manager told us she had developed a Pavlovian response to the logout screen - she'd automatically reach for her coffee cup every time it appeared. "At least I stay hydrated," she joked.
Solution
Working closely with my design partner, we mapped out the core workflows:
Quick status overview - managers needed to see availability at a glance
Fast booking creation - the average call lasted 2 minutes, the system needed to be faster
Damage documentation - photo uploads and condition tracking before/after rental
Maintenance scheduling - bikes needed regular checkups, not crisis repairs
Revenue analytics - the owner wanted to know which bikes made money and which collected dust
We also discovered some quirky requirements. Like the fact that some customers were "blacklisted" (too many late returns), but managers needed a diplomatic way to handle it. We ended up designing a subtle warning system that didn't scream "THIS PERSON IS BANNED" but gently suggested "maybe require a larger deposit."
Prototypes
Before writing a single line of code, we built fully interactive prototypes. These weren't just pretty pictures - they showed exactly how the system would respond to user actions.
We animated state changes - how a bike card transforms when you change its status, how the dashboard updates when new data loads, how error messages appear and dismiss. These micro-interactions seem small, but they make the difference between a system that feels clunky and one that feels responsive.
The development team actually thanked us for the prototypes. "Usually designers throw us static mockups and we have to guess how things should work," the lead developer said. "This time we knew exactly what to build."
Dark-Light Mode
We built the entire system with theme flexibility in mind. Using our variable-based design system, switching between light and dark modes was seamless. The same semantic tokens (variables) that defined colors in light mode automatically adapted to dark mode values.
By leveraging Figma variables, we created a single source of truth for theming. Change one variable, and the entire interface updates instantly. This approach made it incredibly easy for developers to implement theme switching without hardcoding color values.
This wasn't just about aesthetics - many managers worked late shifts, and dark mode reduced eye strain during evening hours. The system remembers user preference and applies it consistently across all screens.
Dashboard
The dashboard became our hero screen. We designed it to answer the three questions managers asked every morning: How many bikes are available right now? What's happening today? Are we making money?
We used card-based layouts with clear visual hierarchy. My colleague came up with a brilliant idea - color-coding bike statuses with traffic light logic. Green = available, Yellow = maintenance soon, Red = in repair, Blue = currently rented. Simple, but effective.
One manager later told us she now starts her day with coffee and the dashboard. "It's like a morning newspaper, but useful," she said.
Table Design
Despite our love for cards and visual interfaces, sometimes you just need a good old-fashioned table. But we weren't going to give them the legacy system's nightmare table.
Our table had fixed headers, sortable columns, inline editing, and contextual actions. We added customizable column visibility and smart pagination.
The color coding carried over from our card design. Status indicators use the same traffic light system, so users don't need to learn a new visual language.
My colleague's favorite detail? The row hover state that expands to show additional information. It's like a tooltip, but smarter.
Team & Collaboration
This project was a true collaboration. While I focused heavily on the dashboard and analytics components, my design partner brought incredible insights into the booking flow and maintenance systems. We challenged each other constantly - some of our best ideas came from disagreements about "should this be a button or a link?"
We worked closely with:
Development team: Weekly syncs to ensure designs were technically feasible
Bike Center staff: Monthly check-ins to validate our assumptions
Real customers: User testing sessions that humbled us regularly
The project taught me that good design isn't about making things pretty - it's about solving real problems for real people. And sometimes those people just want to rent a bike without their manager having a mental breakdown.
Work in Progress
The MVP successfully launched and is currently helping Bike Center Zaporizhzhia manage rentals in real-time. But we're not done yet. Based on user feedback, we're continuously iterating and adding features.
Current development includes automated maintenance reminders, customer loyalty programs, and integration with popular booking platforms. The beauty of building a solid design system from the start is that adding new features doesn't break the existing experience.
We used Figma for all design and prototyping work, with a token-based design system documented for the development team. The responsive approach prioritized mobile-first design with component-level adaptability.