Custom Alerts for ELEMNT

Use cases

Early concepts from Wahoo’s product team kind of limited the feature to food & drink. Which is great—and is representative of how the majority of our users will use the feature.

However, if we’re calling this custom alerts, we should enable users to make them TRULY custom and in accordance with their needs. We need to support everything.

After reviewing use cases, I decided the best way to move forward with custom alerts for its initial launch was to include (1) a single-fire alert (happens once and only once ), and a repeatable interval alert (like eating every 1 hour).

These set my precedents for moving forward with the design process.

Unfortunately I am missing examples of my highly iterative designs for this project. What you’ll see below is live implemented in-app with a walk-through of iterative process and decisions

Companion app set-up of custom alerts includes…

Add an alert

The most core piece of the experience — adding a new, specific-to-you alert. Simple is best.

Via the Workout tab;

Select custom alerts

Manage selections

→

 

Main custom alerts modal

First time UX / onboarding

Main toggle on/off page

→

First time user experience — onboarding

Previously our users weren’t able to add anything custom like this in the companion app. They were able to grab routes and workouts (but those were already made somewhere else).

For a first-time experience, I felt users needed some guidance as to how cool this is; example use cases and prompting to make it your own.

Add — bottom drawer modal

I iterated a lot with how best to organize & display the add custom alert content.

At the end of the day, a bottom drawer modal was the easiest to complete a full “add alert” in the least amount of time.

• Proximity to the bottom of the screen for easy tapping

• Not needing the full screen worth of real estate

Components of the bottom drawer modal

Limited text box

Our bike computers are compact; a character limit was a necessity. After trial and error, 50 chars was a good long message length.

Add a “ghost” message to the empty state (“Finish a water bottle”) to spur ideas.

Interval field + type dropdown

Interval is limited to integers 0 — ∞ and brings up a number keyboard only. Decimals are allowed.

Type was designed as a drop-down — there is a huge possibility that more “trigger types” get added to this feature down the line. My goal was to make sure the feature pliable if subject to additions.

Frequency picker

After iterations (dropdown, changing the modal contents entirely for each of these options picked), selecting between a single or repeated fire alert was done best on a simple 2-up picker that didn’t alter the rest of the modal

• Alerts set as “only once” will be parsed as [alert message] + “AT” + {INTERVAL} + {TYPE}

• Alerts set as “repeated” will be parsed as [alert message] + “EVERY” + {INTERVAL} + {TYPE}

Manage selections

Alerts that you’ve created for yourself stay on this “choose” page unless you need to edit or delete them. It looks very similar to an alarms app.

The most common use case for custom alerts is a rapid on/off of pre-made alerts that a user needs for that specific workout or race.

By enabling a quick toggle for on & off, and stowing editing/deleting elsewhere, we saved the user a few seconds each time they go to use the feature.

Edit alerts

Editing in the “Manage” page allows for an accordion expand-and-collapse for each custom alert that allows each field to be edited in-line!

• Edit message (expanded message box to fit the longest message possible)

• Frequency picker (same)

• Interval and type inputs

• Delete button

I took a huge amount of inspiration from Android clock/alarms for this in-line editing behavior, mostly the repeat and day-specific alarm settings that are nested in the expand behavior

Delete alerts

If you’re gonna edit in-line—you might as well be able to delete in-line.

Deleting an alert can happen in 3 different ways:

1. In-line delete button

2. Multi-select delete

3. Swipe to delete (iOS behavior)

Settings

ELEMNT companion app already had a section under Settings for Alerts. This previously only including text messages, emails, and phone calls.

Adding custom alerts here made the most sense, but I nested it so that it had space for more multiple settings for the feature.

LEDS and Sounds

I decided to keep LED and sound patterns the same as a traditional notification (text) on ELEMNT. I feared adding a third notification sound (in addition to text and call) would be too much.

The in-ride experience

1. Alerts toggled to “on” on the companion app are ready for a workout.

2. Once the “START” button has been pressed, all counters are turned on. TIME is accruing, as is DISTANCE. CALORIES are calculated using the appropriate datapoints.

3. YAY! An alert counter has accrued the amount set. Alert fires and displays message, LEDs flash, piezo buzzer goes off.

4. Alert message stays on-screen with no set fade time.

5. User must manually dismiss alert in order to get it to disappear.

6. Alerts stack on top on one another if not dismissed.

7. If a user MUTES alerts, no alerts shall fire. Counters are still accruing. User confirms muted state.

8. If a user sets alerts back to ON, they will fire back on accrued cadences. No past alerts will fire.

9. If a user finishes a workout with alerts MUTED, that state is persistent for their next ride.

Mute

Muted alerts do not fire but remain on their counter (++)

Dismiss