Having a long day?Pink noise, even across every octave with a slow 10 Hz swell, takes the edge off the room. Attention lasts longer when less is competing for it.

Human-first NLP · People Matching

Building enough safety for someone to type the thing they actually want.

What do you want to do today?

Role
Lead designer — solo
Scope
MVP · design to handoff
Status
Paused at pre-launch
Practice
Product Design · Human-AI Interaction

Tribe is a human search engine for social life and networking. You type one sentence about what you want to do today, the AI finds people who want the same, and you meet them in person.

Its core features: a prompt field that highlights what the matcher can use as you type, a wait screen that shows what the AI is doing, and one chat at a time with two safe exits. I designed the MVP solo, from architecture to developer handoff.

The Tribe prompt field. It starts on the placeholder “What do you want to do today?”, then the intent “I’m looking to play basketball in Budapest this afternoon.” is typed in. As the words land the What, When and Where chips light up, the confidence dot turns green, and the FIND THEM button unlocks.
Intent overlapping into a system, through to a meetup Four equally sized circles. Intent and match overlap - a dot sits at the centre of the hatched intersection, with a line rising from it to a caption above the circles reading validation gap, written out in full rather than fitted inside the small overlap itself. Below both circles, a dashed bracket spans the full width of the venn - intent's left edge to match's right edge - labelled NLP engine, showing that mechanism is what produces the whole overlap, not just the gap. From match, a line continues right, labelled progressive disclosure on two lines above it, to the anonymous reveal circle - the one node drawn filled and in ink, because it is the mechanic the study turns on - then on to meetup with no further label, matching the source's own last, unnamed connector. No circle is drawn larger than another - the overlap comes from how close intent and match sit, not from their size. Intent Match Validation gap NLP engine Progressive disclosure Anonymous Reveal Meetup

Social app where AI matches strangers from one prompt.

The whole product rests on one text field, so the design problem was making someone feel safe enough to be honest in it.

There is no profile and nothing to browse, and people connect before either of them knows who the other is.

Trust can break at three moments.

Between typing a wish and meeting a stranger, trust can break three times: while typing, while the AI works, and when the match arrives. Each moment has its own design answer.

Where does trust break between typing and meeting someone?

Intent + vulnerability

Fear of sharing before trust is established

→ Smart Echo Input

Black box anxiety

Stress during AI processing

→ XAI teachable wait

Decision fatigue

Skepticism of match results

→ XAI confidence badges

Honest prompts need trust first.

The brief was an intent-based social network for Budapest. Once I had mapped the competitors, the real question was how to get someone to type what they actually want, unedited, into a field that matches them with strangers.

The decisionChose intent-first (one prompt, no profile) over engagement-first (profiles, browse, swipe), because people needed a safer way to connect. Cost: managed friction: a harder first screen than a profile grid.

Tribe bets on intent over engagement.

Most social apps measure time in the app and ad impressions, so they lead with profiles, browsing and swiping. Tribe measures how well intent turns into a connection, so it leads with one prompt, anonymity and privacy built into the structure.

What if a social app optimised for trust?

The market

Engagement-first

Primary KPI
Time-on-app / Ad impressions
Friction
Low barrier to contact, high volume, deferred privacy layers
  1. Visual Profiles
  2. Asynchronous Browse
  3. Swipe

Tribe’s bet

Intent-first

Primary KPI
High-intent connection efficiency
Friction
Managed friction, progressive disclosure, structural privacy
  1. Real-time Intent
  2. Semantic NLP Matching
  3. Anonymity
  4. Safety Layer

How might we make it safe to type what you actually need?

The Tribe Trust Framework, mapped from problem to outcome A map from one problem to one outcome. On the left: people don’t type what they actually need, because the barrier is psychological, not linguistic. That fans out into the five things a person feels before typing, and each one runs across to what the system does about it: Social judgement (What will it think of me?) is answered by Non-evaluative framing (No implicit scoring); Language failure (No words for this) is answered by Intent inference layer (NLP bridges the gap); Trust deficit (Will it use this against me?) is answered by Transparency by design (Visible logic, no black box); Vulnerability (Admitting I don’t know) is answered by Curiosity-safe scaffolding (Not knowing = valid entry); App parasitism (Will it exploit my need?) is answered by Minimal footprint (Tool exits once done). Trust deficit is drawn in ink as the core pair. The five responses converge on the right into the hypothesis the product is built to test: that honest intent gets typed, context is read, and the person finds what they actually needed. The product is pre-launch, so this is the expected result rather than a measured one. The problem People don’t type what they actually need. The barrier is psychological, not linguistic. Social judgement What will it think of me? Non-evaluative framing No implicit scoring Language failure No words for this Intent inference layer NLP bridges the gap Trust deficit Will it use this against me? Transparency by design Visible logic, no black box Vulnerability Admitting I don’t know Curiosity-safe scaffolding Not knowing = valid entry App parasitism Will it exploit my need? Minimal footprint Tool exits once done The hypothesis Honest intent typed, context read, the person finds what they actually needed.

The search box is a psychological safety problem.

So Tribe is designed for the moment before someone types the query.

Mapped where people feel exposed, before any screen.

I used human factors as the frame. The interaction gap diagram was my first deliverable: it gives each of the three states a design response, and it became the brief for every decision after it.

“The product’s job is psychological safety — enough of it that someone types the thing they actually want.”

Three states, three answers.

Smart Echo Input answers the fear of sharing, a teachable wait answers the anxiety of the AI’s black box, and confidence badges answer doubts about the match.

How might each vulnerable moment get a design answer?

Human-AI interaction gap — three vulnerability states mapped to design responses: Smart Echo Input, XAI teachable wait, XAI confidence badges

Failure states first: that is where trust breaks.

Each decision answers one moment where trust could break before it has formed.

The decisionChose to design the fallbacks before the happy path, over finalising the happy-path UI first, because the edge cases decide the product’s character. Cost: slower to a first screen anyone could look at.

One sentence runs through three layers.

What the person feels, what the interface shows and what the system does run in parallel. The prompt goes down to the NLP engine, and the match comes back up as trust, revealed step by step.

How does one sentence become a meetup?

How intent becomes a meetup, across three layers A three-lane architecture diagram. The human layer runs left to right: intent input, privacy hesitation, calibrated trust, real-world meetup. The UI layer runs beneath it: prompt field, validation signal, progressive disclosure. The system layer runs beneath that: NLP engine, semantic matching. Intent input drops down to prompt field; privacy hesitation drops down to validation signal; validation signal drops down to the NLP engine. Semantic matching rises up into progressive disclosure, which itself rises up into calibrated trust - the only two upward arrows in the diagram, showing the system's result surfacing back to the person. Human layer Intent Input Privacy Hesitation Calibrated Trust Real-World Meetup UI layer Prompt Field Validation Signal Progressive Disclosure System layer NLP Engine Semantic Matching

Fallbacks mapped like the happy path.

The edge cases carried the most weight: the no-match screen, the breathe chat and the safety exit.

What happens on every screen, including when things go wrong?

Functional sitemap and user flow hybrid — full IA, screen states, decision points, and safety exit branches
A sitemap and user flow in one. I mapped every screen state, decision point and safety exit before any visual design.

What happens when the match doesn’t come?

Core happy path — 10 screens from home to post-meet feedback, plus three fallback states: no match, match declined, all matches exhausted
The core happy path (screens 1–10) and three fallback states, with the key states noted for each screen.

Not everything survived the dev sync.

I designed three generations of input validation. The developers raised two concerns, that the redundancies risked misreading people and that the API calls cost too much. Gen 3 answered both and was accepted once I made the case for it, and the match logic, processing states and safety exits were built around it.

The decisionChose Gen 3, real-time NLP chip validation, over Gen 2, AI metadata extraction, because match quality is the entire product bet: vague input, bad matches, no Tribe. Cost: harder to build, and it took a clear case to get it accepted.

Three ways to check a prompt; one shipped.

Free tags gave the matcher nothing to work with, and AI extraction was too slow and costly. Chip validation reads what, when and where as the person types.

Which of three ways to check a prompt protects the match?

Gen 1 — manual tags added by user
Gen 1 — Cut
Manual tags

Freeform text with no structure, and the system can’t match on noise.

Gen 2 — AI-generated metadata tags from prompt
Gen 2 — Cut
AI metadata extraction

Smarter, but the JSON was unreliable, it took 1.4 s and it cost 25× the tokens.

Gen 3 — NLP chip validation, Well done badge, CTA unlocked
Gen 3 — Accepted
Chip validation

NLP reads What, When and Where as you type. It is hard to build, and it was worth the effort.

Gen 2 failed on reliability, speed and cost.

The developers found three problems: the model’s answers broke the parser, extraction added a 1.4 s wait, and classifying a prompt cost 25× more than processing it.

Why didn’t AI extraction survive the dev sync?

Why Gen 2 was droppedAfter synching with devs
Structural unreliability The system expects {"tags":["x","y"]}, but the LLM answers in conversational text, so parsing fails. Every call needs a retry wrapper just to extract two words.
Latency 800ms standard + 600ms metadata extraction = 1.4s wait before anything useful happens.
Token cost A 15-word prompt needs a 400-token system prompt to classify it, so categorising costs 25× more than processing. An MVP budget can’t carry that.

Chips show what the matcher understood.

As the person types, a chip lights up for what, when and where. When all three are confident, the button unlocks.

How might we teach users what’s needed for prompting that leads to better match quality?

Accepted version — chip validation in action

Chip validation — 9 states 1 / 9
Chip validation states — nine frames of the prompt field, from empty to unlocked

Empty state — placeholder: “What do you want to do today?”

Four failure modes, four messages.

Each of the four failure modes gets its own message. The one for offensive input doesn’t scold the person who typed it.

How might we correct people without scolding them?

InputWhat it says
Offensive or inappropriate: swearing, shaming, sexual, aggressive, racist“Let’s keep it respectful. Try rephrasing your intent.”
Numbers only, invalid characters, no real words“Invalid characters. Please describe your intent in plain words.”
Over 50 characters“Keep it simple — a short sentence is enough. You can add tags to make your search more accurate.”
Misspelling, as in sqashing“Did you mean squashing?”

The wait explains itself.

While the AI matches, the screen shows each step it takes. Location access is asked for only once its reason is on screen, and both people stay anonymous until both say yes.

How might a wait build trust?

01 · Processing Processing — teachable wait, 3-stage ascending stack
Teachable wait

The wait shows what the system is doing at each step. Because the user can see the processing, the wait builds trust.

Used once, then gone

It appears once step two completes, so the reason for the request is on screen before the request is made. My call was to delete location data after a match and use only aggregated data for analytics, because that keeps users safer and earns their trust.

02 · Location access Processing — location access permission
match found no match
Anonymous until mutual yes

Initials and a match score, no photos. Identity is revealed only after both people say yes, so neither of them knows more than the other.

3A · Match Match results — anonymous until mutual yes
3B · No match No match — Luck is around the corner
“Luck is around the corner”

Warm orange, softer than red. Nearby intents appear below, so the person gets real options without manufactured optimism.

One chat at a time, two safe exits.

I limited it on purpose, because people take a single chat more seriously: when choices are limited, people value what they have.

The two exits are the Breathe Chat, a 24-hour pause, and the Safety Exit. Without them, a single chat would be a trap. It is also a bet against dopamine loops: no infinite scroll and no variable reward.

How might one chat at a time stay safe to leave?

More menu More menu opened in chat

A 24-hour pause makes stepping away feel temporary. The user keeps the connection and loses the pressure.

Breathe chat Breathe chat — 24h pause
Leave chat Leave chat — five exit reasons

Five exit reasons, with “I’m feeling unsafe” set apart in red at the bottom. Because it stands apart, someone who feels unsafe finds it without scanning the list, and a casual exit stays easy.

Tapping opens the report on the same screen, because this is the most stressful moment in the app and it should take no extra steps.

I feel unsafe I’m feeling unsafe — selected state
Report inline Report user — inline, zero navigation cost

The report appears in the same row, so the user finishes it where they already are.

One design system for the build.

Once the wireframes, structures, user flows, design system and core features were prototyped, we decided to continue the build with vibe coding.

I built Tribe’s design system too. The full spec:

What holds Tribe together visually?

Tribe design system: typography scale, corner radius, the four brand colours and the icon set. Design system Tribe colour system: surface, chalk, terra and sage shades, plus error, success and system colours, each with its token and usage. Colour system Tribe mobile grid and spacing: 390px screen, 4 columns, 24px margin, 16px gutter, and the spacing scale from 4 to 40. Grid and breakpoints Tribe components: buttons, match cards, chips, the previous-intents drawer, text input, the location modal, the error state and the input field through its validation states. Components Tribe interaction notes for the landing, processing, match results, no-match, chat and menu screens. Interaction notes Annotated wireframes of the landing and prompt workspace, the processing state with its summary, the location permission, and the error messages. Annotated wireframes

Every constraint that survived had a human reason.

Every constraint that survived the dev sync had a human reason behind it, which is why I would still push back on anything that doesn’t serve the user. Next time, a questionnaire would come before the first screen.

The one metric I would track is how prompt quality relates to match quality. Whether the two move together would tell me if the core idea holds.

Phase 1 — UsabilityPre-Launch Lab Testing Phase 2 — TelemetryAlpha Field Testing
Objective Verify if real-time keyword highlighting reduces input anxiety and ensures semantic accuracy. Validate the NLP matching engine and progressive disclosure mechanics under live infrastructure load.
Methodology Moderated testing (8–10 participants) using low-fidelity click-dummies. 14-day unmoderated field test deployed to a high-density cohort of 500–1,000 target users in Budapest.
Signals Time-on-task, token correction frequency, and subjective workload (SEQ score). Progress toward the target ≥40% match-to-meetup conversion milestone, live data logging against the <40% engine failure threshold, and exact drop-off points within the unmasking sequence.

What the team said.

Two people from the Tribe team on the design.

What did the team think?

“This is very, very high level. I like it a lot.”

— CTO, Tribe

“This is an app I’d actually want to see built.”

— AI Engineer & Neuroscientist, Tribe