Dopamp

Summary

DoPamp started as a "Tinder for motivation" idea from a first-time founder. I came in as his design partner, and together we validated the concept from scratch: I ran a 300-person research study across three user segments, built behavioral personas, and we pivoted the product model twice (from peer matching to community to AI agent) before defining an MVP ready for development. Along the way I stopped three high-risk directions before they cost time and money. The project is currently paused, but the strategic foundation and product direction are solid.

Problem Framing

The founder's original vision: People want to work out but lack motivation. The solution: connect "Ups" (people who'd been through the same struggle and overcome it) with "Downs" (people who need a push right now). Like Tinder, but for finding a motivation buddy. Community-driven, with gym partnerships for revenue later.

What was actually broken about this:

The concept was emotionally compelling but had critical product problems:

• Tinder mechanics in fitness are dangerous. Swiping through profiles in a fitness context easily becomes a "meat market." Full-screen profile photos would amplify this.
• Community requires critical mass. A two-sided matching platform (Up/Down) needs enough users on both sides to work. No user base means no matches, which means a dead app on day one.
• The founder's psychology was right, but the mechanism was wrong. The core insight, that motivation fails in a short window of resistance, was validated by research. But peer matching was the wrong way to deliver against that insight.

What research revealed: 300 people surveyed across 3 segments:

• Casual gym-goers: 134 responses
• Regular and experienced athletes: 107 responses
• Coaches and community managers: 59 responses

The key finding: motivation doesn't fail because people lack a buddy. It fails in a specific moment, usually post-work, at home, when willpower is lowest.

They don't need a person. They need an immediate intervention at the right time.

Role and Team

My role: Design Partner. Not just designing screens. Co-defining the product, challenging the founder's assumptions with data, and making strategic decisions together about what to build and what to kill.

The team:

• Founder (vision, funding, fitness domain expertise): making the idea real, getting to market, spending carefully.
• Developer (mobile development, joined later for MVP): technical feasibility, clear specs.
• Me (strategy, research, UX, product design, brand direction): validating before building, protecting the founder from expensive mistakes.

The dynamic: This was a first-time founder who was cautious about spending on a process that might not deliver. My job was to earn trust in the process by being transparent: showing the data, making decisions together, and being honest when an idea needed to change.

Approach

Step 1: Validate before anything.

No wireframes, no screens, no brand. First question: is this idea real? I designed and ran surveys for 3 user segments with different question sets. 300 responses total. This was the foundation for everything.

Step 2: Build personas from real data.

From the survey results I built behavioral personas that mapped motivation patterns, barriers, and what actually helps. The personas told a different story than the founder expected.

Step 3: Challenge the model.

The data showed the original Tinder-matching model had problems. I brought this to the founder with specific evidence, not opinion. Together we iterated on the model.

Step 4: Define the product together.

Every major decision was made together. I proposed, he challenged, we decided. This wasn't me delivering a brief. It was a partnership.

Step 5: Direct development strategically.

When the developer joined, I handed off generic screens first (registration, login, profile, messaging) so building could start while I worked on the core feature. That kept development moving without blocking on the hardest design problems.

Challenges

Challenge 1: Killing the founder's original idea (the Tinder model).

The founder was attached to the Tinder-style matching. It was his original vision. Telling him "this won't work" required more than opinion. I showed him:

• The survey data on when and why motivation fails (it's a moment, not a relationship).
• The risk of fitness plus swiping profiles becoming a meat market.
• The cold-start problem: who are the first 100 "Ups" on day one?

We explored alternatives together: small profile photos instead of full-screen, gender-separated feeds, even narrowing to a single tight-knit community as a beachhead. But ultimately the Tinder model didn't survive the data.

Challenge 2: The chatbot mascot debate.

The founder wanted an animated avatar or character as the AI interface. I pushed back: it feels childish and reminds people of WhatsApp sales bots. I argued for a clean, minimal chat interface inspired by ChatGPT and Claude. People already know how to interact with those. Just adapt the colors and tone for fitness and motivation.

This was a real disagreement. He felt the avatar would create personality and connection. I felt it would undermine credibility. We discussed it, I showed references, and he came around.

Challenge 3: Scope kept expanding.

The founder had big ideas: nutrition tips, psychological matching, community challenges, trigger detection near fast-food spots, gym-proximity notifications, integration with gym check-in chips. Each idea was valid on its own. My job was to say "yes, but not now." We scoped to the core: SOS button, AI diagnosis, 3 micro-solutions, verify, reward. Everything else was Phase 2 and beyond.

Challenge 4: The project paused.

The project paused for personal and budget reasons. It was self-funded, and runway got tight mid-build. This is a real risk with early-stage founders, and it's part of the story. The work we did (validation, personas, product architecture, MVP definition) is still valid and waiting.

Solution

The pivot: from peer matching to AI agent.

As AI matured during the project, we realized the technology could deliver what the community model couldn't: immediate, personalized intervention without needing other users.

The core flow (SOS model):

1. Home screen: large SOS button (single tap, zero friction).
2. AI asks: "What's blocking you today?" with 5 preset answers plus free text or voice.
3. AI suggests 3 ranked micro-actions, based on what worked for similar users, the user's current location (home, work, near a gym), and the time of day and past patterns.
4. User picks one (and can swap it if it doesn't fit).
5. Verification: did you actually do it? (GPS, gym chip, or self-report.)
6. Reward: credits for completing, and credits for sharing what worked.

Example micro-actions:

• "Put on your shoes." (Research showed that once the shoes are on, most people go.)
• "Play this 5-minute playlist and start walking home instead of taking the bus."
• "Do 5 push-ups right now, right where you are."

Smart features (designed, not yet built):

• Location-aware suggestions (near a gym gives a different prompt than at home).
• Psychological matching: if a solution worked for users with a similar profile, show a match ("87% match: this worked for people like you").
• Up/Down fluidity: the same user can be an "Up" (giving motivation) and a "Down" (needing it) on different days.

Visual direction:

• Dark background, navy with neon-lime accents.
• A focused, technical, immediate aesthetic.
• Inspired by professional training environments and clean AI interfaces.

What was deliberately cut from the MVP:

• Community features (matching, chat).
• Nutrition tips.
• Gym-partnership integrations.
• The challenge system.

Results and Impact

Research outcomes

• A 300-person survey conducted and analyzed across 3 user segments.
• Behavioral personas built from real data.
• Core insight validated: motivation fails in a short window, not from a lack of knowledge or community.

Strategic outcomes

• Pivoted the product model twice based on evidence (peer matching, to community, to AI agent).
• Prevented 3 high-risk directions before development: Tinder-style swiping (meat-market risk), an animated chatbot mascot (credibility risk), and a premature niche-only launch (scale risk).
• Defined an MVP scope that a solo developer could build.
• Clarified the business model: a credits system plus gym partnerships.

Product outcomes

• Complete product architecture defined.
• Core flow designed (SOS, diagnosis, solution, verify, reward).
• Lo-fi wireframes for all screens.
• Moodboard and brand direction established.
• The developer was actively building before the pause.

The honest result: The project is paused, but the strategic work (validation, personas, product definition) is intact and waiting. Sometimes the most valuable thing a design partner does is prevent expensive mistakes before they happen.

Three bad ideas were stopped before a single line of code was wasted on them.

Next Steps

What I'd do differently

• Push earlier for a conversation about funding and runway. A self-funded model is risky for a two-sided product. Flagging it in week 2 would have let us plan a leaner MVP or rethink timing.
• Document the survey methodology more formally. 300 responses is strong, but the analysis was mostly qualitative, and a more structured approach would have produced more shareable findings.

What the product needs to move forward

• Hi-fi screen designs for the full flow (the core screens exist; the rest of the lo-fi wireframes need to become real UI).
• Funding, or a co-founder who can code.
• A single gym partnership for a pilot.
• A defined day-1 user-acquisition strategy.

What this project taught me

Working with a first-time founder who is spending carefully requires a particular kind of trust. You can't just show up with a pretty deck. You have to show the work, share the data, make decisions together, and be honest when a beloved idea needs to die. That is what "design partner" actually means. Not "here's your mockup." It's "here's why we're not building that."