Pair

An App for a Long-Term Relationship

Overview

End-to-end design of a couples app — concept on paper, eight participant interviews, FigJam affinity, two personas, a two-track user flow, and a hi-fi mobile design system. The artifact below is the chain from research to screens, presented in the order it actually happened.

My role

Sole designer, 2020 — research through hi-fi, end to end. This is a concept project: there’s no shipped app or usage data behind it. The artifact is the research process and the design decisions that came out of it — every step earns the next one.

Problem

Long-term couples drift. Not from love — from attention to specifics. The small acts that say “I see you” — a meal you’d like, a favor you’d been meaning to do, a kind of touch that matters today — get crowded out by everything else. Most people don’t have a partner problem. They have an execution problem: thoughtful intent without a system that surfaces it on the day it’d actually land.

The product question wasn’t “how do we fix relationships.” It was: can a small mobile app act as the prompt — gentle, low-friction, two-sided — that gets couples to do the things they already meant to do for each other.

Approach

Concept on paper, before users

Before recruiting anyone, I sketched eight loose UI ideations to know what I was even asking about. Color-coded annotations — what the home screen needs to feel like, where the task list lives, what the “you finished it” exchange looks like. The sketches weren’t right; that wasn’t the point. They were enough to make the interview questions specific.

Recruiting and interviews

I recruited participants through a Google Sheet — couples in long-term relationships, mixed ages, mixed countries, mixed digital literacy. The screening filters were time-in-relationship and comfort with mobile apps. I kept the sheet as the participant log so I could come back to people for follow-ups.

Synthesis

FigJam affinity. Five columns came out of the notes — Devices and Digital Literacy, People Characteristics, Potential Users’ Motivations, Users’ Needs and Wants, and Thoughts and Features. The pattern that mattered: people didn’t want a relationship CRM. They wanted a nudge to be the version of themselves their partner married.

Personas

Two — Anna Volkova (32, Marketing/Media in IT, Warsaw) and Dmitriy Ryschyk (35, self-employed photographer, Warsaw). Both high digital literacy, both married, both fluent in two languages. Anna wants fewer arguments and a calmer baseline. Dmitriy wants to understand his wife better and bring them to the next level. Different framings, same underlying need: a way to remember.

I treated Anna and Dmitriy as a test panel for every later decision. Would she follow this flow. Would he respond to this copy.

Sketches, this time informed

Back to paper, but this time the IA came from the participants’ words instead of my pre-research guesses. Red-pen revisions on each screen — what to drop, what to merge, what to test next.

The flow that surprised me

Pair only works if both partners are in. The user flow has two parallel tracks — User A and User B — connected by notifications, shared tasks, and a feedback exchange after each completion. Four phases: sign-up and invitation, first questionnaire, onboarding, and the repeating core experience.

The flow was the artifact I redrew most. It’s easy to design a single-user task app. It’s much harder to design a two-user system where neither side stalls if the other is slow.

Hi-fi — three surfaces

Onboarding. Eight questions, one category at a time — Routine, Sex life, Rituals, Pastime, Emotional Responsiveness. The taxonomy comes straight from the affinity diagram.

Today. A horizontal date strip across the top, today’s tasks below, a bottom nav for Home, Tasks, Notifications, and Profile. The screen is sparse on purpose — the day’s ask is the headline, everything else is in service of it.

Task detail. “Romantic dinner” with an image, a “Why this is important” note, partner-specific tags pulled from onboarding (“Her preferences: Italian, wine, capricciosa”), and a single CTA: “Book a restaurant.” This is the moment the app pays off — context exactly when you need to act on it.

Alternatives considered

Passive inline AI tips, not a chat assistantOut of scope here — but the equivalent call was nudges vs. notifications: gentle, dismissible prompts on the day a task lands, rather than a noisy notification stream that trains people to mute the app.
A single-user habit trackerSimpler to build and validate, but it loses the whole point. The feedback exchange between partners is what turns a chore list into a relationship gesture; one-sided, Pair is just a calendar.
A relationship “CRM” with rich profilesResearch said people didn’t want to manage their partner like a contact record. They wanted a small nudge to be their better self — so the data model stayed light and the daily ask stayed front and center.

Reflection

What I’d do differently. Validate a single-side version first. Two-sided products are 4× harder to land, and I designed the two-sided version before testing whether one partner alone gets enough value from the daily nudges. A single-side wedge — “remember the small things for your partner” — is a faster path to learning whether the prompt itself works.

What surprised me. The people most willing to download a “relationship habits” app were the people who needed it least. Anna and Dmitriy aren’t the hard users. The hard users are partners who don’t think they have a problem — and the app has to land for them without feeling like an accusation.

What I’d keep. The feedback exchange after each task. People in interviews lit up when I described it — a small thank-you, a “this was great,” a “next time, with less rosé.” It’s the part that turns a chore list into a relationship gesture, and it gives Pair its emotional shape.

QuantRule

No-Code Risk Decisioning Platform