Background
Hyena split its software into several separate applications to demo ideas faster and offer customizable client solutions. By 2020, the strategy had run its course — the fragmented system created a steep learning curve for users and an unsustainable maintenance burden for engineering.
My Role
I led design for all software systems except the rider mobile app, working alongside a senior PM, a firmware manager, and ten engineers. For the service center feature specifically, I owned user flows and wireframes through handoff; a collaborating designer applied visual design to bring it to production.
The Problem
The task: find a solution for regional service centers to update e-bike configurations for after-sales services. The original proposal — giving service centers access to BTS, the factory assembly tool — would have required heavy customization and training we couldn't deliver in time.
We audited the existing system and interviewed 6 users across departments. Two findings stood out: e-bike information and management functions were scattered across separate applications, and there was no reliable way to identify a bike's model and settings from the bike itself.
Sequence modeling exposed the bottleneck: 80% of setup time was spent manually cross-checking the same information across multiple applications before any settings could be applied.
What looked like a feature request required rethinking the system's foundation — without it, any new feature would inherit the same fragmentation.
System-Level Redesign
Product Architecture
We consolidated from 3 applications to 2 — Hyena Management Tool and Hyena Manufacturing Tool — eliminating duplicated functions and creating a single source of truth for bike information. Engineering no longer had to maintain the same logic across multiple codebases, and the consolidated structure became the foundation for the product roadmap.
Bike Model Data Structure
A unified bike model structure serves as the data backbone — performing validation system-wide so assembly and service operations always reference consistent, accurate information.
The Shipped Feature
Access the Service Center Feature
The service center feature is integrated directly into the existing bike service tool via a top-left menu icon. A login gate enforces local regulatory constraints and lets us track service histories per regional center.
Select the Bike Model
Users select the bike model — by brand, name, or frame number — connect to the e-bike, and the system handles the rest.
Service the Bike
Once connected, the system surfaces full bike details — part numbers, firmware version, and whether re-configuration is needed.
Progress and status display throughout the update, with a warning to keep the bike connected until complete.
Impact
- Saved 50% of the time required to service and re-configure an e-bike.
- Delivered within 2 months by integrating into an existing tool rather than building new software.
- No additional training costs at regional service centers.
Reorganizing bike model data alone generated immediate positive feedback — users noticed the consistency before any UI changes shipped.
Takeaways
Observing the Root Cause
Software-hardware research requires following how users actually move through a physical workflow, not just observing interface interactions. The root cause here was never the UI — it was fragmented data.
The Best Solution
The best solution balances user need, business feasibility, and technical constraint. Integrating into an existing tool wasn't the most elegant option, but it was the one that could ship — and ship well.