SleepMapper is a data-driven app that pairs with the SmartSleep deep sleep headband and Somneo wakeup light to offer a solution that helps you monitor your sleep and build healthier sleep habits every night. 

My Role

As Lead Designer for this project, I worked directly with the core team of PM, SW dev, HW eng, Product (device) design, Marketing (Project Owner). I was responsible for the following.

• Define app requirements with core team
• Design and run alignment workshops
  
• Interaction design
• Testing protocols
• Visual design
  

Purpose of a Companion App

How might we help individuals using SmartSleep, who get less than 7 hours of sleep per day, get the most out of their SmartSleep device by integrating it into their existing sleep routines? 

Working with Devices

The scientists at Philips developed SmartSleep, a wearable sleep device that helps people get deeper and more restful sleep. It works by monitoring brain waves and playing tones during delta (restorative) sleep to increase the depth of sleep. 

• Target audience
  • High-performing white-collar workers, ages 35-60, who lack sleep (< 7hr) due to busy schedules and obligations
  • New parents with young children, ages 25-40, who have irregular sleep patterns 
  • College students, ages 18-24, who lack consistent bedtimes
• Device Behavior: Measure sleep activity, play tones when in deep sleep
• Data collected: Sleep staging information
• App Challenge: How can we help users make sense of data and trust recommendations?

Kickoff: Identifying Primary Audience & Features

We had a broad target audience. So I brought the core team together for an empathy-building kickoff workshop. With 3 target audiences, we did a Think-Feel-Do exercise followed by role-playing a persona, followed by importance versus difficulty matrix. This helped us identify our primary audience, key features, and scope of the project.

Outcome of our importance vs. difficulty matrix that helped align and prioritize user groups and product features

Key Features that emerged from the workshop

• Sleep graph
• Sleep score
• Sleep data details
• Score breakdown
• Sleep tips & coaching 

Primary Audience & Persona 

High-performing white-collar workers, ages 35-60, who get less than 7 hours of sleep a day

Sarah, 42, is a marketing VP for a pharmaceutical company. She is married to Thomas, 40, who is an architect. Their 6-year old daughter Katy loves dance class as much as tae-kwon-do. Sarah typically gets 5 hours of sleep and sustains herself with 3 cups of coffee a day.

• Goal: Wants to balance professional and personal life
• Sleep challenges: Wants more sleep, but has no time
• Realistic Challenges: Cannot devote time to look for a solution  
• Opportunity: Improve the quality of sleep 

Understanding App Landscape

First, we performed a market analysis to identify key features and opportunities.

With devices that directly impacted users and the most accurate sleep staging data on the market, we had the opportunity to build an app that gave users a trustworthy assessment of their sleep and information tailored based on their own sleep data. 

Defining User Engagement

Prototyping Features & Testing Engagement

What data is relevant and appears actionable to users? We broke our questions down into variables and created screen flows that drew contrast to the different attributes.

• Data: What sleep data is most relevant and is it understandable?
  
• Time: How much time do users want to spend with their data? 
• Quantity: What is the appropriate amount of data to share with users?
  
• Tips: How do you make tips feel relevant?
  

To test this, we built wireframes, simple prototypes, and testing protocols. 

Wireframes focusing on differing types, quantities, and granularity of data were tested through CommuniSpace

Findings

Virtual testing was performed by C-space, a research agency, with 14 total participants. We found,

• Data: The most relevant data to be the sleep score, but users noted that it needed to be transparent to be relevant
• Time: Users only wanted to spend a short time looking at their data. Just an overview would suffice unless an issue arose 
• Quantity: Users wanted bite-size morsels of information and wanted to be able to control the amount of detail they viewed.
• Tips: For tips to be relevant, they needed to tie to data. As for the content, they preferred tips to be immediate, specific, and actionable
  

Key Takeaway

Users wanted to know when there is a problem, what was problematic, why it was an issue, and how to improve it.

Designing a System

Content Strategy 

I mapped out how information should flow by applying a logic-based questioning methods

I designed a feedback loop framework based on test findings and models of behavior change

Interaction Model

Based on our findings, and tying them into 'nudge' frameworks, I designed a feedback loop model that would reinforce continuous improvements and use of products. This became the basic structure for our information architecture. 

I designed a feedback loop framework based on test findings and models of behavior change

Building a Sitemap

The main sections were Sleep Data, Device Control, and Tips. We created 2 different types of sitemaps based on data granularity and tested them with C-space. 

Day-focused <“Just tell me how I did”>  - Landing screen "last night's" sleep score. More data shown by swiping down

List-focused <“Give me everything”>  - Landing screen is a list of scores. Clicking on a score shows all data for day

When tested, the 'Day-focused' view, which showed the Sleep Score as the landing page, was clearely preferred.

Workshop: Building a Sleep Score

Now that we had a system, we needed a score to tie everything together. The original sleep score was built by sleep scientists & experts and was medically accurate, and medically complicated. This led to a few user-facing concerns.

1. Not Actionable: Although accurate, not all items of the score were actionable
2. Not Understandable: The language was too technical and difficult to understand
   
3. Invisible: The "secret sauce" breakdown was hidden, so users could not understand the score
4. Unscalable: With so many Philips sleep devices, a device-specific score would confuse users

We brought in the key stakeholders - product owner, sleep scientist, marketers, product | digital | service designers - and engaged in a workshop.  We needed to strike a balance between accuracy, comprehensibility, and scalability.

Items 1 & 2: Action-ability & Verbiage

We kept hammering home that user trust was ultimate goal. Non-actionable elements were eliminated or consolidated and more commonly-used phrases were used as titles.

Shows the changes made to score elements and title of elements

Items 3 & 4: Visibility of Breakdown & Scalability

Thinking of scalability, we first made the score elements sleep specific rather than device specific. This meant any product that measured sleep stages could use the same score and any device specific contribution would become an add-on or "boost," limited between 0 and 20. 

Final score breakdown & point distribution

Providing Coaching vs. Tips

The final step of the feedback loop would be tips. The Product Owner wanted coaching (not tips) to be a key feature but lacked definition and resources. After weeks of back and forth, I created a chart visualizing the differences between coaching, tips from a resource, time, and UI standpoint.

Chart  I created to show the difference in effort between Tips (small) and Coaching (Large database)

 We had enough resources to create tips and so the decision was made.

Creating Wireframes

With our sitemap and sections determined, we created wireframes for the entire app. The daily view, detailed view, calendar view, device controls, and on-boarding.

Example wireframe screens of the data section and calendar view

Defining Key Interactions

Our home screen was determined to be a sleep overview that showed the sleep score. From there, users could just swipe to see more data regarding that score. This interaction gave users full control of how much data they would see. 

Though synchronization happened automatically. A button was added to enable manaul synchronization. Such redundancies were carefully considered and designed into the system.

Design Reviews

We held design reviews and worked with key stakeholders frequently to build consistency with the device behaviors as well. As the device was also being developed, this meant building joint definitions around behavior and accounting for unexpected changes. 

Design review with PM, Marketing, UX, Service, SW, HW Engineering leads

Creating Visual Designs

Considering the brand guidelines were limited to webapp and website guidelines, we needed to create new paradigms and visual assets. This project would later become a part of the new Design Language System that was being developed at Philips as a whole. 

Onboarding "Cards"

How can we inform and educate first-time users so they can maximize their product value? We decided to go simple and straight to the point. We also had "how to put on your SmartSleep" and gathered basic information for goalsetting and to assess a baseline. 

Final App Architecture

As an MVP, we released a de-featured app focused around the sleep score. 

Final App Features

Final Product

Learnings

I learned building a solution is more than a checklist. It is a journey you travel with your colleagues. Making sure you're all pointed in the same direction and taking the time to re-visit assumptions, and saved us time, head-ache, and heart-aches as a team. 

Epilogue

SleepMapper was developed in 3 parts. First for SmartSleep, then Somneo, then a combined app. I took part in all 3 of the design efforts and played different roles. 

Phase 1: SmartSleep (UX Lead)

• 1  office, 1 product team
• Define, align app requirements
• Define the core experience
• Prototype & test key features
• Build IA, navigation,  wireframes, visual language

Phase 2: Somneo (UX Lead)

• 3 offices, 3 product teams
• Define, align app features
• Align the core experience with key stakeholders
  
• Ran sprint to test desirability
• Build IA, navigation, WF

Phase 3: Combine (UX Des)

• 5 offices, 4 product teams

• Design the app UX

• Design device menu tree

• Define device & app interactions

• Create new nav paradigm

• Create wireframes for dev

Please reach out if you'd like to find out more!

© Made by Mark 2020