The configuration cost is the real barrier

Our research — Tiago's journey map and broader user interviews — showed why tools like iOS Focus Mode and Bixby fail: they front-load configuration, so people never get curious enough to explore the automations. Users weren't lazy; the setup cost was genuinely too high.

So we flipped it: the conversation becomes the onboarding. Presence asks for context progressively, only when it's earned — exactly where a screen-based form would add friction at the moment users are most overstimulated.

Existing context-switching tools fail because they front-load configuration before delivering any value. The conversation is the onboarding, and it asks for context only when it's earned.

Five phases, one conviction

The visual went through five phases — Galaxy, Tasting Field, Dust, Aura, Bloom — moving from drawing what the system does toward what it is. The hardest to kill was the Galaxy: that amber, almost bio-organic core circled by companion worlds. We were so invested we nearly renamed the whole project Symbiosis.

Symbiosis implies two things merging, and that's not what this is. Presence is something you feel but don't operate. Once we understood that, the name — and the galaxy — had to go.

Taste, rendered as colour

The second phase — Tasting Field — came straight from Ratatouille. We kept thinking about the way the film draws taste: the bursts of colour and shape that explode around Remy the moment food hits his tongue. That's synesthesia, and we wanted Presence to feel exactly like it — so every spoken phrase painted the dark with bursts of colour, each word its own hue, the field's breath riding the voice's volume.

It was, honestly, a screensaver that happened to talk — so we let the literal fireworks go. But it handed us the principle we carried all the way to Bloom: breath = voice.

Tasting Field came from Ratatouille — taste drawn as bursts of colour. We made every phrase paint the dark. We dropped the fireworks, but kept the rule it taught us: breath equals voice.

Someone is finally there

Through Dust and into Aura, the scattered motes gathered into a single luminous body — one warm core, breathing and drifting on slow organic paths. For the first time it felt less like weather around you and more like a presence with you. Beautiful — but still too nocturnal. One last flip remained.

Debugging the audio loop by hand

We built it for real — React and the OpenAI Realtime API over WebRTC, deployed as a PWA. The deepest problem was the voice hearing itself through the speakers and retriggering, which made it loop.

To find the exact threshold, I sat there and manually repeated sounds during the intro until one made the model restart — basically binary-searching the trigger point by hand. Then I replaced the guesswork with a proper audio gate: the mic stays closed while Presence speaks and opens only when it finishes. Reliable on every device and in any room, not just a quiet one.

The model was hearing itself and looping. I debugged it by repeating sounds until I found the exact trigger — then replaced it with a proper audio gate: mic closed during its speech, open only on completion.

A live product, not a mock-up

I deployed it as a PWA behind a QR code — a one-euro domain, a live server — so anyone could scan and use it. At the CMU evaluation, the room expected a Wizard-of-Oz prototype and got a functional, live product they could try themselves.

Real testing surfaced real behaviour: the model switched to Portuguese mid-session when we spoke Portuguese — emergent from its language detection. Honest scope: Presence proves the interaction concept; the real version needs OS-level network access a PWA can't provide — that's the next step, not a flaw.

The room expected a Wizard-of-Oz prototype. It was a live product they could scan and use. That surprise told us something about the gap between what people expect from student work and what's actually possible.

Always readable, never audio-only

Presence is voice-first, so it captions both sides of the conversation in real time — what you say, transcribed as you speak, and what Presence says, appearing word-by-word in step with its voice. There's no menu to find and nothing to switch on: the text is simply always there while it talks.

That makes a spoken interface fully readable for anyone who can't rely on audio — deaf and hard-of-hearing users, a loud room, or any moment where reading beats listening. The accessibility isn't a bolted-on mode; it's how the interface works by default.

From companion to operating system

The hardest, most important next step is OS-level network access — what lets Presence actually manage the phone the way the brief intended, instead of just demonstrating the conversation. From there we'd evolve the interface into something adaptable that gives trust back: a menu that reshapes around you, and a small companion bubble that follows you through the operating system — present, but never in the way.

The conversation is the setup

There's no form and no settings screen. You land on a black field with a single italic cue — speak to begin — and the moment you talk, Presence introduces itself and walks you through six spoken questions: how your week runs, when you do your best work, who must always be able to reach you, what should happen to messages during focus time, and how you want to be nudged when it's time to shift. Every answer is context the system would otherwise have forced you to configure by hand.

While Presence speaks, the screen blooms — warm light breathing in time with its voice — and both sides of the conversation are captioned live, so the interface stays readable, never audio-only.

This is the one

Flipped to light: a motion-blurred bloom of warm light floating in a bright room, the name bold and still. Dead Space-minimal — only the name and a sliver of progress. The interface disappears and leaves only the being. Home.

Autonomy vs. oversight

Teenagers need autonomy over their health information to build trust with providers and develop self-advocacy — while parents need appropriate visibility for safety. The whole product comes down to one decision: where you draw the line between what a parent can and can't see.

Built as a team

On a team of three, we shared the work — research, interviews, and design alike — and shaped the direction together: the information hierarchy, what each persona sees and what's hidden, the interaction model for the GP chat, and the three-tier visibility structure across profiles. The thinking behind what is shown to whom came out of that shared work.

The trust problem solved the design problem

We researched with parents aged 25–46 and found genuine disagreement — some felt teen autonomy was essential, others wanted full visibility. The deciding insight was what I call the trust problem: no abusive parent downloads an app that limits their access. So the system can safely grant teens real privacy, because the people most likely to misuse oversight self-select out.

The edge case that drove the design: a teenager dealing with substance use who can't talk to their family — that's exactly the user who needs the confidential chat most.

No abusive parent downloads an app that limits their access. That's why we could give teens genuine clinical privacy — the edge case we designed for was a teenager in crisis who can't speak to their family.

Full privacy vs. a tiered model

A teammate argued for full privacy in sensitive cases like pregnancy. I argued for a tiered model — teenagers are still financially and legally dependent on their parents, so total opacity isn't always safe or practical. The research broke the deadlock: what parents actually wanted was for their kids to develop autonomy naturally, with trust built progressively. We landed on tiered visibility, with parental access to non-sensitive information by mutual agreement.

A research-driven concept

MediConnect is a research-driven concept prototype: two high-fidelity apps that make the privacy argument concrete. The parent app handles booking, family management, and notifications but no access to the teen's private health data; the confidential chat and emergency support are teen-only. The contribution isn't the screens — it's the defensible boundary underneath them.

Plenty of choice, hard to discover

TrendWear, an online fashion retailer, had falling retention and repeat purchases. Despite wide variety and frequent sales, users couldn't find items matching their taste. The goal: improve discoverability and encourage repeat purchase.

Maria doesn't have hours to scroll

Our primary persona: Maria, 29, an art director in Lisbon — busy social life, follows fashion influencers daily, zero patience for endless catalogue scrolling. Her frustration is the product gap in one sentence: she sees an outfit on social media and can't find it in the store.

I want to look amazing at every event — but I don't have hours to scroll through hundreds of items to find the right one.

Nine ideas, one bet

We didn't jump to AI. The ideation round produced nine candidate fixes — free returns, a favourites system, fidelity points, moodboards, picture uploads, simple recommendations, a virtual fitting room, even a gamified BattlePass. We converged on the AI-powered product finder because it attacked the actual problem — items seen on social media being unfindable in the store — instead of decorating around it.

Photo → recommendation → checkout

You photograph an outfit you like; the AI suggests matching items in the store; dot indicators let you select the specific piece you mean (an outfit is many items — which one?); you add to cart and check out without leaving the app.

Define success before you test

We set the success criteria up front — at least one add-to-cart per participant and 75% checkout completion — rather than asking "does it look nice?" With 7 participants, 6 of 7 completed checkout, clearing the target. The one who dropped off was missing a back-navigation path to return to other products: a fixable problem we identified but didn't iterate on, since TrendWear was scoped as a methods exercise, not a full case study.

We set behavioural success criteria before testing — add-to-cart and 75% checkout — not 'does it look nice.' 6 of 7 participants completed checkout. The one who dropped off was missing a back-navigation path. The real value was learning to define what success looks like before you test.