Overview
Role: Product Designer & Team Lead
Type: Map-based community app, 0→1 product design
Core Concept: Starting from maps, helping people rediscover their city and its people
Starting from an Observation
The pandemic made one thing clear: the distance between us and our city is far greater than we thought.
Open your phone, and algorithms feed you global trending topics and distant friends' life fragments. But what happened on your street last night, what events are happening nearby, whether that corner shop is worth visiting — these things never appear in your feed.
The deeper problem: existing social platforms are pushing people further apart. Likes replaced greetings, curated personas create anxiety, algorithms decide who gets seen. We sit at home scrolling 'social' apps, yet know nothing about what's happening next door.
Research: Finding Real Pain Points from Real People
Before any design work, I led the team to do one thing: understand what a user's day looks like.
We used 'office workers' as our core Persona — modeled after a 32-year-old professional who commutes daily, wants lunch companions during breaks, wants to explore nearby spots after work, yet spends too much time maintaining an attention-seeking image on Facebook, Instagram, and Tinder. A clear gap existed between his real needs and the apps he used daily.
Using the Value Proposition Canvas, we analyzed research results across three dimensions: what Jobs to be Done users truly care about, what Pains they face, and what Gains would move them. The process made us realize the problem wasn't just 'can't find nearby information' — more fundamentally: there was no reason motivating people to connect in physical space.
Competitive analysis also confirmed the market gap. Facebook has a complete ecosystem but is losing young users; Instagram is visual-oriented with increasingly commercialized social features; Zenly tried 'social maps' but its core was still tracking friends' real-time locations, not generating public content around urban spaces. No platform organized community content around 'location' as its core.
Core Architecture: Three Elements, One Living Map
After research convergence, we defined Streetchat's information architecture core: People, Map, Posts — where these three overlap is where 'Streetchat' finds its meaning.
This architecture wasn't just a conceptual framework — it directly influenced every design decision:
Posts must be anchored to a location on the map, giving information spatial context. You're not just reading a post — you're seeing what happened 'at this place.'
Three types of posts were designed: Regular Posts (record discoveries), Topic Posts (community discussions on specific topics), Event Posts (organizing offline gatherings, turning virtual connections into real action). Each type aimed to pull community interaction from 'emotional venting outlets' toward 'spaces where real connections happen.'
The Hardest Design Problem: Privacy
For a location-based community, the most intuitive concern is privacy. Posting at a marked location on a map requires a significant foundation of trust.
Our solution was a multi-layer system:
- Explore Map (Public): City exploration between strangers, visible to anyone
- Following Map (Semi-open): Content from friends and followed users, built on mutual relationships
- Group Map (Closed): Private space within a single group, members only
- Private Map (Friends only): Private daily sharing, only friends can see your footprints across the city
When publishing any post, users must choose which layer it appears on. This mechanism gives 'posting on a map' finer control granularity, and makes groups a real container for cultivating vertical communities.
Ecosystem Building: Cold Start Strategy for Social Products
Streetchat's core challenge wasn't just design, but cold start.
No content on the map means no motivation to post; no one posting means the map stays empty forever. This is the chicken-and-egg problem every location-based community must confront head-on.
We deconstructed user motivations from a behavioral science perspective, identifying three levels of drive: Instinctive motivation (curiosity, belonging), Social motivation (attention, identity), Emotional motivation (joy, fun, connection). Feature design must correspond to these motivations to transform users from 'occasional trial' to 'habitual return.'
For ecosystem building strategy, we designed a Hooked Model application framework:
Trigger: New post notifications appear on the map nearby, triggering curiosity; or through event recommendations, letting users know what's happening around them.
Action: Lowering the posting barrier was a key design goal. Topic posts provide quick entry so users can express themselves even without specific ideas; event posts dramatically reduce the organizational cost of offline gatherings.
Variable Reward: Explore map content is different every time; personal map records provide a sense of achievement unlocking progress, keeping return visits fresh.
Investment: Accumulated UGC content, map bookmarks, group establishment — the more users invest, the higher the cost of leaving.
In the early cold-start phase, the strategy was to have the internal team build content density first, ensuring new users don't face an empty map on first open; then through event post mechanisms, create offline events as early community convergence points.
Design Execution
Mockup design started from core flows, focusing on making 'interacting on a map' intuitive and fun:
Opening the app, users aren't greeted by a feed but a city map, where every floating post bubble represents 'someone said something here.' Explore mode is like treasure hunting in the city — you never know what the next tap will reveal, and that uncertainty itself is the attraction.
Personal maps serve as users' own life records — every post is a location marker, accumulating into a private diary of city movement. Group maps let the same group share a common map space, solving the coordination costs of 'finding and waiting for people.'
Chat design extended map interaction: sharing a post link or sending a location are ways to continue the map context within conversations.
What I Learned as Team Lead
Streetchat was my first 0-to-1 product led as Product Team Lead.
From leading the team through Persona interviews, Value Proposition Canvas, competitive analysis, to defining information architecture, designing Mockups, and launching the MVP — this process taught me that the core job of a product leader isn't to propose the best ideas, but to ensure the team discusses the right questions at the right time.
A few memorable decision moments:
When privacy concerns were raised, we could choose to 'simplify architecture, reduce complexity,' or 'address it head-on, design it as a product differentiator.' We chose the latter, and the layer mechanism transformed from a technical issue into one of the product's core concepts.
When discussing cold start strategy, 'complete features first' vs. 'populate the map first' were two fundamentally different prioritization logics. We ultimately decided content density matters more than feature completeness — an empty map can't retain users, no matter how many features it has.
Ultimately, Streetchat didn't continue due to funding. But this experience gave me a complete product leadership perspective — design ability is only part of it. How to make strategic judgments and coordinate at the team level is what truly moves a product forward.
Showcase
