With over three years of user calls compiled in our research DB, we evidence of a growing trend regarding our devices' usability– riders were finding the device itself a poor UX compared to their smartphones. The insight wasn't that people didn't like the UX of the software itself, rather they figured the smartphone would be a better location to move out-of-ride configuration. This trend proved to be a reflection of our evolution from an early-adopter product to one finding mass-market appeal.

The early adopters, who were critical to our initial growth, tended to be tech-experts, preferring the Karoo's ability to act as a standalone device. Over time, cyclists started buying our product not to be tech-evangelist, but to have a better, simpler experience. Trying to cram advanced configuration experiences onto the 3.2” touchscreen led to disappointing, difficult flows for the average rider. Often times this meant watering down feature sets. One example of this was our route-planing on device, which made for a painful way to plan the next ride. Through Jobs-to-be-Done theory and analysis, we identified and validated that for many users, it's important for them to minimize time interacting with the Karoo when away from the bike. In other words, if they don't immediately need the Karoo for biking, they'd prefer not to be using it. Configuration should instead get moved to the riders most comfortable touchpoint– their phone.

At the same time, we were identifying tempting product opportunities with Jobs-to-be-Done Theory that were constrained by the Karoo's SIM-only internet connectivity. The vast majority of riders weren't going out and being SIM cards with internet plans for their cycling computer. This severely limited any benefit our team would see by developing internet-connected features. It was clear that moving configuration away from the device would be a major usability improvement, and moving internet connectivity to the riders' phones would unlock new product opportunities. The convergence of these two facts led to a strong case for investing in mobile resources, building out this new "companion app".

This project had been on the back burner until I was given the task of figuring out our next generation device's feature set– [ Read about the next gen Karoo here]. Upon doing quantitive analysis of our Jobs-to-be-Done findings, there was enough potential market opened up by a phone-internet bridge that we could justify allocating resources to the project.

Once the initiative started, there were a few main tasks and problems to solve:

• What does a mobile app look and feel like within the SRAM / Hammerhead design language?
• How would a Hammerhead iOS app translate to Android, both functionally and aesthetically?
• How does moving configuration away from Karoo and onto smartphone change the onboarding process previously established?

Early on in the project, I build out a modified version of the official Material 3 and iOS 17 Figma Design systems. Using these base systems, I input our own design tokens using the new Figma Variables. The base colors and styles in iOS 17 and M3 projects were overridden by our tokens. On top of this, I paired up similar components between each system to give us a reference when translating designs between iOS and Android.

One of our key goals with the cross-platform design system was to leverage pre-existing styles and components where available. This was a learning from our past experiences building up as a small product team. Over time we saw our one-off designs fail the test of ongoing development. As a small team, we didn't have the privilege of having people overseeing each component and analyzing the consequences of each change. I  was the design system team, and the research team, and the design team. This meant I had to face my mistakes of unmaintainable choices. My experiences in this department led us to choose design patterns that made sense across touchpoint. My decision making was backed up by some key developers who acted as design advocates.

Early on designing the informational architecture, we found that managing potentially multiple Karoo's, associated with multiple accounts, across multiple smartphones, to be the major foundational design challenge of the project. What we came up with is a design principle that any state where connection is critical must show relevant connection state. In this context, the context state must include:

• Is the current Karoo set to be the Karoo with and active data stream?
• Are there different accounts associated with each Karoo?
• Is the current Karoo actively connected and streaming data?

To satisfy these criteria, I built a series of micro-components that convey status. We called this the  persistent connection status indicator. These reusable elements can adapt to all screens where connection is critical.

After solving for this foundational connection issue, we built out all variations of configuration states for the Karoo, users, and relevant data objects, like sensors. These additional pages were made to become extendible for future features.

The Karoo Companion App is set to release Spring of 2024.