Halving E-bike Servicing Time with a Single Service Flow

Background

Hyena builds the electronics and software that turn an ordinary bicycle into an e-bike. By 2020, that software had splintered into a suite of separate applications — one for manufacturing, one for configuration, one for diagnostics, one for the rider — each built to demo ideas quickly and tailor solutions per client.

The strategy had run its course. The fragmentation created a steep learning curve for users and an unsustainable maintenance burden for engineering — and it left regional service centers, the people who actually repair bikes after sale, as the one audience with no application built for the work they did every day.

My Role

I led product design across Hyena's software systems — everything except the rider mobile app — working alongside a senior PM, a firmware manager, and ten engineers. On the service-center feature I owned the work from research through the user flows — interviews, sequence modeling, and the end-to-end flow — and drove the product decisions for what shipped, then partnered with a UI designer who took it through interface design and engineering handoff.

The Problem

The brief was concrete: give regional service centers a reliable way to identify, configure, and update an e-bike before sending to the dealer. No tool did that today, so technicians improvised across whatever applications they happened to have access to.

I audited the existing system and interviewed six users across departments to see how service work actually happened. Two findings stood out, and they compounded each other:

• E-bike data and controls were scattered across separate applications. No single tool held identity, status, and configuration in one place.
• There was no reliable way to read a bike's model and settings from the bike itself. Technicians reconstructed them by hand, from the work order.

Sequence modeling put a number on the cost of all that reconstruction:

The problem wasn't a bad screen. It was a missing flow.

The Decision — Extend, Don't Rebuild

There was an obvious shortcut, and I argued against it.

The original proposal was to give service centers access to BTS, the factory assembly tool. It already knew how to write bike configurations, so why not reuse it? Two problems made that the wrong call. BTS was built for a controlled factory line — pointing it at hundreds of regional centers would have meant heavy customization and training we couldn't deliver on the timeline. And it would have exposed manufacturing-only controls to a far broader, far less controlled audience, on hardware that carries people at 20 mph.

So I made the opposite bet: build the service flow inside the bike service tool technicians already opened every day, and expose only what a service center actually needs. It wasn't the most elegant architecture — a cleaner world might have had one purpose-built application — but it was the one that could ship in the window we had, with no new tool to learn and no factory controls left exposed. The constraint became the design.

Designing the Service-Center Feature

The feature lives inside the existing bike service tool, one click from the home menu. Instead of a new application, it's a guided sequence — login → identify → connect → review → update — that mirrors what the technician physically does at the bench.

Before the redesign, a technician assembled this picture across tools. After it, the same work is one focused surface that shows only what the job requires:

I also designed the flow around the moments that go wrong — a bike that won't answer, data that disagrees with the cloud record, firmware that's out of date — not just the happy path.

The screens below show that flow in the shipped tool. I owned the sequence, the states, and the behavior at each step; a UI designer took the flow into its finished interface.

Accessing the Feature

A login gate does double duty: it enforces the regulatory constraint that only authorized regional centers may re-configure bikes, and it attributes every service event to a center so histories stay accountable.

Identifying the Bike

Technicians search by brand, name, or frame number. The search-first, accept-anything field was deliberate: in interviews, technicians almost always had at least one of these data points from the work order — but never a consistent one — so the same field had to take whichever they had in hand.

Connecting Over Bluetooth

The pairing handshake spans hardware and software. The technician double-clicks the power button on the bike's HMI to enter pairing mode, then clicks Connect in the 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 hand-entered identifiers, no jumping between apps.

A single connection indicator sits at the top of the flow so a technician can always tell at a glance whether the tool is still talking to the bike — critical once an update is in progress.

Reviewing Bike Status

Once connected, one screen shows the full picture — part numbers, firmware versions, current configuration — sourced directly from the bike, and flags whether re-configuration is needed. The three-application scavenger hunt collapses to a read.

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 stay visible throughout, with a persistent warning to keep the bike connected until the write is done. Interrupting an in-progress update can leave the controller in an unrecoverable state, so past a threshold the action becomes non-cancellable — the interface refuses to let a technician brick a bike.

A clear completion state closes the loop and writes the service event to the bike's history.

The Bike Model Data Structure

Every step above — search by any identifier, auto-populate live data, validate against the record — assumes one thing the old system couldn't guarantee: that every reference to a bike resolves to the same canonical record.

So alongside the feature we shipped a unified bike-model structure as its data backbone — validated system-wide, so assembly and service always read consistent, accurate information. Without it, "identify the bike" would still have meant cross-checking three sources; the interface would have been new, the problem unchanged.

It was also the part users felt first. Reorganizing the model data generated positive feedback before a single new screen shipped.

Impact

1. Half the servicing time. Collapsing identify–connect–configure–update into one flow removed the cross-checking that had dominated the old process.
2. Shipped in two months. Extending a tool technicians already used — instead of building new software — is what made that timeline real.
3. No new training cost. Regional centers stayed in the application they already knew, so the learning curve was close to zero.

Reflection

1. In hardware-software work, follow the body, not the screen.
   The bottleneck here was invisible in any single interface — it only surfaced when I traced how a technician physically moves through a service, tool by tool. Sequence modeling, not usability testing, is what named the real problem: fragmented data and a missing end-to-end flow.
2. The shippable solution beat the elegant one.
   A purpose-built application would have been cleaner on paper. Extending the tool technicians already knew was less elegant and far more real — it fit the timeline, the training budget, and the safety constraints at once. Senior design is often choosing which constraint to design inside, not wishing it away.
3. Design the unhappy path, or you haven't designed the tool.
   For a service technician, the failure modes — a bike that won't pair, a write that can't be interrupted, a record that disagrees with the hardware — aren't edge cases; they're the job. Building dongle detection, retry, cloud validation, and a non-cancellable write into the flow is what made it trustworthy on a real service bench.