Rele: Designing the User Journey
Turning a broad social platform concept into 20 connected user flows.
Turning a broad social platform concept into 20 connected user flows.
Project: Rele mobile app
Focus: User flows, interaction planning, and MVP scope
Tools: Figma
Stage: v0.2 planning and prototype exploration
Focus: User flows, interaction planning, and MVP scope
Tools: Figma
Stage: v0.2 planning and prototype exploration
About the project
Rele is a social platform built around casual sharing and real-world connection. It brings together friends, communities, creators, and small businesses, with the goal of helping people discover places and relationships beyond their screens.
The product combines several experiences: sharing content, joining communities, shopping locally, messaging, and creating. Before those features could become a cohesive app, I needed to clarify how people would move between them.
My role
I defined the product requirements and directed the development of 20 core user flows for the mobile experience. I outlined the actions people should be able to take, the choices they would encounter, and the situations the design needed to accommodate.
My focus was connecting Rele’s larger vision to specific interactions from signing in and customizing a profile to joining a community or completing a purchase. The resulting flow diagrams and screen references provided a starting point for design review and engineering discussions.
The challenge
Rele’s breadth created a central challenge: making its features feel connected without overwhelming people.
A single action, such as sharing a photo, raised several questions. Was the post public, private, or intended for a community? Could other people comment or share it? Would publishing to another platform change who could see it? The flows also needed to address situations beyond a successful interaction. Someone might forget their login information, wait for community approval, or encounter an unresolved payment. Those moments needed clear next steps.
How I approached it
I organized the requirements around what people were trying to accomplish. Instead of treating every feature as an isolated destination, I mapped journeys with an entry point, decision points, and an outcome.
I grouped related options within 20 core flows to make the scope easier to review. Each flow received a consistent identifier so the team could connect the journey to its corresponding screens and behavior notes.
I also distinguished core MVP needs from later capabilities. This helped make dependencies visible and supported conversations about what needed to be built first.
Making privacy part of the journey
Privacy became a decision within the experience rather than something people would have to discover afterward in settings.
In the publishing flow, I specified an audience choice before the final review. The flow also separates who can see a post from whether people can like, comment on, or share it.
Optional sharing to external platforms was treated as a separate, explicit choice. Restricted posts should not become public simply because someone connected another account.
Designing for different community experiences
Joining a community is not always an immediate action. A free, open community can allow someone to enter directly, while a private community may require approval. I mapped those differences so that requesting access, waiting for approval, and becoming a member were distinct states. Paid membership introduced another dependency: access should follow confirmed payment.
This made the relationship between community rules, membership status, and access easier to discuss before implementation.
Accounting for uncertainty
I included recovery and pending states alongside the main paths.
For the sign in screen, that meant providing routes for forgotten credentials and password recovery. For marketplace checkout, it meant distinguishing a confirmed order from a pending or failed payment. These branches helped clarify what the app should communicate when an action could not finish immediately, including when someone should wait and when they could retry.
Accessibility considerations
I treated accessibility as part of the interaction structure. Swipe navigation needed an alternative through visible tabs, controls needed clear labels, and status changes needed explanations beyond color alone. The accompanying screen specifications also called for readable contrast, scalable text, and sufficiently large touch targets. These were design requirements for implementation and testing, rather than a claim that the prototype had already passed an accessibility audit.
The outcome
The v0.2 work established 20 core user flows with branching options and corresponding screen references. Together, they made the proposed experience more concrete and highlighted dependencies across authentication, privacy, community membership, publishing, and payments. The outcome at this stage was a design and planning foundation. Usability testing and implementation would be needed to determine how well the journeys work in practice.
What I learned
This project reinforced how many decisions sit behind an apparently simple interaction. A “Join” button depends on membership rules, while a “Post” button depends on audience choices and sharing permissions. Mapping those decisions helped me examine the experience more carefully and identify where the product needed a clearer rule or a more understandable next step.
