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.
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.
2 weeks
(Oct 2022)
* UI was updated in June 2025.
Research, UX/UI Design, and prototyping
Design challenge
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.
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:
With that in mind, I created a 4-step process to find and define a strong, problem-first direction:
This flipped approach helped me go from abstract capability to a product idea grounded in real needs.
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.
This helped me narrow in on the kinds of problems dream data might realistically help solve.
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.
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.
Based on the insights, I reframed the vague problem into a clearer opportunity. It was the one that could directly shape the product direction.
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.
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:
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.
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.
These devices promote stress and emotion tracking, but the insights are inferred from physiological signals, not directly measured.
While these signals may feel helpful, they are not precise reflections of emotional state, and should be treated as supporting signals, not conclusions.
Their strength is in tracking raw body metrics like HRV, skin temperature, and resting heart rate, rather than delivering personalized insights.
Users may be willing to pay a high price for raw physiological data alone, even without emotionally accurate interpretation.
Fitbit stands out by pairing physiological signals with self-reported mood, grounding stress insights in user reflection.
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.
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.
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:
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.
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.
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.
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.
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.
I explored multiple directions for layout, hierarchy, and metadata interactions, narrowing down to one final decision for each element.
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.
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.
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.
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.
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:
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.