Designing a Cross-Platform Community System for Real Human Connection

Most social products are built to expand.
LOCL was built to contain.

In a digital world optimized for reach, feeds, and algorithmic noise, LOCL took a quieter stance: community works best when it is local, governed, and intentional.

LOCL is a location-constrained community platform, live on mobile app stores, designed for iOS, Android, and responsive web. A browser experience is in progress to reduce “download-first” friction.

I served as the Senior UX/UI Designer from early system definition through ongoing iteration-owning architecture, interaction design, governance UX, and cross-platform parity clarity.

Role

Senior UX/UI Designer (end-to-end)

Focus

System architecture · UX/UI design systems · Discovery and taxonomy · Governance and moderation UX · Privacy and safety patterns · Cross-platform parity · Interaction design

BUILD

Flutter (cross-platform) for iOS, Android, and web

Status

Live on app stores · Browser in progress

CLIENT

LOCL

TIMELINE

Apr 2024 – Present

Context

A calm alternative to the modern feed

Most social products are designed to expand. More reach, more content, more noise. LOCL took a quieter stance. Community works best when it stays local, has clear stewardship, and feels intentional to return to.

We built LOCL as a location constrained community system that supports real participation, not engagement loops. The goal was not to keep people scrolling. The goal was to help people find what matters where they actually live, then give leaders the tools to keep that space healthy.

Intro video: the problem with modern feeds, and LOCL’s local-first answer.

What I owned (high level)

  • Product structure and key navigation patterns, including the split between Discover and Joined

  • Core community surfaces: feed, about, members, affiliates, and posting behaviors

  • Governance and trust flows: roles, join requests, moderation, reporting, and leader tooling

  • Cross-platform behavior clarity: component states and edge cases across iOS, Android, and web

  • Design-to-build artifacts that reduced ambiguity for engineering and prevented drift

Discover · Joined · Community · Governance · Profile · Connections

The core problem

A system-level challenge, not a UI challenge

Community products rarely fail because of UI. They fail when the system breaks under real human behavior.

LOCL had to balance four tensions most platforms avoid:

Signal vs noise

Local relevance disappears when global mechanics dominate attention.

Discovery vs belonging

Browsing and returning are different behaviors. The product had to respect both.

Growth vs governance

Communities grow fast, but they stay healthy only when leadership and moderation scale with them.

Openness vs safety

Removing friction drives growth. The right friction protects trust.

These tensions shaped the system. Everything you see next is a response to them.

Principles as constraints

The rules that kept the product honest

Instead of starting with generic UX patterns, we treated LOCL’s principles like product requirements. Each one is a constraint that narrows decisions and prevents drift. The screens below show how those constraints show up in real surfaces.

Proximity over popularity

Discovery stays local by design. It prioritizes proximity and relevance, not virality.

Discover · Tags · Boundaries · Location

Calm over engagement

Hierarchy and pacing are designed to feel unhurried. You can use it without being pulled.

Home feed · Community feed · Post flow · Direct messages

Guidance over emptiness

Empty states teach behavior instead of apologizing for missing content.

Home empty feed · Joined communities empty · Community empty feed · Messages empty

Governance is part of UX

Leaders, moderators, and reporting are foundational, not a settings afterthought.

Manage hub · Reports · Join requests · Roles + visibility

Parity across platforms

Flutter enabled shared patterns, but not identical behavior. Design respected platform norms while staying consistent.

iOS (Home) · Android (Home) · Android Tablet (Joined) · Desktop Web (Home + Post)

Research & insight

Light, strategic, and rooted in reality.

We started with patterns, not assumptions. We looked at where community platforms break, then designed around those weak spots.

Competitive observation

Across Nextdoor, Facebook Groups, Meetup, and Discord, the same cracks show up:

  • Feeds turn communities into noise

  • Local relevance collapses under global behavior

  • Moderation arrives too late, after trust is already damaged

  • Discovery and onboarding don’t match how people join communities in real life

Human insight

In early conversations with community leaders and active members, the same needs came up:

  • “Who is this for?” must be clear before joining

  • Leaders need control that feels dignified, not punitive

  • Trust is built through clarity: rules, roles, visible leadership, predictable behavior

  • Communities do better when creation is guided, not unlimited

One early community example (Humanity Showers) reinforced the signal:

When people care, they want a space designed with dignity.

Real community example · Feed context · About

System architecture

How LOCL is structured

LOCL is structured around two modes: Discover to explore, Joined to return to your communities, stay updated, and build.

Discover vs Joined Communities

Discover is for exploration. Joined is for commitment.

Two psychological modes: Discover for exploration, Joined for commitment sharing the same core community structure, with mode specific actions

Same community, different state: Discover shows Join Community, Joined opens to Feed

Search, tags, and intentional discovery

LOCL keeps discovery focused and easy to refine.

  • Search is scoped to communities

  • Tags are guided with suggested chips instead of endless categories

  • Discovery stays location-bound

  • Filters preserve context via a sheet/modal instead of page jumps

Scoped discovery: explore communities, then refine with guided tags and filters

Community creation

Creation is structured so communities start with clarity, not confusion:

  • Define the basics: name, headline, about, and domain

  • Anchor it locally: location and visibility

  • Make it findable: guided tags that shape discovery

  • Set stewardship early: leaders and moderators from day one

  • Launch with guardrails: required fields prevent unclear communities

  • Start momentum: invite people immediately after launch

Structured creation: define identity, anchor locally, set visibility, assign stewardship, then invite people to start momentum.

Community as a living space

Communities are designed like rooms, with dedicated spaces for updates, context, people, media, and affiliated communities, with topic channels for focused discussions coming soon.

  • Feed: the shared notice board for updates and conversation

  • About: mission, location, and leadership, visible up front for trust

  • Media: a shared library for photos and videos, not buried in the feed

  • Members: clear roles and participation context, who is here and why

  • Affiliates: partner communities, connection without turning it into a global graph

A community is organized into five dedicated spaces: Feed for updates, About for context, Media as a shared library, Members for people and roles, and Affiliates for related communities.

Profile, identity, and connections

Identity supports belonging. Profiles show context, not performance.

  • Activity: a running log of your posts and shared updates across every community you participate in

  • About: lightweight identity and self expression your bio plus optional links, media, and socials you choose to share

  • Communities: where your joined and created communities live with controls to show them publicly or keep them private

  • Connections: a local first network where connecting is intentional not follower based

Profile as context: activity across communities, curated links, community presence, and intentional local connections

Supporting navigation

These core surfaces work together to help people find what matters, connect intentionally, and stay up to date on the communities they’re part of. Each area is scoped by intent with clear actions and consistent patterns, so the experience stays local, calm, and easy to return to.

  • Search: spans people and communities, locals first with scoped filters

  • Connections: My Connections / Find People, designed for real relationships over follower counts

  • Notifications: grouped by intent (Reactions / Requests / Replies) so actions are quick and obvious

  • Messages: 1:1 and small-group threads with reactions, replies, edits, media, link previews, and sharing

  • Context stays local: location and purpose shape what you see

  • Consistent patterns: tabs, filters, and action buttons behave the same across surfaces

Supporting navigation: search, connections, notifications, and messages

Engineering collaboration

Senior design is buildable design

Flutter enables cross-platform parity, but it raises the bar for precision. Consistency doesn’t come from polished UI, it comes from decisions engineers can implement the same way every time.

I partnered closely with engineering to reduce build risk and speed up delivery by producing build-ready specs, including:

  • Component behavior contracts (rules, reuse patterns, edge cases)

  • State coverage matrices (empty, loading, error, partial, success)

  • Parity guidelines (what must match across platforms vs intentional differences)

  • Interaction specs detailed enough to implement without interpretation

  • UI decisions shaped by constraints (performance, time cost, feasibility)

The intent was technical empathy: not to write code, but to eliminate ambiguity and reduce rework.

Early structure & decision exploration

Minimal wireframes, used correctly

Before high-fidelity UI, I used low-fi wireframes to lock in LOCL’s information architecture, core flows, and edge cases. Below, you’ll see (1) a build-ready lo-fi set that clarifies structure and states, and (2) an organized iteration library where explorations and pivots are archived so decisions stay traceable and patterns can be reused.

  • Align structure early: validate navigation, hierarchy, and flow order before visual polish

  • Reduce build ambiguity: define interaction rules, empty/loading states, and guardrails upfront

  • Move faster with reuse: establish consistent patterns (tabs, lists, sheets, filters) across surfaces

  • Explore broadly, decide deliberately: test multiple approaches, then converge based on clarity and intent

  • Keep decisions traceable: archive explorations in an iteration library so the team can reference prior work without rework

Lo-fi wireframes: 12 curated screens selected from a larger exploration, capturing LOCL’s core MVP flows across discovery, joining, community navigation, posting, governance, creation, and profile, mapped to remove ambiguity and keep implementation buildable.

Iteration library: archived explorations and pivots, organized for traceability and reuse.

Outcomes & signals

Data, used sparingly and honestly

I use metrics to validate design intent, not to decorate the story.

Early traction (first 5 weeks)

In the first five weeks (Apr 4 to May 8, 2025), we saw clear momentum that validated the system direction:

  • Users: +225%

  • Installs: +221%

  • Communities created: +126%

  • Strongest growth came from unlisted and private communities, signaling demand for clearer governance and permissioning from day one

What this changed (a real design takeaway):

The fastest-growing community type was not public. It was unlisted and private. That reinforced an early bet that governance, join requests, and visibility controls are foundational, not “later.”

Snapshot (scaling signal)

As of Jan 8, 2026, LOCL had reached:

  • 2,456 users

  • 509 communities

  • 4,992 community members

  • 3,474 posts

  • 680 cities

  • 53 countries

This matters because it is not just adoption, it is distribution. Even at MVP stage with a small team, the system had to stay coherent across cities, community types, and increasing levels of governance complexity.

Reflection

What this taught me

Designing LOCL reinforced something I already suspected:

What this taught me

Community is not software, it is people. People need clarity to join. Safety to stay. Leadership to scale. And they need a product that does not hijack attention just to prove it is working.

LOCL is still early, with no marketing push yet. That has been a useful constraint. It forced the product to earn repeat use through structure, not hype, and validated that local-first systems can grow through real participation instead of endless browsing.

In a world chasing virality, LOCL is a chance to design for something slower and more meaningful: infrastructure that helps humans show up for each other, without noise.

As LOCL evolves, the next investments stay focused on:

  • Leader tooling that reduces platform risk and strengthens trust

  • Discovery systems that stay local-first without collapsing into directories

  • Events as a core surface for local communities to coordinate and build momentum

  • Community channels to support focused discussions beyond a single feed

  • A donation system to support individual communities and partner NGOs directly in the app

  • Cross-platform parity that preserves intent as the system scales

The goal is not to grow a feed.
It is to grow a place.

EXPERIENCE THE PRODUCT

The writeup is still in progress, but LOCL is live. Visit locl.com for an overview, then download the app to see the full flow in context.

Check Next

SACKCLOTH & ASHES
A purpose-driven e-commerce platform redesigned for clarity and ease, with UX, UI, and front-end development aligned to the mission.

CLEAR SMILES ORTHODONTICS
A clean, responsive site built for a modern orthodontic practice. Full UX, interface design, and front-end to support trust and precision.