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. Regional service centers, in particular, had no application built for the work they actually did day-to-day.
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 the end-to-end design — research, user flows, and interaction design through handoff — partnering with a visual designer on production polish.
The Problem
The task: give regional service centers a reliable way to identify, configure, and update e-bikes after sale. The original proposal — granting service centers access to BTS, the factory assembly tool — would have required heavy customization and training we couldn't deliver in time, and would have exposed manufacturing-only controls to a much broader audience.
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. Technicians needed a single flow that handled identification, connection, and configuration end-to-end — without leaving the tool they already worked in.
Designing the Service-Center Feature
The feature lives inside the existing bike service tool, accessed from a top-left menu icon. Rather than introduce a new application, we built a guided sequence — login → identify → connect → review → update — that mirrored the technician's physical workflow at the service bench.
Accessing the Feature
A login gate enforces local regulatory constraints — only authorized regional centers can re-configure bikes — and lets us track service histories per center.
Identifying the Bike
Technicians select the bike model by brand, name, or frame number. The search-first approach was deliberate: in interviews, technicians told us they almost always had at least one of these data points in hand from the work order, but never a consistent one — so the same field had to accept any of them.
Connecting Over Bluetooth
The pairing handshake spans both hardware and software: the technician double-clicks the power button on the bike's HMI to enter pairing mode, then clicks Connect in the service tool. The tool scans for nearby bikes, and once paired the HMI flashes its indicator light to confirm the right bike is on the bench. The bike's live data populates the next screen automatically — no manual entry of identifiers, no jumping between apps.
We surface a single visible connection indicator at the top of the workflow so technicians can always tell at a glance whether the tool is still talking to the bike — particularly important once an update is in progress.
Reviewing Bike Status
Once connected, the system surfaces the full bike details — part numbers, firmware version, current configuration — and flags whether re-configuration is needed. Everything the technician used to gather from three separate applications now loads on one screen, sourced directly from the bike.
We also redesigned the bike status diagnosis workflow as part of this effort — outside the scope of this case study, but happy to walk through it if you're curious; feel free to reach out.
Updating the Configuration
Progress and status display throughout the update, with a persistent warning to keep the bike connected until complete — interrupting an in-progress update can leave the controller in an unrecoverable state, so the action becomes non-cancellable past a certain threshold.
A clear completion state closes the loop and writes the service event to the bike's history.
The Bike Model Data Structure
The feature's flow — search by brand, name, or frame number; pair; auto-populate live bike data — assumes one thing the existing system couldn't provide: that any reference to a bike resolves to the same canonical record.
So we shipped a unified bike model structure as the data backbone alongside the feature — performing validation system-wide so assembly and service operations always reference consistent, accurate information. Without it, "identify the bike" would still have meant cross-checking three sources.
Impact
- Saved 50% of the time required to service and re-configure an e-bike.
- Delivered within 2 months by extending an existing tool rather than building new software.
- No additional training costs at regional service centers — technicians stayed in the application they already knew.
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 and a missing end-to-end flow.
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.