Problem
According to a survey our research team conducted on kid's routines, parents ranked getting kids up and ready in the morning as their #1 daily pain point. In order to help parents, I designed character alarms as a way to encourage kids to get up, as well as become more autonomous in their daily routines.
Target audiences
Character alarms' primary audience is kids, but it also included two other key audiences for the success of the product as a whole: Parents and Brand partners. Each of these audiences have very unique needs.
Kids
•I want to have fun and talk to my favorite characters
•I want variety so the responses feel new and interesting each time I use the alarm
•I want to understand what all my character choices are and, if you don't have my favorite character, list my alternatives
Parents
•I want the alarm to be easily modifiable for disruptions to our daily routines & changing sleep schedules
•I want the content to be fun and age-appropriate
Brand partners
• I want an easy, templated way to build character alarms so I clearly understand the level of investment from my internal creative, legal, and marketing teams
Constraints
Considering all of the options for alarm implementation, it made the most sense for the scope of the eng team to build on top of the existing media alarms stack for our smart speakers & displays. However, this meant that we inherited existing bugs that wouldn't be resolved before launch. We also inherited the existing rules and constraints around how to build an alarm, which limited the customization of the alarm experience.
A media alarm is comprised of 3 key interactions:
•Setting the alarm
•Waking up to the alarm
•Snoozing the alarm
We wanted to have the character involved in these 3 moments in order to drive a cohesive experience and differentiate the alarm from basic productivity alarms. But this required rigorous testing and bug-bashing within our team. Diverging from the default stack and calling new apis results in unstable builds and regressions, which was a huge time investment for our eng team, leaving less time for pushing the visual design scope.
Visual interface
As the primary design owner for character alarms, I worked directly with the Surfaces team to identify existing patterns that I could use to create the screens for each step of character alarms setup and delivery of the alarm.
Our use cases were a good fit for most patterns in the library, but some had to be modified to deliver an experience that felt engaging to our kids audience.
For example, in the 'form filling' template, we added the character's face to the line where the character's name appears. This provided additional wayfinding for the child as they continue setting up their alarm.
Conversation design for alarms
In parallel with the visual interface, I also designed the conversational experience for character alarms. I used a tool called Podium to map the user experience and logic for all types of user paths: the happy path, when there's a no match response to what a kid said, and when the child is overwhelmed by choice and unable to choose themselves. Below is an example of how I documented the flow: First, by sketching out the conversation and then mapping to all the potential outcomes.
Testing and trying this live on the device helped me quickly workshop responses that felt more natural while also leveraging existing alarm setup language. This simple sketch then turned into a logic mapping of the entire experience, including disambiguation and all potential edge case responses.
Developing content appropriate for kid audiences
Special legal considerations were taken into account while developing character alarms with our third-party partners. If an action is targeted at children as the primary audience, oru 3P partners are required to join the Actions for Families program and designate their actions are family-friendly. This ensures kids are being delivered trusted, high-quality content.
I was responsible for onboarding our 3P partners to this program and I helped navigate them through our voice storage practices for AFF actions. The majority of the coaching I provided was during script reviews. Our 3Ps would provide the scripts for the characters and I would do a first pass of my own to flag audio passages or visual assets that I felt weren't in compliance with our policies. This was an initial step before a final review with our Policy & Legal council.
Assets for brand partners
I noticed when onboarding multiple 3Ps that their teams would ask the same clarify questions about how to write their scripts for the alarms. Aggregating these most common questions, I created a document for our brand partners on how to create content for character alarms. It outlines the goal of the experience, the character's role in helping wake up kids, and details of how to prepare audio files for production.
I also developed a script template in the form of a spreadsheet, divided into the different steps of the experience:
•Alarm confirmation
•Ringtone
•Character follow up (i.e. words of encouragement)
•Snooze response
For each of these, I recommended having a minimum number of response variants to ensure there would be novelty when using the alarm over time.
Brand partners were also required to provide their own visual assets, because they know their IP best. However, given their unfamiliarity with our screen sizes and resolutions, I created this Sketch template to provide an easier self-service experience for designers on our brand partner teams to understand the visual assets they would need to provide for their alarm.
Testing the experience
Before deploying the feature to the public, our team did an internal dogfood to see where the experience was breaking as well as to highlight any feature flags to launch. I created a dogfood plan and had 10+ team members test the build before production to identify and log bugs.
Sound design and quality was also an issue that needed to be addressed in testing. I listened to all the audio passages for each alarm on different speakers and documented which needed to be re-balanced or, in some cases, re-recorded because of poor audio quality of background noice from repurposed audio from TV show clips.
Shipped product
Character alarms was launched in March of 2019 on speakers and smart displays. We saw cosnistent engagement since launch, with an average of 800 DAU. Routine engagement (i.e. users who use more than once averaged 3.5 times a week) has 60% retention. This was incredible given that regular alarms had a retention of 11.9%. Character alarms was included in an Assistant press event in November that covered new feature for the holidays. Since launch, we received interest from additional partners, such as Marvel, Disney, the Wiggles, and SpinMaster.
"It helps my little brother get up in the morning so I LOVE IT." -Google directory review
"My kids ask for the 'Turtle alarm' now. It's really cute." - Google directory review
This page is part of setup where the child can choose from familiar brands if they don't know what characters we support. At the time we launched, these were our three early brand partners with more partners onboarding on a rolling basis.
Alarm experience on a speaker device. This was one of the variations of the Hatchimals wake sequence with the follow-up message of encouragement.
Alarm experience on a screen device. This is one of the variations for LEGO City. There were still some bugs with the display of the graphics at the time I took this video. But they were fixed before launch.
Project learnings and challenges
Maintenance for this feature was difficult, given the lack of engineering resources and the team moving on to support new kid features. I developed a proposal for scaling character alarms into 'delightful ringtones' that could be centrally accessible to Android users (even on phones!). This way we'd be able to increase discovery and have more resources for internationalization beyond ENG-US locales.
Leadership gave us the green light to scale character alarms into 'fun timers' which would be part of the central productivity team. It was moved to the personality team so we could bring more delightful animations to the screen and not be as limited by the surface alarm framework.