Lunara: AI dream-recording wearable device app

Connects journal and dream data using AI to deliver context-driven, personal insights.

Lunara allows users to not only write journal entries about their daily life, but to also have their dreams recorded for them through a wearable sensor. It analyzes both journal entries and dreams to provide personalized dream interpretations that help users understand their subconscious and how it relates to their waking life.

Overview

This project was a take-home UX design challenge from a company.

“Create a new product idea under the presumption that we invented a new sensor that enables us to record and track our dreams.”

This case study explores how I designed a product using imaginary technology, starting with research to define its capabilities and determine a strategic direction using the most relevant data available. I then narrowed the scope to a focused use case that was likely to have high demand.

The result was a clear product concept supported by a brief profit model.

Duration

2 weeks
(Oct 2022)

* UI was updated in June 2025.

Role

Research, UX/UI Design, and prototyping

Project

Design challenge

Challenge

How can I create something valuable without knowing what it’s for?

I was given only a vague concept: a futuristic technology that tracks and records dreams. There was no real product and no clear user problem. Just a speculative sensor that might still be in development, possibly not real yet.

It was one of the hardest kinds of design problems. How could I create something valuable when I didn’t even know what it was meant for?

I thought back to small moments in my own life where I used tools in unexpected ways. For example, using eyeliner to cover bleach stains on clothes. Those experiences reminded me that sometimes, the key is not starting with a problem but instead looking at what a technology can actually do. This changed how I approached the problem.

Instead of asking what problem I wanted to solve, I focused first on understanding what could be done with dream data. That gave me a foundation to identify the kinds of problems this tool might be able to solve.

Process

Flipping the UX Process: Capability First, Problem Second

Since the technology I was designing for didn’t exist yet, I couldn’t begin with a user problem. Instead, I had to flip the typical process: start with the capabilities, then look for a meaningful use case.

Here’s what I kept in mind:

  1. The technology was defined, but the user problem wasn’t.
  2. Because the technology was imaginary, there was no real user behavior to study.
  3. For a product to succeed, it had to solve a problem shared by enough people.

With that in mind, I created a 4-step process to find and define a strong, problem-first direction:

My 4-Step Process

This flipped approach helped me go from abstract capability to a product idea grounded in real needs.

Secondary Research

Step 1: Exploring the Potential of Dream Data

To understand the potential of dream data, I reviewed about 30 articles, studies, and analyses related to dreams and their interpretation.

I identified recurring patterns and grouped them into three potential application areas for dream data.

Three potential areas where dreams could be applied

This helped me narrow in on the kinds of problems dream data might realistically help solve.

Step 2: Narrowing Down to One Capability

Ideally, I would have validated the direction with a survey asking: “Which type of dream data would be most useful to you?” However, due to time constraints, I used a practical shortcut.

I assumed that if a capability was already being mentioned or used to address a real problem, it would likely be something people would look forward to using once the technology became available.

Based on my research, Area #1(Getting insights from dreams to waking life or mood) stood out as the most promising. While Areas #2 and #3 had little to no comparable use cases, I found examples of “dream therapy” that likely fit under Area #1. This suggested that it had stronger relevance and traction.

This insight gave me the confidence to move forward with a focused design direction.

Review Analysis with a JTBD Framework

What Users Really Want from Dream Apps: Actionable Insights, Not Just Symbolic Meanings

Although I narrowed down the dream data’s capability to Area #1, ‘Getting insights from dreams to waking life or mood’, the problem still felt vague.

I analyzed reviews from three popular dream interpretation apps. Even though they didn’t use dream-tracking technology, the feedback revealed key behavioral patterns and unmet needs.

Based on recurring themes in the reviews, I defined the following JTBD statement:
[Situation] When something is happening in their lives or they’re experiencing recurring dreams,
[Motivation] They want to understand the deeper meaning of those dreams
[Desired outcome] So they can gain insight into their emotions and take action in their waking lives

I also found that users were frustrated with shallow, generic interpretations, especially when asked to pay for them. In contrast, users who received deeper insights from a real human expert felt the subscription was worthwhile.

Key insight: They believe dreams are connected to their waking lives and are willing to pay for interpretation when it feels meaningful and actionable.

This helped clarify the real job users were hiring dream tools to do, not just decode dreams, but make sense of themselves.

“How might we turn dream data into personalized insights that help users understand their subconscious and take action in real life?”

Based on the insights, I reframed the vague problem into a clearer opportunity. It was the one that could directly shape the product direction.

Competitive Analysis

While the sensor to record and track dreams would be wearable in any form, I questioned whether a wearable alone could effectively display rich, personalized insights, especially on a limited screen during sleep.

Given the tight timeframe and the need for a scannable, accessible experience, I chose to design a mobile app to visualize the dream data and insights.

Before diving into design, I conducted competitive analysis to explore existing patterns, understand user expectations, and identify areas where this product could stand out.

Step 1: Advanced Dream Interpretation Apps

Why They Fall Short: Too Reactive, Too Shallow

I analyzed two advanced apps: one used AI, and the other offered in-depth interpretations through human experts.

Both went beyond basic dictionary lookups. But when mapped to the JTBD framework, their flow failed to fully meet user motivations or outcomes:

These apps are fundamentally reactive. They can provide meaningful interpretations only when:

  1. Users recognize that their dream is related to something in their waking life.
  2. Users remember and share all relevant details from that dream.

Even when a dream is tied to real-life experiences, users may not realize it, or they may forget key parts when logging it. As a result, these apps likely fail to deliver meaningful or actionable interpretations.

Unlike existing apps, our system can passively capture raw dream data, reducing reliance on memory or self-reporting.

However, to deliver truly meaningful insights, we still need to connect dream data with life context, which requires designing seamless, low-effort ways for users to share what’s happening in their lives.

Step 2: Wearable Sleep Devices

Where Wearables Win: Trustworthy data + user reflection = value

The goal of this challenge was not to design a mobile app, but to create a product idea using the sensor. Since the product would be a wearable, I analyzed existing sleep devices to better understand their value propositions and revenue strategies.

By analyzing their features and pricing, I identified insights I could apply to the product I was designing.

What I Confirmed/Learned
Insight #1

These devices promote stress and emotion tracking, but the insights are inferred from physiological signals, not directly measured.

What this insight suggests

While these signals may feel helpful, they are not precise reflections of emotional state, and should be treated as supporting signals, not conclusions.

Insight #2

Their strength is in tracking raw body metrics like HRV, skin temperature, and resting heart rate, rather than delivering personalized insights.

What this insight suggests

Users may be willing to pay a high price for raw physiological data alone, even without emotionally accurate interpretation.

Insight #3

Fitbit stands out by pairing physiological signals with self-reported mood, grounding stress insights in user reflection.

What this insight suggests

Combining raw data with user reflection may make the interpretation feel more personal and trustworthy.

Competitive analysis suggested that combining dream data with life context could lead to more meaningful outcomes and make the product more competitive.

Additionally, the insights reinforced that while some users are satisfied with raw data alone, others are willing to pay more if the insights feel meaningful.

Based on this, I shaped my business model: I priced the wearable and core app, which always provide access to raw dream data, at around $300. I then offered the premium experience with personalized insights as an optional add-on.

Turning Research into a Product Direction

Through competitive analysis, I realized that connecting users’ real-life context and their subconscious would be key to delivering personalized and meaningful insights. From this, I began exploring how to turn that connection into a workable product experience.

Step 1: Encouraging Users to Share Life Context

To generate meaningful insights, the system needed context about the user’s life. Otherwise, dream data would remain disconnected and raw.

I made two key assumptions during ideation:

  1. Users are unlikely to share every detail of their life, especially in an app, due to privacy concerns.
  2. Dreams may reflect not just life events, but also how users feel about them.

Based on these assumptions, I chose to use user journals as a data source, since they addressed privacy concerns and contained emotions and events more effectively than other options.

Step 2: Connecting Life Data and Dream Data

Life data and dream data are both complex and unstructured, unlike typical numeric statistics. The system needs to read, interpret, and connect long, subjective dream logs and journal entries within seconds. To generate meaningful insights, it must deeply analyze both sources together.

This led me to conclude that AI would be essential.

These two ideas, journal-based life context and AI-powered dream analysis, became the foundation for the design.

Designing an AI Insight App Powered by Dream Data and User Journals

Step 1: Focusing on the Core Flow

Since the main product was a dream-tracking wearable, the app needed to support onboarding and device connection. There were additional edge cases to consider for a potential real-world launch.

However, due to the tight timeline, I prioritized designing the core experience, based on defined user stories, flows, and information architecture.

Even when people share context in journals, AI would likely struggle to link it to their dreams without clear reference points.

To solve this, the system needed something recognizable to anchor connections. I called these ‘metadata’ so the AI could connect dots between journals and dreams.

Step 2: Introducing AI-Learning Touchpoints

To help AI learn with greater accuracy, I introduced a metadata model for both journal entries and dreams. I added subtle interactions to make it clear to users that the AI could recognize patterns like names or recurring people.

This approach was essential because meaningful personalization comes from ongoing learning, not just a one-time analysis.

Business Insight: Since personalization improves over time, offering the first few months free could build trust and demonstrate long-term value.

With the defined flows and interactions, I moved on to designing the core experience.

Step 3: Designing the core experience

Starting from the layout, I knew I needed to define clear principles that would guide every design decision. Even though this was a concept project using speculative technology, I grounded the process in real user needs and product goals.

I focused on four core principles:

These principles shaped every interaction, layout choice, and content priority throughout the app.

Messy, not pretty, but important sketch process

I explored multiple directions for layout, hierarchy, and metadata interactions, narrowing down to one final decision for each element.

Final Designs

Since this design was for a take-home assignment, the process was rapid and didn’t include lo-fi design, testing, or iteration. During the sketch phase, I explored as many ideas as possible, then narrowed them down based on four defined principles before moving straight to hi-fi designs.

Note: All icons were sourced from the Iconify Figma plugin, and all images were sourced from the Unsplash Figma plugin.

Premium Experience Walkthrough

Insights from a competitive analysis of wearables reinforced that while some users are satisfied with raw data alone, others are willing to pay more if the insights feel meaningful.

Based on this, I designed the core experience for all users, with raw dream data always available. Premium features build on this by adding AI-generated insights. Here’s how this premium experience could work.

Step 1: User writes a journal before sleep

The goal: For the AI to learn the user’s life context.

Step 2: User goes to sleep wearing the wearable

Goal: AI records all dreams and separates them.

When the user falls asleep, the wearable automatically starts recording. Most people have about 4–6 dreams per night, so the AI should detect where each dream starts and ends so users can choose which ones to explore.

Step 3: User wakes up and opens the app

Goal: The user can easily review personalized insights and recorded dream data.

Prototype

Many people don’t like sharing dreams because it feels too personal or private, especially when they realize dreams can reveal a lot about them. Research shows even therapy clients often hold things back. 1 2

This concept gives people personalized insights without needing to share their dreams. Over time, the AI learns from their data, making the experience more helpful while still protecting their privacy.

Next Steps (if launched in the future)

Test assumptions, iterate (if needed), and design for remaining core and edge cases.

While I initially designed the premium experience around user needs identified through research, the non-premium version without AI-generated insights should be designed next, as premium is optional. Clear onboarding would also be important to guide users through both experiences. If this concept were developed further, I’d also focus on:

  1. Validating assumptions
    • Testing whether users feel comfortable sharing detailed journals.
    • Confirming the core navigation supports their mental model.
  2. Completing necessary flows
    • Designing supporting pages like Explore connections, Settings and Journal history.
  3. Covering edge cases
    • Handling scenarios such as nights without recorded sleep data.

Reflection

Thinking outside the box while balancing user workflows and continuous AI learning

First, it was challenging to design a product without knowing exactly what to solve, especially under pressure and a tight timeline. However, it was also a valuable opportunity to push myself to think outside the box and flip the typical process. It reminded me that design isn’t always linear and that it’s often more complex in the real world.

It also gave me a chance to think about what ideal AI and human interactions can look like. Perfect personalization is the goal, but it’s something that can be achieved gradually as the system learns more about the user. This process is necessary, but when gathering feedback requires user effort, the product should ask for it at the right moment without disrupting natural workflows.

Next

© 2020 – 2025 Rachel Yoon. All rights reserved.