This project is password protected
Designing Nearville: Reducing Friction as a 0→1 Marketplace Grew
Using systems thinking to identify and reduce friction across connected marketplace flows.
Founding Product Designer
5 months
Marketplace
P2P
Mobile
0→1
Nearville is a peer-to-peer rental marketplace where users borrow and lend everyday items.
As the product moved beyond early MVP usage, we began to see hesitation and drop-off—not because features were missing, but because the experience had become too complex too early. Users were asked to understand multiple states across booking, cancellation, messaging, and in-person handoff before they felt confident committing.
I used systems thinking to step back from individual screens and audit the product end-to-end, identifying where connected experiences were creating unnecessary cognitive load—and where simplification would have the biggest impact.
Role & Scope
As a Founding Designer, I:
Audited renter and owner journeys end-to-end to identify friction points
Designed core mobile flows (booking, cancellation, pickup/return)
Clarified system feedback through notification and state logic
Applied systems thinking to simplify connected marketplace experiences
Timeline
Post-MVP iteration and development (~5 months)
Team
3 Designers
3 Engineers
2 PMs
The Problem
As Nearville moved beyond early MVP usage, users hesitated to commit—not due to missing features, but because the product surfaced too much complexity too early.
Disconnected states across booking, cancellation, messaging, and handoff increased cognitive load and reduced confidence at key decision points.
The Solution
I took a system-level approach—mapping connected renter and owner flows to identify where complexity surfaced, then simplifying decisions and handling edge cases invisibly.
The focus was not removing functionality, but reducing what users needed to understand at each step to move forward with confidence.
Impact
50%
Faster onboarding
5X
Increase in sign-up completion
Measuring
Conversation rate
Hesitation wasn’t caused by missing features—it emerged from compounding complexity
Early MVP usage revealed a clear pattern: hesitation wasn’t driven by confusing screens, but by the product asking users to reason about too many states and edge cases too early. As a peer-to-peer marketplace coordinating real-world exchanges, complexity accumulated across time—not at a single interaction.
The problem wasn’t usability in isolation, it was systemic complexity across the renter–owner experience.
01.
Renter ↔︎ Owner
→ Two-sided flows with asymmetric motivation
02.
Digital & Physical Touchpoints
→ Real-world handoffs requiring coordination, trust and timing
03.
Possible edge-cases
→ Driven by asynchronous decisions, shifting responsibility, and physical handoff uncertainty
I approached the problem with a systems-thinking lens
Rather than optimizing individual screens, I stepped back to map renter and owner journeys end to end—tracking how decisions, states, and notifications interacted across time and physical handoff. This reframing shifted the problem from fixing isolated UI to reducing cognitive load across the entire experience.
Early hesitation wasn’t about trust in the product—it was about being asked to commit too early.
Early feedback from potential users revealed a consistent hesitation:
New product
Low trust at first contact
Hesitation to sign up before interaction
This wasn’t resistance to the idea of peer-to-peer rentals — it was resistance to early commitment without clarity. To understand why, I audited the experience end to end.
Auditing the product from a bird’s-eye view
Before making changes, I stepped back to examine renter and owner journeys end to end—across system states, notifications, and real-world handoffs. Instead of reviewing screens in isolation, I focused on how decisions and states accumulated over time, and how much reasoning was required before users could simply explore.
User feedback and product audit revealed a clear gap between product assumptions and user reality.
Signal 1: The product assumed readiness before users had context
Users were asked to download the app and complete onboarding before they could meaningfully explore listings or understand how renting worked. Commitment was required before users had context or confidence.
Signal 2: The "are we really making the users' lives easier?" question
Travel to a physical hand-off
Coordinate hand-off time & location
Fill in details, pick price to list
Verify exchange
Travel for return
Confirm completion
Leave review
Early flows bundled too many operational responsibilities into a single journey. While each step made sense in isolation, together they created an experience that felt heavier than necessary for first-time use.
For an early-stage marketplace, the experience asked users to manage logistics, trust, and coordination before they had experienced value.
Reducing friction before commitment
Early user conversations showed hesitation to sign up before understanding the value of the product.
Instead of requiring onboarding upfront, we delayed account creation—allowing users to explore listings first, and prompting sign-up only when they attempted to list or request an item.
Before - Signup and onboarding required before accessing the app
After - Explore-first entry, signup triggered by listing or request
Not all structure was necessary in the early product phase
The audit showed that pickup and return tasks added significant cognitive load early on—before traction or stable usage patterns had emerged.
We removed these tasks in the early phase, preserving the ability to reintroduce coordination later once real patterns and needs became clear.
Before - Task-heavy pickup & return flow
After - Easy and intuitive pickup & return flow
We prioritized deliberate trade-offs over early completeness, evaluating each decision against shared constraints that evolved as the product matured.
Each major decision was evaluated against a shared set of constraints—recognizing that these would shift as the product matured. Some major decision constraints were:
Timing
Is this the right moment to ask users to take on this responsibility?
Resource feasibility
Can the team support this reliably at our current scale?
Learning priority
Does this help us learn now, or lock assumptions too early?
Risk tolerance
If this fails, can users and the system recover safely?
Decision 01 — Reduce early commitment without removing safety
Challenge
Early onboarding asked users to commit before they understood how Nearville worked, contributing to hesitation.
Decision
We re-sequenced signup to allow exploration first, gating safety mechanisms to higher-intent actions.
Rationale
This reduced early friction while preserving trust and safety during first use.
This decision was appropriate for Nearville’s early stage and continues to be re-evaluated as usage evolves.
Decision 02 — Defer structure until usage patterns stabilized
Challenge
With flows still evolving, enforcing consistency too early risked locking incorrect assumptions.
Decision
We allowed controlled inconsistency to preserve learning velocity, consolidating only after real usage patterns emerged.
Rationale
This avoided premature optimization and kept the system adaptable as real usage clarified.
This approach prioritized learning early and was revisited as patterns stabilized.
From Early Hesitation to Measurable Progress
By re-sequencing when commitment was introduced and reducing early structural complexity, Nearville shifted from an MVP that asked users to reason too much, too early to an experience that progressively revealed intent and responsibility.
Instead of optimizing for feature completeness, we optimized for decision clarity
This reduced hesitation at critical moments and unlocked measurable improvements in early conversion, while preserving flexibility as usage patterns evolved.
50%
Faster onboarding
5x
Growth in sign-up completion
Measuring
Conversion rate
Using metrics as directional signals, not endpoints
In an early-stage, trust-sensitive marketplace, metrics were treated as directional signals—not endpoints—used to validate whether changes reduced hesitation and clarified decision-making rather than prematurely optimizing local maxima.
I also led Nearville’s design system work, which informed many of the system-level decisions described here. For a deeper look, see the Design Systems case study.
This project reinforced how to design effectively in an evolving early-stage product—balancing structure with adaptability amid shifting priorities and uncertainty.
Design for shifting priorities, not fixed roadmaps
Designing guardrails instead of rigid solutions made it easier to adapt as priorities shifted—without reworking the product.
Systems thinking reveals compounding friction
Viewing the product as a connected system—across onboarding, booking, notifications, and physical exchange—revealed how small frictions compounded into user hesitation.
Match design depth to product maturity
Deferring complexity until the product was ready helped focus on traction and learning—while preserving room to scale later.
Future Considerations
As Nearville evolves, the next focus is driving meaningful adoption—supporting real transactions, not just sign-ups. Rather than expanding the product surface area prematurely, the focus remains on observing market response and adjusting the roadmap to strengthen trust and perceived value before introducing additional complexity.