Quite a bit of sleep was lost while researching better ways to sleep.


Challenge: Build a Digital Application for the National Wellness Institute (NWI) to help them increase their accessibility to potential users in need of health guidance.

Goal: Create a Digital Application that falls under one of the Wellness categories designated by NWI that allows a coach to track the user’s metrics and improve the user’s well being.

Time Limit: Two separate Four Day Sprints

Solution: A sleep application that focuses on providing a vocal or written journal before going to sleep to reduce anxiety and allow the user to reduce the use of applications right before going to bed through the use of a feature that prevents usage of apps that distract from sleep.

Why Focus on Sleep?

During my third week at Ironhack, a bootcamp for /UI, I was tasked with helping NWI design a digital experience to help their members better balance and maintain a healthier lifestyle. We were given four days to complete a design sprint and present a solution that could be feasibly refined through another iterative process in high fidelity. As designers we were required to make sure the digital solution allowed:

  1. Interaction with coaches provided by the NWI so that users had support on their wellness journey, and
  2. A variation of a health tracker to let users know their progress during their wellness journey.

Otherwise, I was given the freedom to choose what aspect of health the digital solution would focus on. I wanted to choose a health issue that I struggle knew a lot of people struggle with. An issue that prevented them from living as full of a life as they wished. Something that I could personally relate to so that I could better empathize with that problem. It is not impossible to create a solution for a group that you are not personally apart of, but it takes much more time to do it properly. I knew full well about the risk of having my bias come in to control the direction of my project, but by constantly returning to what my user’s were saying I could stay on the right track. I have sleep apnea, which long story short makes me feel more tired throughout the day. I wanted to see if I could design a solution to help others sleep a lot better because of how deeply sleep effects not only how we navigate through the day but our capacity to handle the daily stressors that we are bound to face. But before we talk about solutions I needed to understand what we are actually trying to solve.

Problem and Parameters

I knew people had a problem sleeping, but I really didn’t know what those problems were and to what degree those problems effected people. My first instinct was to grab people and ask them what their problems were. I went through my first interview with my really good friend, and well … it was terrible. My questions kept ending in yes/no responses without any good follow up whys. I felt as if I was steering my friend in a particular direction because he had an idea of the solution that I was going for before the interview started. More importantly, I realized that I didn’t really know what I specifically wanted to ask except overarching questions with sleep, leaving me with surface level questions.

I needed to go back to the drawing board (before I even really got started) and research two things: what does the existing data in reports say and what products are already on the market to help with sleep. I thought initially that doing my interviews would better guide my research, but sometimes googling becomes a vehicle to clarify my thoughts after I have read the same thing in multiple places. After a few hours of looking through Consumer Reports, product reviews, and endless scrolling through the app store I came to two conclusions:

  • there seemed to be a gap in the market for sleeping applications that do more than track your sleep or tell you to meditate
  • the problem statement I initially created was way to vague
(Left) Feature Comparison and (Right) Competition Analysis

Currently their are hundreds of products that help with sleep, but they mainly fall into three categories: physical products, meditation apps, sleep tracking applications. The gap comes from the lack of focus on guiding the behavior of users rather than throwing a bunch of data at the user giving them vague suggestions hoping they follow it and making everyone rely on meditation to improve their sleep — yes meditation is good for me, but is that really the solution for everyone. For example, apps like Calm or Headspace to a good job of attempting to help people build good habits and curb bad ones, if you run to meditation for comfort from the harsh world.

One application that I added that may seem out of place is the app tracking application Moment that mainly gauges the usage of a user’s activity of the applications on their phone. I started noticing, during User Research, that people were just not doing a good enough job of tracking how much time around bed time and after waking they were spending on distracting apps like Social Media. Time spent is an important consideration because it allows for a better understanding of the areas where smaller shifts in behavior can have larger impacts on the user’s activity on the phone. Whatever area I focused on it needed to incorporate reducing bad habits.

Dealing with the problem statement I initially thought that not being too specific would help me keep an open mind but it was actually sending me in mental circles without a clear path forward. It is better to be precise and have to pivot moving forward than to move aimlessly without direction. I quickly adjusted and came to something more precise. Instead of just “how can we help improve people’s sleep with technology” I wanted to know:

How do we help people go to sleep more easily and stay asleep through the night?

This new statement not only focuses on the sleep itself and less on the technology being a necessary end but also on what people do to effect their sleep. Armed with this newly crafted statement I created my survey and new set of interview questions. I was now ready to do some User Research.

User Research

Before coming to the design field if you would have told me that research would be challenging I would have laughed and said I have been doing research my whole life. From Psychology and Philosophy research papers in undergrad to spending days on Roe v. Wade (in all its majesty) during law school just to argue a single point. User Research is settled in the sweet spot between on the ground conversations and behind the book inquiries to find a hook — an insight. I think the biggest difference was the static nature of the information that I was analyzing in the past. User Research felt much more fluid because I was dealing more with human elements in real time. Building on information of people, who at times have only a vague idea of their own problems let alone how they would liked it solved, is a whole other endeavor. But even still I managed (with the help of my sister and Instagram) to get over a 100 surveys and 7 detailed interviews in a day and a half.

I knew the importance of Quantitative Data as I quickly began to see patterns in people responses, but the importance of the Qualitative Data I gathered put everything into perspective for me. The word “anxiety” kept popping back up in my mind as people explained their troubles of getting to bed. What reinforced this even more is that Social Media just like TV seemed to be an escape from that anxiety to “get my mind off of the day.”

With all this information scattered about between the surveys and the interviews I needed to get a better view of the trends that were popping up overall. I created an Affinity Diagram to get a bird’s eye view of the information landscape and organize my thoughts a bit for a further drill down. Where the pain points were further solidified for me that there were a ton of distracting elements that prevented people from reaching their desires around sleep.

Affinity Diagram

I distilled all of this information further into three prominent pain points that I saw emerging:

Seeing all this information grouped together was very helpful, but now I needed a keep this information grounded and applicable to my problem moving forward. Enter Paulina.


She was the summation of all the information I had gathered so far and would now be used to better understand the mindset and typical day of a professional person in their mid to late 20’s (most of my demographic response). I used two methods to pull in more specific information from my interviews an Empathy Map to understand what Paulina was experiencing and a User Journey Map to go through a typical evening with Paulina, which ended with her going through Social Media because she was having FOMO. A typical and real fear of missing an event that all your friends are having the time of their lives without your presence.

Empathy Map and User Journey Map

Both helped me better understand the anxiety that people (and myself) are actually feeling could not be simply understood by focusing only on the time right before sleep. If people were using their phones to cope with that anxiety or escape throughout the day then that would partially account for the large social media usage right before bed as a way of unwinding or escaping. If people were really excessively thinking in the bed its is because they were either holding on to stress from the day or dreading the next day. With all this in mind I was ready to start solidifying my ideas and Prototyping.

Ideation and Prototyping

As I was going through User Research quite a few potential solutions came to my mind: alerts to notify people on usage, algorithms to predict user habits based on phone usage, suggestive language based on the type of user, and even boring people to sleep to put down the phone. To determine what the actual features of what the application would be I used the MOSCOW method.

MOSCOW Method Feature Selection

Throughout this process there were many features that I wanted to add, but clarifying what needed to be in my MVP (most viable product) was necessary to make my initial prototypes relevant to the discovered pain points. I decided to focus on features that were common to sleep trackers, but adding two features that were not. First, I wanted to create a feature around letting people vent their frustrations at the end of the day. Although, venting has a negative connotation, and “aggressive” was not something I wanted associated with my sleeping app. The word vent changed into the releasing of cumbersome or negative thoughts. While this may seem to be a semantic difference the repeated use over a period of time will definitely impart a different meaning on the user. Second, their needed to be a more assertive way for people to curb their bad habits if they wanted to and that led to the app blocker feature. This would allow the user to take it upon themselves to block their unhealthy phone usage, and slowly overtime the application would suggest blocking based on the user’s behavior. Again “blocker” is an aggressive word that does not do the act of winding down for sleep any justice. It wasn’t until the design of the interface that I would adjust the name to unplug (see below in UI section).

Primary Features of SleepPlease

After my features were chosen it was time to create a user flow to identify the screens that I needed and then proceeded to iterate on the specific structure of each screen to make it as functionally sound as possible.

Initial Flow Chart for Journal Writing Path

I then proceeded to play Crazy Eights to come up with the different variations of the screens. I chose the home screen and the journal screen as the basis for the type of structural design that I was going for with the application overall. These would be the screens that the user was looking at the most so they seemed to be good places to start.

My sketches are going to get better I promise

The resulting low-fi screens were good enough for me to follow the adage “test early and test often” so as soon as I felt semi-comfortable with the drawn up screens I tested them on five different individuals. The test consisted of having each individual go from the start screen to filling out their journal for the day either verbally or through writing. My initial usability test on the low-fi screens resulted in some good responses to improve my design:

  1. Make the Alarm on the Home Screen look more like an Alarm.
  2. Make it clear what screen the user is on at all times
  3. Remember to design for interaction with a coach
Lo-Fi to Mid-Fi

Taking all these into consideration I was able to have a more clearly defined product that led the user getting to and using the journal rather quickly. In the follow up conversations that I had with each test user four out of five asked and wanted to know more about the blocker feature that I had mentioned adding in the future. Those conversations made it apparent to me that the blocker should be something that I should should develop more now since it fit in nicely with the flow of my target user’s night. They would be preparing for bed the blocker would either come on automatically or by the command of the user and then they would use the journal to de-clutter their mind before going to bed. I decided to include it as an icon in the mid-fi on the alarm screen to supplement the journal.

UI Design

I had three considerations for the overall feel and direction of the application’s apperance:

  • It needs to break away from the standard blues present in sleep applications
  • It is a sleep application so it needs to be simple
  • It will probably be used a lot in the evening so a darker UI is essential

The need to break away from the blues was both a personal decision to give my application a more unique look compared to other applications and an objective decision to focus on earth tones that bring out feelings of warmth and elegance.

Competitors (Left) Calm App and (Right) Sleep Cycle App

Simplicity is something that I always strive for while designing because of my personal frustrations with interfaces that are unnecessarily complicated or long. The goal should be to take as much work off of the user as possible.

Lastly, a dark UI is necessary to reduce the potential of eye strain when looking at a screen at night. Darker UIs are common in entertainment interfaces because of the increase likelihood that the user is going to use the application in the evening. I started by creating a Mood Board to bring together the overall theme.

I eventually settled on pictures of beds, environmental backdrops, and colors because they brought out the Smooth, Calm, and Comfortable feeling that I was looking for when defining the Brand of SleepPlease. When I did round of desirability testing with five different people a new word started popping up that helped me determine the ultimate direction of the application, mysterious. The air of unknown that the pictures were evoking gave me a new angle to add to my application and so I played on that sense of unknown and decided on pushing for subtle hints of allure with certain screens in the application. Allure would play on the user’s desire to get to their one true love, sleep. The title could now have a more subtle push to it with the contrast between the light typeface of Sleep and bold typeface of Please. Please no longer remains a command but a seductive call from the bed itself.

Sleep applications by their nature are normally simple because there is only so many features that they are intending to cover in the first place, which falls squarely on tracking the sleep itself and an alarm. The sleep tracker does not effect the interface beyond what the designer decides to show the user for the statistics/sleep log portion of the application. Showing a lot of information gives the user access to information they did not have before, but runs the risk of creating information overload. The goal shouldn’t be to force the user to become a statistician to help them get better sleep. On the other end too little information will not give the user any sense of progression, and they will stop using the application. The alarm ends up being the home screen for many sleep tracking applications and does not have, or need, much variation.

I did not want to include a whole on-boarding process for an application that should be mostly intuitive by design. This problem was easily avoided if I kept to my UX strategy of constantly reminding the user where they were at in the app. I decided to change the title on each screen to Sleep_____ so that it was next to impossible to not know where user is currently located. As redundant as this seemed to be initially, it worked in my favor bolstering navigation while reinforcing the branding in an unique way.

When considering the Darker UI I looked a lot at applications that I use quite frequently like Spotify and Xbox because I always admired the sleek look, and did not really notice until now that the darker tones, black in this , allowed me to the use applications longer. In both of these examples there is a pop of some bright color, green here, to break through the darkness besides the white that is an obvious contrast. I didn’t believe that this was necessary as the feeling that I was trying to evoke called for a more subtle color, but color could still pop in certain screens.

(Right) Spotify Artist’s Screen and (Left) Xbox Home Screen

After all these considerations I wanted to start from the ground up to build up my application in a manner that would allow me to manipulate elements during the early stages to avoid back tracking. I followed an atomic design approach to tackle each separate element alone and make sure they stood up as individual objects alone.

This really came into play with my initial decision on fonts. I had gone for Raleway for my larger/title font, but had initially chosen Cabin for paragraphs and the icon font. Cabin seemed like a good choice initially, but when I started placing the font on its own I could not shake the feeling that it just didn’t fit. Thankfully I didn’t have to make the call users did for me in my next round of Desirability testing. Compared to my eventual pick of Avenir Next it didn’t even stand a chance.

My first draft of hi-fi screens were set, I was able to start getting some validation on the design aesthetic overall to know if I needed make any major alternations. Essentially my major changes came down to: avoiding colors that did not present enough contrast for accessibility purposes, whether dogs or cats were less divisive when people saw the picture, and the name unplug instead of blocker. The last one being crucial because with the blocker being one of my primary features it more than anything is going to carry the look and feel of the app when people learn and talk about it. Blocker did not give off the right connotation and again is a very aggressive and very commanding on the suer. Unplug seemed more like a gentle suggestion that evokes a feeling of letting go, which is exactly what I was looking for and what will resonate with my target users.

Desirability Test Results

Through many iterations the High Resolution prototype was created.

I recently had the opportunity to do further desirability testing and I found out the brown was not necessarily sitting well with users. I opted to find a different option while staying within the feel of my mood board and the colors I used. The slate ended up being the new back drop for my re-designed application.

Conclusion and Considerations

Moving into the future I would like to focus on secondary portion of helping people go back to sleep when they do wake up in the middle of the night. It calls for a different type of mechanism in the application that involves very little user input because people waking up in the middle of the night should not be going to their phones. The point of the application overall is to limit the use of the phone for only necessary tasks before going to bed to encourage good habits. There still needs to be a lot actual testing to see where the application fails in use and why, but this initial design will establish a platform to guide users to better behavior.

Personally during this project I learned three things:

  1. Go back to the user
  2. Context is king
  3. The Devil really is in the details

First, never ever stop going back to the user throughout the entire process while you are designing. Of course as designers we go back for testing purposes, but I believe the designer gains a certain sense of grounding if they are continually confronted with the user and their problems in the wild. Empathy is lost if we are not constantly checking our relationships with the people we are designing for. Second, you can come up with a good idea or solution, but it might mean nothing or very little when the user is attempting to use your product/design in a different environment. Here in particular everyone’s problem may not be actually involved with their phone and drawing them to use their phone when they weren’t before is a bad thing. In the future giving the user analog options is preferable, like a notebook that records entries digitally. Lastly, making things look good is great, but making things feel good is vital. I appreciated when users told me my design was pretty, but I lit up inside when users told me “that was easy to use”. I know it was a sleep application, but I aim to master designing functional solutions and this project helped me know I was headed in the right direction.

Source link


Please enter your comment!
Please enter your name here