Product Thinking

What is Cannondale’s Wheel Sensor?

It’s a device sold on select Cannondale bikes or one that you can add to any bike after market where it records the distance and time of every ride. When the Cannondale app launched in 2019 (on iOS and Android), the wheel sensor was a focal point. The app used information from the sensor to then tell the user their bike ride data. The device is manufactured by Garmin. Every now and then, a firmware update comes out and when that happens, the app lets the user know.

Wheel Sensor Overview.png

What’s the issue?

Whenever a firmware update was needed, users were constantly running into problems. They would often end up writing to the company in order to get their questions answered as to why a firmware update failed. This caused frustration on the customer end but also costed the company valuable time in resources writing back to users individually. The app stores were also getting flooded with angry users along with their low star reviews.

User Feedback… not so great

Scanning the reviews on the Apple App Store, I knew a lot needed fixing. The priority was to fix the bugs. After that, the overall experience.

Reviews.jpg

Why does the business care about this?

With so many bugs causing user frustration, the app has not been shedding a good light on the Cannondale brand. By addressing the bugs and overall user experience, the business can then confidently market the app and continue to gain brand loyalty well after the purchase of a bike.

My team

My team consisted primarily of software and hardware engineers and product managers

The team.png

To start, I needed to know how everything worked technically

In order to do that, I created technical flowcharts with the software and hardware developers. We would have working sessions and I would be putting together a flowchart on the screen as developers would give me more information and answer open questions. The visual of the flowchart was incredibly helpful while figuring out how the tech on the backend actually worked and then later on, using it as a guideline for the UI.

Visual Design

Pattern libraries and OS guidelines

Existing pattern libraries consisted of both iOS and Android human interface guidelines. It was important to maintain the design if and when necessary of both operating systems. 

The Cannondale style guide is a constant work in progress within our small team of designers. We have brand guidelines and a style guide for the website that is fairly buttoned up. However, the app required many new elements. So a new section of the Cannondale style guide was created that was app specific.

Some visual challenges…

Trying to simplify the screens was my biggest challenge. There was A LOT of information that I needed to digest and parse through. Designing a firmware update doesn’t sound super sexy and it’s not something most people think of when they think of great design. I worked with a team of almost all engineers so requirements were very wordy and often times, people in the room had strong opinions on why certain instructions should or should not be on the screen. I took that internal direction and feedback and played with the layout over and over. Removing language when it repeated itself and often replacing words with icons to create some visual hierarchy.

Interaction Design

A few iterations of the start screen

This screen was meant to display all the requirements before starting the firmware update. There were many but some of those we could figure out on the backend and alert the user through dialogs. What we couldn’t find ourselves, we had to display here.

iterations.png

The progress screen

Progress.png

Prototype

here

Prototype.jpg

What I learned

This was the first time I spent a significant time designing a firmware update experience. I learned that there are a lot of moving parts in the process and it takes a great deal of organization within internal teams as well as third parties to iron out the kinks. In this case, I found that it was nearly impossible to start designs without talking extensively with the hardware and software team and to really nail down the technical flowchart. Being in a room with many very smart engineers, I also learned to trust my own abilities as a product designer. Their technical contributions and knowledge of the project did not replace my expertise as someone who can get inside a users head and make a complex problem seem so easy and seamless when in use.