Project overview:

Add a feature that will be immensely useful to both pre-existing and new users of the Hatch Rest App.

My role:
UX/UI Designer for new feature

Duration 1/1/24 - 2/8/24

Tools used:
Figma, Miro, Whimsical, Maze, Photoshop, Optimal Workshop

The problem:
While the Hatch rest is an amazing product, one important option is missing: the parents' voice. Science has proven that a parent’s voice helps a baby release levels of cortisol to stay happy. Dr. Debbie Palmer Wolf, principle researcher on The Lullaby Project, has said, “‘Lullabies allow infants to create neural pathways for calming down, soothing, falling asleep [and are] especially important in the early months of life when brain pathways are being created. A lullaby is an external routine that becomes an internal pathway for calming down.’” If the app allows you to adjust settings from bed, it should also allow your child to hear your comforting voice from bed.

The goal:
Propose an alteration to the Hatch Rest Sleep app that would allow a parent to record their own voice for the child to listen to. They would then be able to add their recording to the favorites section, either on loop or slowly transitioning into one of the other favorite preset sounds.

Link to Prototype

Design Process

Empathize

Competitive Analysis:‍
In the initial competitor analysis, it became clear that the pre-existing products that offer the ability to record oneself had both sound quality issues, and used bluetooth, which many parents do not want near their infants. The option to blend one’s voice into a pre-existing white noise sound would be a novel setting. All products at a similar price point to the Hatch had a special feature that set them apart from the competition, such as using real noise (fans) for a loopless sound experience, playing with alpha and beta waves to improve a child's sleep patterns, and an adaptive feature that scans a room for any noises and adjusts sounds accordingly

User Survey:‍
Before starting my interviews, I sent out a survey that used Likert, Binary, and written responses from parents to help sharpen and direct the questions I would do during the interviews. 10 parents responded, and this is what I learned in the process:

I made an error in my question format, which was asking parents if they currently sing their children to sleep - this question should have read “Do you, or have you ever used your voice (singing/shushing) to help your child fall asleep” - since many parents use their voice in different ways to soothe a child, and since infants are much more soothed by lullabies than toddlers are, and in general it seems voice is a much bigger part of helping babies fall asleep than older children, the answers to this question were much different once that correction had been made for the interviews.
The dominant white noise machine being used by participants was the Hatch, so it helped to have a large percentage of participants being intimately familiar with the product I will be angling to update.
Interestingly, the survey participants were much more divided on the topic of using a pre-recorded voice, and much more unanimous about not wanting the voice to loop. The difference here again is that I failed to make it clear that the study was angling towards their experience when their child was 1-12 months old, and not how they currently get their older toddler or child to sleep.

While the survey didn’t yield the responses I was expecting, it helped me take note of the flaws in my questioning and set me up for a much more successful interview process, as I was able to reframe the future questions to the more specific needs of newborns and older infants.

User Interviews:
During the user interviews, I received a ton of helpful feedback from my seven participants: more so than any other Designlab project I’ve completed. I believe this to be because I interviewed exclusively parents, and most parents have experienced a struggle with sleep issues. This made them more engaged in the prospect of making the process of bedtime easier. Doing this project showed me what user interviews can be like when you have the exact right audience for the product! Learning from the survey, I tried to make my questions as specific as possible without being leading. I conducted recorded in-person and virtual interviews. When I was finished, I recorded key points from the interviews with Miro and started to map trends.

Key Takeaways:

Most interviewees showed interest in the possibility of using a pre-recorded voice of themselves to soothe their child to sleep
Many thought of how effective of a tool it might be when a babysitter or secondary caretaker has to take on naptime and the child wants their primary caregiver.
Many would be curious to see how effective it is, but were not completely sold on the idea as they were not sure how their children would react.
One concern/pattern pointed out was that some people don't like the sound of their own voice - they would be willing to use the product remotely or use their partner's voice, but didn't want to hear themselves.
It was clear that both the loop and the fade into white noise options should be available: interviewees were almost equally divided on this, and as one person said, "it depends on the kid!"

Ideate

Affinity Mapping:
I used the process of affinity mapping in alignment with completing the interviews, adding notes to the map each time I finished another interview, so I had a strong idea what my affinity map would look like as I was still finalizing the interviews. One thing I added during the mapping process were additional improvements for the Hatch brand to consider beyond the scope of this project, such as:

Travel connectivity and back-up battery for power outages
Use of AI to improve sound quality/match noise levels in any given room
Advice section offering bonus materials from sleep pros to help make bedtime more successful
Additional meditation/mindfulness sound feature

Click image to view original work in new page

Storyboarding:
Prior to building personas. the feedback I received from all walks of parental life made me want to use the optional storyboarding project to begin to explore how real-life application of this feature might look:

Click images to view

Personas:
From here, I developed my personas using some of the input I had received from interview participants, as well as trying to think of some other specific scenarios in which this tool might be necessary, such as the process of helping a special needs child fall asleep.

Click images to view

Goal Setting:
Since this app was already a well-oiled machine, I knew my ultimate goal was to add a feature seamlessly that did not disrupt the habits of parents, goals of the business, or technical functioning. In order to further explore what the different goals for the user, business, and technical sides are, I began writing out a list. The most directionally solidifying quadrant was where business & parent goals overlapped.

Define

Problem Statement and Feature Set:
It was now time to take all of the information I had gathered, and write out some Point of View and How Might We statements. Once I had the right questions being asked, it was time to envision what the future of the new feature might look like, and what details should be included in this new addition. It was fun to take the concerns and wants that interviewees had voiced, and think of practical solutions, such as the ability to lock one’s recording for in-app only to address feelings of vulnerability/embarrassment having a recording of one’s own voice.

Click either image to view original work in new page

Site Map:
To better familiarize myself with the workings of the Hatch app and how my feature might fit into it, I chose to take the optional site map project. There were five items in the lower navigation of the app already, as well as three buttons on the top of the app - exploring these helped me to decide where & how my feature would be mapped in.

Click image to view original work in new page

User Flow:
Moving on to user flows, I spent a lot of time ideating on how the process of recording would work. The Hatch Favorites only has 6 save options (3 in the new version) and Programs have 10 slots. As it currently works, the Favorites override the 6th spot, but my design plan was to alter this to be able to select which favorite to override. I would also later include a Voice Archive to be able to re-use recordings one likes in different settings.

Click image to view original work in new page

Prototype

Lo-Fi Wireframes:
I started this process with a ton of sketches, trying to imagine how my concept would match the style of the brand seamlessly, but still add a little something to dazzle the user.

Earlier sketches vs. later sketches

Click either image to view

Once I had a direction to move in, I started designing in Figma. I used screenshots of the current app (exploring pages from both the original and plus versions for inspiration.) I took notes of ideas and questions I had as I designed in order to have them for reference to myself and in discussion with my mentor. There were so many details from the original app that I wanted to make sure I was staying on track with their own brand’s UX patterns

Click image to view

Brand Style Tile:
Since Hatch has an established design key, my objective with the style tile was to make a few updates, such as a color redesign of custom sound buttons (done with the help of photoshop) to bring it closer to the newer Hatch Plus design concept, and create new custom icons for the voice recordings. I also sought to match their font and color schemes, opting to use Inter as the closest font to the hatch typeface.

Click any image to view

Hi-Fi Prototypes:
Finally, I was able to polish up the frames into high fidelity mockups that could be used to complete several tasks. To my great frustration, there was, and continues to be, a technical error on Figma’s side which continues to drop vectors in the prototyping (they are within the frame and should be working fine). Regardless, I was mostly pleased with how this design came out, and now it was time to test!

Click image to view original work in new page

I feel proud of a lot of this design work, as I feel I managed to keep the style of Hatch undisturbed (especially on the homepage), but was still able to make the new feature flashy & unique.

Click image to view

As the below examples show, there was a style evolution, but it was keeping in line with a lot of pre-existing app design, such as the rounded edges of modals and the thin, subtle lines of the buttons.

Click image to view

Test

Tree Testing:
In order to gain insights as to how discoverable and easy to use the new voice record feature might be for Hatch Rest app users, I opted to do a tree test with some lo-fi frames. For this test, I used:

8 participants
All located in USA, 1 test via mobile, 7 via desktop
Participants did not have to be familiar with Hatch Rest App

I asked for only one task: “You want to record a custom voice recording for your child. Please go through the steps to make a recording that will fade into white noise, choose a custom sound, mark for in-app only, and save to favorites.”

Performance was subpar, but offered great insights to pinpointing the problem area, and how adjustments to the design would lead to a more straightforward experience for the user.

Click image to view

It appeared that, even without the addition of a microphone icon, users would intuitively go to the sound tab of the app to find the option to record. This lead me to believe that:

I could bypass adding a microphone icon to homepage, since users will intuitively go to the sound section anyway
If I do add a microphone icon to homepage anyway, I should create an additional pathway via the Sound tab (I opted for this option)

Hatch User Testing Lo/Mid-Fi Prototypes:
I wanted to try something besides Maze for user testing, so I set up a lo-fi prototype, and then asked users to complete tasks using Google Forms and answer in long paragraph format. Overall, the five participants seemed to have a mostly easy time getting from start to finish with tasks, with a few exceptions.

Some feedback I noted to explore as the project progressed:

Is the term ‘delete’ too aggressive vs. remove?
Is edit button too subtle? I used the icon as Hatch had it in the first version, but it was noted to be difficult to spot. (I did update this to say the word “edit” vs using the pencil.)
Should I add an additional save button at bottom of program screen?
Others had some issues with the tabs - I think this is in part because prototyping doesn’t allow for button pushing experiences, but could also consider adding a success check after each selection, as is visible here:

Click any image to view

Hatch User Testing Hi-Fi Prototypes:
‍For my last Hatch test, I did a moderated virtual user prototype test in Figma with 5 individuals: 3 unfamiliar with the app, 2 familiar with it. I had 5 goals with this testing:

Make sure the flow of the prototype is intuitive to follow
Take note of any observed UI/visual flaws
Make sure to remove any redundancies/things that don’t make sense
Take note of any parts/language within the flow that seem problematic/unclear to users
Get general feedback about how using this product felt and if the interviewee feels they might use this themselves.

There were four tasks to complete:

Task A:
Starting from the home page, please attempt to make a new recording. Note: your library will be full.

Task B:
Starting from the recording page, please “record” something, customize, and save as a program.

Task C:
Starting from the home page, please find your previous recordings

Task D:
Starting from the home page, please set a pre-saved recording as a favorite

Results:
2 out of 5 of the participants were Hatch users, and they fared the best through testing due to their familiarity with the app. Users brought up some valid points about the UX and offered mostly achievable insights as to what wasn’t working and how to improve the product. There was some clear overlap in issues users faced, as shown in the below board:

Click either image to view

Conclusions:
Based on user testing feedback, I felt there were several necessary changes:

There were too many customization options (color customizing the recording for the archives before also customizing to set as a program or favorite), so I picked a uniform color for archive recordings and added a folder icon to make recordings simpler to save and re-use.
The choice to save a recording to archives or continue without saving (to then customize into a program or favorite which could be deleted without preserving the voice recording itself) was confusing to users, so I opted to automatically save the recording (with the option to edit) and then continue on to customization.
The customization itself was challenging for people to follow, I feel in part because the prototype was not offering the same level of UX that a live version actually would, but I added some additional discoverability by adding instructional language to the tabs (step 1, step 2. etc) as well as a check box when the step had been completed.
Users who were not familiar with the app had a hard time grasping how the programs and favorites saving & customization process worked, but I believe this is more of a learnability issue than something that needs to be fixed, because they seemed to catch on quickly as they went
Finally, there is a lot of pushback - especially from those who are not familiar with the app - about the location of the voice archives. I decided to move them over to the sound tab to make finding them more intuitive.

Click any image to view