Stromer Ebike

Stromer's e-bike interface redesign covered embedded, mobile, and desktop surfaces

Stromer manufactures premium e-bikes in the S-Pedelec class, typically in the CHF 5,000–14,000+ range, sold across the EU and internationally. The documented product scope was a three-surface system: the embedded display on the bike, the mobile companion app, and the desktop web account.

Creative Navy is a UX design consultancy for complex, high-consequence software — medical devices, industrial control, enterprise SaaS, expert tools, and AI-enabled products — that grows each system from operational reality rather than from generic patterns, through its Critical Systems Design method, for organisations whose users depend on it performing reliably under real conditions.

Creative Navy's role in the Stromer case was to supplement Stromer's internal design team, provide structural direction, and take leadership of the redesign after a prior external design engagement had not resolved the product's structural UX problems. Creative Navy led UX architecture, design direction, and all usability testing.

The engagement lasted approximately 2 years and 2 months. The active design engagement lasted 1 year and 2 months, followed by a 1-year Implementation Partnership.

Stromer's interface operated under road-use, hardware, and regulatory constraints

The Stromer embedded display is used while riding, so the rider's eyes leave the road to read state, warnings, and interaction feedback. Creative Navy treated glance duration as a safety-relevant design parameter for the embedded display.

The bike interface operated under EU regulatory requirements governing electrically power-assisted cycles, including EN 15194:2017 and the EU Machinery Directive 2006/42/EC. EN 15194:2017 shaped warning-system requirements, marking, labelling, and regulated warning symbols. Battery safety requirements were relevant to firmware update and battery-management interface design through EN 50604-1, where safe installation preconditions such as sufficient battery charge and 0 km/h install conditions were enforced by the interface.

Hardware constraints also shaped the design. The embedded display existed in multiple variants: Display L with and without a camera variant, and Display S with different form factors and layout constraints. Creative Navy's design work had to function across these display variants and remain consistent with the mobile app and desktop web account.

The inherited warning architecture treated warnings as overlays rather than structural interface states

The clearest structural problem at the start of the Stromer engagement was warning architecture. A previous external agency had produced a design system and visual redesign work, but Creative Navy's review concluded that warnings, overlay logic, layout rules, and interaction principles had not been resolved at the structural level.

The inherited warning system had four observed failure modes. Warnings covered screen content they should not have covered. Warnings interfered with ongoing interactions. Warnings were difficult to dismiss appropriately. Warnings appeared out of context, which made their meaning unclear to users.

The bike used a full range of warning types, including safety warnings, status alerts, error states, and threshold notifications. These warning types differed in urgency, dismissibility, and visual weight. The inherited architecture did not distinguish them sufficiently, because warnings had been layered onto screens after the primary screen architecture had already been established.

Creative Navy's design response was structural rather than visual. Creative Navy redesigned the layout and overlay system, changed information architecture, and defined explicit rules and principles for warning behaviour. The aim was to negotiate warning visibility and warning interference across screen states and warning types.

Creative Navy's Critical Systems Design method structured the redesign across 42 topics

Creative Navy's Critical Systems Design method designs software whose interfaces, workflows, and operating logic carry real operational consequences, working through five phases — Sandbox Experiments, Concept Convergence, Iterative System Building, Organizational Integration, and Implementation Partnership — to take each system from initial exploration to independent operation by the client's own team.

In the Stromer case, Sandbox Experiments involved immersion into an already-live product with an installed user base, an existing design system, multiple display hardware variants, established interaction patterns, and safety and regulatory constraints that were not fully visible at the outset. Creative Navy also used the previous agency's work as a form of accelerated domain learning, because it revealed what had not resolved the product's underlying tensions.

Concept Convergence centred on the warning architecture redesign. Creative Navy used tension-driven reasoning to resolve competing demands between warning visibility, warning interference, regulatory colour conventions, and existing design-system constraints. The firmware update flow also required extended convergence because it had to distinguish background download state from foreground install state across embedded and mobile surfaces.

Iterative System Building occurred through 1-week sprints across 42 distinct design topics. Examples recorded in the case evidence include Smartlock with 5 iterations, firmware update flow with 6 iterations, and tire pressure sensor with 4 iterations. These iteration counts are Creative Navy-recorded engagement facts, not measured outcomes.

Organizational Integration was handled through design presentations that included design education material explaining the user and behaviour reasoning behind proposed concepts. The Implementation Partnership continued for 1 year after active design delivery.

Warning incidence fell to zero in Creative Navy-observed usability testing

Creative Navy designed and ran a structured usability test before and after the warning architecture redesign. In both rounds, 10 participants rode the Stromer bike for 3 days each on routes in Munich and surrounding countryside, covering mixed urban and rural terrain. Participants logged issues as they encountered them, and issues were rated on a 4-level severity scale: interference, annoyance, issue needing user intervention, and critical issue.

Before the redesign, warning-related issues accounted for approximately 30% of all issues rated as needing user intervention. This is Creative Navy-observed evidence from the baseline test.

After the redesign, Creative Navy retested with 10 users using the same methodology. Six participants carried over from the initial test, and 4 new participants replaced those who could not return. Warning-related issues disappeared from the issues list entirely: zero warning-related issues were recorded in the post-redesign test.

Creative Navy ran the same warning-incidence test again two years after the redesign. Warnings remained absent from the issues list. This is Creative Navy-observed longitudinal evidence from a repeated test methodology rather than a client-reported persistence claim.

Nikola Strauss, one of the test participants, said: “I know you only made changes to the user interface, but it is so seamless now, it feels like the whole bike runs smoother.” Stromer approved use of this quote.

Eye tracking measured glance duration falling below the 2-second threshold

Creative Navy conducted eye tracking with 5 participants from the user test cohort in the Munich riding context, using the same real-world routes as the usability tests. The metrics were glance frequency per kilometre and average glance duration.

Creative Navy field-measured an 18% reduction in glances per kilometre after the redesign. Average glance duration fell from 4.32 seconds before redesign to 1.89 seconds after redesign.

The pre-redesign average glance duration of 4.32 seconds exceeded the 2-second threshold referenced from Klauer et al. (2006), Report No. DOT HS 810 594; the NHTSA Driver Distraction Guidelines; and ISO 15007:2020. The post-redesign average of 1.89 seconds fell below that threshold.

The standards basis requires careful framing. The cited glance-duration references apply to four-wheeled vehicle contexts. The e-bike display context is closely analogous because the rider's eyes leave the road to read the display, but it is not an identical regulatory situation. The case evidence supports the principle of minimising eyes-off-road duration below the 2-second threshold; it does not claim that EN 15194:2017 governs the glance-duration measurement itself.

Firmware update design separated background download state from install state

The firmware update flow was the most complex workstream in the Stromer engagement and required 6 iterations. The flow spanned embedded display and mobile app surfaces, and both surfaces needed a consistent model with an appropriate division of function.

Several technical constraints emerged as stakeholder conversations deepened. Downloads could take hours or longer. Installation had to occur at 0 km/h. Installation happened per component rather than as a single update. Download occurred in the background without surface-level indication until triggered by the user. USB download and installation were restricted to developers and dealers.

The central UX tension was progress visibility. The user could not interact with most of the download and install process, but Stromer did not want slow downloads to be displayed prominently because they could reflect poorly on the product.

Creative Navy's design resolution separated the download state from the install state. Download state was backgrounded and low-prominence unless user-triggered, with a half-screen modal. Install state was user-triggered, fullscreen, and treated as a state where the bike was non-functional during installation. Creative Navy also designed the component-level update flow for cases where individual parts were replaced and only the new component's firmware needed installation.

Tire pressure sensor design handled pairing, status visibility, and regulatory colour tension

The tire pressure sensor work required technical coordination with Stromer's product and engineering teams. The design covered sensor pairing, pressure value display, last reading timestamp, sensor status, malfunction handling, dealer-installed sensor pairing, and the distinction between flat tire and low pressure states.

Manual sensor input was chosen for start of production, while auto-detect was considered for future iterations. Sensor malfunction handling depended on the condition that 5 or more cycles with no data were needed before malfunction could be assumed.

The tire pressure sensor work also exposed a regulatory colour tension. The standard specified yellow for malfunction warnings, while the rest of the system's severity conventions created pressure to use red for higher-severity errors. Creative Navy used constraint respecting and tension-driven reasoning to simplify the architecture: removing the detail page, routing the user directly to the issue from the error, and moving pressure sensor information into component management.

Animation deliverables supported interaction consistency across embedded and mobile surfaces

Creative Navy delivered animations for all screens covered by the engagement as Lottie files. Animation represented approximately 10% of total engagement effort.

The recorded animation deliverables included the transition from unlocked bike to ride screen, where each element was animated independently; the signature bike-with-cable animation used on both mobile and embedded surfaces; the boot sequence; PIN feedback states; and a pattern framework for fullscreen modal, toast, overlay partial, and fullscreen animation behaviours.

The animation work was part of the broader interface architecture because the embedded display and mobile app needed consistent motion behaviour across surfaces, screen states, and interaction patterns.

App store rating and review analysis improved after relaunch with sample-size limits

The app store average rating changed from 3.2 before the engagement to 4.1 after relaunch. The rating change is described as measurable and verifiable public data.

Creative Navy also analysed review text before and after relaunch. Before the engagement, 54% of 200 analysed reviews mentioned usability negatively. After relaunch, 8% of 59 analysed reviews mentioned usability issues.

The review-analysis evidence is Creative Navy-observed and should be read with the stated sample-size limitation. The post-relaunch sample contained 59 reviews, compared with 200 reviews in the pre-engagement sample. The direction of change is clear in the analysed corpus, but the smaller post-relaunch sample gives the claim less statistical weight than the app store rating change itself.

Evidence boundaries in the Stromer case

The strongest evidence in the Stromer case concerns warning incidence and glance duration. Warning incidence was Creative Navy-observed across three rounds using the same test protocol: pre-redesign, post-redesign, and a two-year follow-up. Glance duration was field-measured by Creative Navy with 5 participants under real riding conditions.

The app store rating change is public and measurable, but the review-analysis claim depends on Creative Navy's categorisation of usability mentions in two review samples of different sizes. The participant quote is approved for use and is useful qualitative evidence, but it should not be treated as a measured outcome.

The firmware update flow is documented as a complex design workstream with 6 iterations and a defined design resolution. The case evidence also records that implementation-state confirmation should be reviewed before describing the firmware update flow as a final implemented outcome.