Heat app

Designing an AI-assisted social discovery app

Timeframe

10 Months

Position

Lead UX/UI

Date

2025

What is it?

HEAT is a self-directed product exploration focused on how people discover social activity and connection in real time.


The project explores how AI, interaction design, and narrative can reduce uncertainty in social decision-making, guiding people toward confident, low-pressure engagement in the real world.

Designing Across Disciplines

The work was done with a limited budget and a small, distributed, cross-functional team, requiring strict prioritization and clear decision-making. I partnered closely with developers and freelancers across product, engineering, and implementation while owning product direction, UX, and system design. These constraints shaped the scope early and kept the team focused on what mattered most.

User Pain Points

People want to be more social in real life, yet deciding where to go and when to engage is filled with uncertainty. Over one-third of adults report frequent feelings of loneliness, even in highly social cities. Most social and discovery apps rely on static feeds, profiles, or matches that assume confidence and advance planning, which often increases pressure instead of reducing it. As a result, users hesitate, overthink, or default to familiar places, missing real-world connection when the opportunity is actually there.

Product Decisions

Based on this research, I made a deliberate choice to avoid features that require advance commitment. Heat does not rely on profiles, matches, RSVPs, or scheduled intent. Instead, I designed a map-first experience that surfaces real-time activity and momentum, allowing users to assess social energy before committing.

This meant prioritizing live signals over personalization depth, and clarity over feature breadth. Several planned ideas were intentionally cut to keep the experience lightweight and decision-focused.

Pivot: From Heat Map to Social Companion 🤝

The problem I encountered

The original concept for Heat centered on a social heatmap: a visual layer showing where activity was happening in real time. Early prototypes tested well visually, but something felt off in use. Users could see activity, yet still hesitated to act. The heatmap answered “where are people,” but not the harder question users were actually struggling with: should I go out at all, and would this be right for me right now?



What wasn’t working

In testing and informal feedback, I noticed a pattern. Users would open the app, scan the map, and close it without making a decision. The visualization was informative but passive. It assumed that visibility alone would drive action, which turned out to be false. Seeing social energy did not reduce uncertainty; in some cases, it amplified it.



The insight

The real problem wasn’t a lack of information, it was a lack of interpretation. Users didn’t need more data points; they needed help contextualizing what they were seeing. This reframed the core question from “how do we show activity?” to “how do we help someone decide, with confidence, in the moment they’re already uncertain?”

What changed in the design

  • The heatmap became an input, not the outcome

  • An AI agent was introduced to summarize context and surface relevance rather than issue commands

  • A feed was designed to translate real-time signals into lightweight cues that users could scan and act on without pressure


These decisions allowed Heat to move from “where people are” to “what this moment means,” supporting confident decisions without removing user agency.


The pivot

I shifted the product from being a social heatmap to a social companion. Instead of treating the map as the product, I treated it as one signal in a broader decision loop. I introduced contextual cues, place-level framing, and adaptive prompts designed to guide decision-making rather than just display popularity.



The outcome

This shift changed how every feature was evaluated. Features that added visibility without clarity were deprioritized. Features that reduced hesitation, set expectations, or helped users assess fit were prioritized. The result was a product that actively supported decision-making instead of assuming users would do that work themselves.

Market Research 💡


Heat was shaped around real patterns of last-minute decision-making across dining, events, and social plans. Industry data shows that ~45% of restaurant reservations and ~50% of event tickets are made on the same day, not days in advance.


This insight exposed a mismatch: most social products optimize for future planning, while real decisions happen close to the moment. I used this behavior to prioritize live context over static intent.

Product Decisions

Based on this research, I made a deliberate choice to avoid features that require advance commitment. Heat does not rely on profiles, matches, RSVPs, or scheduled intent. Instead, I designed a map-first experience that surfaces real-time activity and momentum, allowing users to assess social energy before committing.

This meant prioritizing live signals over personalization depth, and clarity over feature breadth. Several planned ideas were intentionally cut to keep the experience lightweight and decision-focused.

Persona and User Profile 👤


Heat was designed primarily for expats, digital nomads, and international residents aged 25–45. In cities like Barcelona, over 25% of the population are foreign nationals, many living temporarily and without established local networks.


In this context, spontaneity is not a preference. It is a necessity. When social availability changes quickly and networks are fluid, committing days ahead feels risky. Real-time information becomes more valuable than long-term plans.

Insight to Interface

The insight that users decide close to the moment directly shaped the interface. The home experience prioritizes what is happening now, highlighting proximity, live activity, and social momentum.


Heatmaps visualize collective presence, while lightweight cards surface context without requiring action. The interface avoids confirmation-heavy flows, allowing users to explore without pressure and decide only when the moment feels right.

AI Integration Decisions 🤖

AI was never intended to be an add-on, chatbot, or novelty feature. From the start, the goal was to integrate AI directly into Heat’s decision loop, supporting real-time interpretation of context without removing agency from the user.


Rather than telling users what to do, the system is designed to reduce uncertainty. It helps users understand what is happening around them, so they can make their own decisions with more confidence and less friction.


This approach intentionally avoids prescriptive recommendations and instead focuses on assistive intelligence that feels contextual, subtle, and human.

The Learning Model

Rather than relying on preference forms or onboarding questionnaires, the AI is designed to learn gradually through passive behavioral signals.


Examples of signals the system observes over time:


  • When the user typically leaves the house

  • How much time they spend in certain places

  • Which environments they return to repeatedly

  • Which suggestions they ignore versus act on

  • Whether they gravitate toward low-energy or high-energy settings

  • How spontaneous versus structured their routines are

Design System 📏
With a small team and limited budget, I treated the design system as a speed tool, not a branding exercise. I adapted a base system and added Heat-specific tokens, components, and state variants so implementation decisions were made upfront.

How it improved handoff

  • Developers built from a single set of components and swapped variants based on state, instead of rebuilding UI per screen

  • Tokens eliminated visual guesswork and reduced design questions

  • Naming conventions made designs searchable and faster to implement

  • Interaction rules reduced back-and-forth across flows

What I shipped

  • Tokens for color, spacing, typography, radius, and overlays

  • Reusable components with variants tied to product states (map pins, cards, sheets, tags)

  • Interaction rules for how the map and bottom sheets behave across flows

Thank you