Day 2: Defining the Core Experience of a Privacy-First Running App

On Day 1, I defined the product problem and the main hypothesis behind the app:

A running app where progress is the core experience, and sharing is a choice.

Today, I want to move one step closer to the actual product experience.

Before designing screens or writing code, I need to define what the user should be able to do, what the first version should include, and what should wait for later.

This is where the idea starts becoming a product.

The core user experience

The main flow I imagine is simple:

A user logs in, starts a run, tracks the activity, reviews progress, and decides what to do with that data.

The app should not push the user into a public feed.

It should not assume every run needs to be shared.

It should first help the user run, improve, and stay consistent.

At a basic level, the core experience should look like this:

Log in → Start a run → Track route, time, distance, and pace → Finish the run → Review progress → Keep private or share intentionally

That flow is the heart of the product.

Everything else should support it.

Photo from Unsplash.

Starting a free run

One of the first features should be a simple “free run” mode.

The user opens the app and starts running without needing to configure a full training plan.

This matters because many runners, especially beginners, do not always want complexity.

Sometimes they just want to go outside, press start, and run.

During a free run, the app should track:

• time
• distance
• pace
• route
• progress during the session

The live tracking screen should be focused and readable.

No distractions.

No unnecessary social elements.

No feed.

Just the information the runner needs while moving.

Music without breaking the running experience

One idea I want to explore is allowing the user to control music without leaving the app.

For example, if someone is listening to Spotify while running, it would be useful to access basic playback controls directly from the running screen.

I still need to research what is technically possible depending on platform limitations, permissions, and Spotify’s API.

So for now, I would not treat this as a guaranteed MVP feature.

But as a product idea, it makes sense.

When someone is running, switching between apps can be annoying. The ideal experience would allow the runner to stay inside the app while still controlling basic music playback.

For the MVP, this may start as a simple media control concept.

Later, it could become a proper integration if technically feasible.

Training history

A running app needs memory.

If the user cannot see previous runs, compare progress, or understand consistency over time, the app becomes just a tracker.

I want the user to have a clear record of their training.

The activity history should include:

• past runs
• date and time
• distance
• duration
• pace
• route
• personal notes, eventually
• whether the activity was private or shared

This history is important because progress is not always visible day by day.

But over weeks, patterns start to appear.

The user should be able to look back and understand:

Am I running more consistently?

Am I getting faster?

Am I increasing distance?

Am I closer to my goal?

User-defined goals

Another important part of the product is goal setting.

Instead of forcing predefined plans from the beginning, I want users to define their own goals.

For example:

“Run 10K.”

That could mean different things depending on the person.

For one user, it may mean preparing to run a 10K race.

For another, it may mean reaching the ability to run 10 kilometers without stopping.

For another, it may mean completing 10 kilometers per week.

This means the app needs to be careful with goal design.

At first, I would keep goals simple.

Possible goal types:

• weekly distance goal
• target race distance
• consistency goal
• personal distance milestone

For the MVP, the simplest version could be:

Set a weekly distance goal and track progress toward it.

Later, the app could support larger structured goals like:

• prepare for 5K
• prepare for 10K
• improve pace
• build consistency
• return to running after a break

But for the first version, weekly goals are probably enough.

Route tracking

Route tracking is one of the most valuable features of a running app, but also one of the most sensitive.

The app should record the route during a run, but the user should remain in control of how that route is stored and shared.

At the product level, route tracking should support:

• recording the path of the run
• showing the route after the activity
• calculating distance
• connecting the route with pace and time data
• giving the user control over route visibility

This is where the privacy-first approach matters again.

A route can reveal sensitive patterns.

So route sharing should never be automatic.

The app should also eventually support privacy controls such as hiding the start and end points of a route, especially if the run starts near the user’s home or workplace.

Sharing as an intentional action

I do not want sharing to be the center of the app.

But I do want sharing to be possible.

The difference is important.

After finishing a run, the user could choose to generate a shareable image.

Before generating it, the app should ask what the user wants to include.

For example:

• show distance
• show time
• show pace
• show route
• hide route
• hide start and end points
• show only the achievement
• include the weekly goal progress

This gives the user control.

Instead of assuming that every metric and route should be public, the app lets the user decide.

A shared image could be simple:

“5.42 km completed”

Or more detailed:

“5.42 km · 32:18 · 5:57/km pace”

Or route-based:

“Morning run completed” + map preview

The key principle is:

The user chooses what gets exposed.

That is a very different experience from social sharing by default.

Places of interest and recommended routes

Another idea I want to explore is helping runners discover places to run.

This could include:

• parks nearby
• recommended running routes
• safe or popular running areas
• places of interest near the user
• user-curated running routes

This feature could be especially useful for people who are new to an area, traveling, or looking for safer places to run.

However, this is probably not a Day 1 MVP feature.

It belongs to a later product layer.

The first version should focus on personal tracking and progress.

But in the long term, recommended routes could become a strong differentiator.

The important part is that route discovery should still respect privacy.

The app can recommend places to run without forcing users to publish where they personally run.

MVP vs. later features

At this stage, I need to separate what belongs in the MVP from what belongs in the product vision.

The MVP should be small enough to build, test, and learn from.

The product vision can be bigger.

MVP features

For the first version, I would focus on:

1. User account
2. Free run tracking
3. GPS route recording
4. Distance, time, and pace
5. Activity history
6. Weekly goal tracking
7. Private activities by default
8. Post-run summary
9. Optional sharing
10. Basic share image generation

That would already be enough to test the core idea.

Can users track runs?

Do they understand the privacy model?

Do weekly goals motivate them?

Do they care about controlling what gets shared?

Later features

Features that can wait:

1. Spotify or media controls
2. Recommended running routes
3. Nearby parks
4. Places of interest
5. User-curated routes
6. Advanced training plans
7. Social profiles
8. Clubs or groups
9. Challenges
10. Public route discovery

These features may be useful later, but adding them too early could distract from the core loop.

The first version should prove the foundation:

Run → Track → Review → Improve → Share only if desired

The first product flow

Based on this, the first product flow could be:

1. User logs in
2. User sees weekly progress
3. User taps “Start Run”
4. App starts tracking route, time, distance, and pace
5. User finishes the run
6. App shows a post-run summary
7. Activity is saved as private by default
8. User chooses whether to generate a share image
9. User selects what data appears in the image
10. Weekly goal progress updates

This flow keeps the app focused.

It also puts privacy in the right place: inside the experience, not hidden in settings.

Product principle for Day 2

The product principle for today is:

The app should help users improve without forcing them to expose themselves.

That means the design should make progress visible, but sharing optional.

It should make route tracking useful, but route exposure controlled.

It should make goals simple, but meaningful.

It should help the user build consistency without turning every run into content.

What I need to validate next

After defining this core experience, the next questions are:

1. Is the free run flow enough for the MVP?
2. Should the first goal system focus only on weekly distance?
3. What information should appear in the live run screen?
4. What information matters most in the post-run summary?
5. How much control should users have when generating a share image?
6. Are recommended routes important early, or should they wait?
7. Would users value privacy controls enough to choose this app over existing options?

These questions will guide the next step.

Next step

The next step is to turn this product flow into low-fidelity wireframes.

I do not want to design a polished interface yet.

First, I need to map the screens and decisions:

• home dashboard
• start run screen
• live tracking screen
• post-run summary
• sharing options
• activity history
• weekly goal progress

Day 2 is about defining the experience before designing the interface.

The app is still early.

But the direction is becoming clearer:

A running app focused on progress, goals, and privacy-first tracking — with sharing as a choice, not a requirement.