Find a relevant community
Potential friction. A dense feed or unfamiliar navigation can hide Spaces.
Design response. Keep social shortcuts near the feed and provide a dedicated discovery view.
MOBILE EXPERIENCE · DESIGN SYSTEMS
Carrot
From discovery to belonging.
I designed Carrot’s home, login, card/post creation, profiles, and settings—key parts of the member experience.
My contribution is shown alongside related Spaces and membership flows to explain the wider community journey.
01 /
A community needs more than a feed.
The problem
Members need to find a relevant community, understand its access rules, and know what happens after they ask to join.
The product opportunity
Connect discovery to clear membership states and give owners the controls to manage access.
Why it matters to the business
The business hypothesis is that relevant discovery and understandable membership states support participation. Owner controls support community operations. The artifacts demonstrate the proposed experience; retention, moderation efficiency, and growth have not been measured here.
MY CONTRIBUTION
Product designer · Member experience
How to read the shared product work
This case places my screens within the wider community journey. Spaces and membership flows provide related product context; I do not attribute the entire shared Figma file to my individual work.
Scope & source context
I owned home, login, card/post creation, profiles, and settings. The shared-file exports also include Spaces and membership flows for product context. Sample content is preserved from the source. The file records a verification revision; its precise implementation constraint and release status are not documented.
02 /
Start with the person and the task.
Task model synthesized from member-home and Spaces artifacts. User needs are hypotheses; completed interview evidence is not available.
| Who the experience serves | What they need |
|---|---|
| Exploring member | Find relevant people and Spaces without learning the full product model. |
| Prospective Space member | Understand public access, approval requirements, and the status of a join request. |
| Space owner | Set privacy and membership rules, then review requests in a dedicated workflow. |
Explore the task model and potential friction
Discover, evaluate, participate.
Understand the place and the next commitment
Potential friction. A private Space can look accessible even when approval is required.
Design response. Show context, a privacy label, and a membership-specific action.
Understand membership status and owner decisions
Potential friction. A request can feel lost while waiting for approval.
Design response. Persist Request Sent and give owners a separate review surface.
03 /
Connect discovery to the access model.
A member finds a Space, examines its context, and chooses the appropriate membership action. Owners manage the approval side of private access.
Discovery & Space access model
Verification state diagram
Reusable pattern map
Design for the exception, too.
Request sent is a distinct state
A pending private request replaces the primary action. It should not be confused with accepted membership or a failed action.
Verification still needs recovery
The guest flow preserves completion, expiry, and error states. The accompanying diagram is reconstructed from those authored states.
Maps synthesize the authored screens and labels. They describe the design model, not verified production transitions.
04 /
Follow the experience, screen by screen.
Explore the key screens, interaction states, and decisions behind them.
01
From the member feed to a relevant Space
Two levels of navigation
The compact social bar preserves room for the feed. Its expanded view supports returning to familiar Spaces and looking for another community.
State travels with the result
Search results distinguish an invitation, a public join action, a private request, a pending request, and existing membership. Names, counts, and copy are source placeholders.
02
Make the membership decision explicit
Context before commitment
The About surface presents a description, interests, rules, and flags. These help someone assess a community before acting.
Visibility and membership differ
Public and private designs change both the privacy label and primary action. This comparison shows authored states; the connecting runtime behavior has not been tested.
03
Connect member expectations to owner controls
A different job for the owner
Privacy settings define the access policy. Join Requests gives the owner a place to act on the demand created by private membership requests.
The next validation question
Can owners predict the consequences of changing privacy, and can applicants tell whether they are still waiting? Those are task questions for testing, not results inferred from screens.
Supporting design / Two starting intentions, two clear actions
04
Two starting intentions, two clear actions
A primary entry action
Account creation uses the stronger filled treatment.
Returning users have a route
Log in remains a separate, visible alternative.
Supporting design / Permission and capture belong to the same task
05
Permission and capture belong to the same task
Reason before access
The permission screen ties camera access to the immediate verification task.
Instruction at capture
The expression guidance stays visible beside the live-image area and capture action.
Supporting design / Initial, completed, and expired
06
Initial, completed, and expired
A consistent container
The bottom sheet keeps the challenge in the context of the guest flow.
An actionable interruption
Expiry includes a concrete retry instruction instead of leaving the person to infer the next step.
Supporting design / One visual vocabulary across many states
07
One visual vocabulary across many states
Consistency across state types
Shared color and illustration treatment connect distinct product moments.
Words carry the instruction
Accessible state text must work even when the illustration cannot be perceived.
05 /
The choices behind the experience.
Design evidence, the reasoning it supports, and the tradeoffs that remain.
DOCUMENTED ITERATION / ORIGINAL FIGMA EXPORTS
A real constraint changed the verification surface.
01 / Earlier direction
02 / Approved revision
What the evidence shows
The earlier sheet uses a customized dark verification widget and a separate Continue button. The approved revision uses a standard light widget and removes that separate button while retaining the surrounding explanation.
The design tradeoff
The revision gives up some visual uniformity. It preserves the product context around the verification step and keeps progressing, completed, expired, and error states in the approved set.
The source labels the earlier section “can’t be developed” and the later section “Approved.” The exact implementation constraint and the reason for each visual change are not recorded.
01 / Keep discovery close to the member feed.
In the design. Member home includes a horizontal social bar. Its expanded Spaces view has pinned items, invitations, search, and filters; search distinguishes People from Spaces.
The rationale
Frequently visited communities and broader discovery serve different intentions. A compact entry point preserves room for content while the expanded view supports deliberate exploration.
The tradeoff
Pins and status badges can become visually dense. Their meaning and discoverability need task testing with first-time and returning members.
02 / Distinguish joining from requesting access.
In the design. A public Space shows Join. A private Space shows Request to Join, followed by a separate Request Sent state. Search results also carry these membership states.
The rationale
The action label sets an expectation about whether participation is immediate or needs another person’s decision. Persistent pending status helps explain why access has not changed yet.
The tradeoff
Public visibility, membership, prerequisites, and paid access are separate concepts in the file. Their combinations need an explicit permission model so one label does not promise too much.
03 / Give owners a separate control surface.
In the design. Privacy distinguishes a public Space from one accessible only to approved users. Join Requests offers separate approval and decline actions. The wider owner design includes roles, members, rules, and prerequisites.
The rationale
A member decides whether to join; an owner decides who can enter and how the community operates. Separate surfaces let each workflow expose the controls it needs.
The tradeoff
Changing privacy has consequences for existing members and content. Confirmation, authorization, and the resulting access behavior need implementation agreement.
04 / Design the recovery states with the main flow.
In the design. The file contains CAPTCHA initial, progressing, completed, expired, and error states. An expired state tells the user to check the checkbox again.
The rationale
A verification step should not become a dead end simply because it times out. Recovery copy is part of the task model: it tells the person what changed and how to proceed.
The tradeoff
The approved set preserves completion, expiry, and error states even though the verification surface changes. Maintaining brand consistency must leave room for implementation constraints.
Alternative directions & constraints
Retrospective option analysis; these are tradeoffs for review, not claims that every option was tested.
Put every requirement into one long form
Value. Makes the complete set of requirements visible immediately.
Tradeoff. Combines unrelated decisions and makes errors harder to isolate.
Present isolated verification screens
Value. Lets each technical step be implemented independently.
Tradeoff. Can fragment the visual language and leave users unsure of their progress.
Use a guided flow with reusable state patterns
Value. Connects entry, permission, verification, and recovery in one consistent experience.
Tradeoff. Requires state mapping, engineering alignment, and careful content governance.
What the design has to respect
- Camera and verification requirements must match the actual authentication architecture.
- Implementation feasibility affected at least one documented design direction.
- Brand naming and content must remain consistent throughout guest and logged-in states.
- The illustrated state system must retain readable instructions and nonvisual equivalents.
06 /
Track where trust and progress break down.
Test the member and owner sides together: discovery, understanding access, recognizing a pending request, and applying a privacy policy. Separate observed task success from an inferred engagement benefit. Verification recovery remains a supporting task.
Put the design under pressure
Proposed task-based scenarios for validation.
| Scenario | What to observe | How the result informs design |
|---|---|---|
| Find a relevant Space from member home. | Can the participant discover the social bar and explain the search results? | Clarify the entry point or simplify overlapping discovery controls if they cannot. |
| Request access to a private Space and explain what happens next. | Whether Request Sent is understood as pending approval. | Strengthen status and notification expectations before adding more engagement features. |
| Review a join request and explain public versus private access. | Whether the owner predicts who can access content after each decision. | Clarify privacy consequences and confirmations before implementation. |
| Recover from an expired verification challenge. | Whether the retry instruction restores progress without restarting. | Resolve recovery barriers before optimizing successful-path speed. |
Measurement definitions & study plan
Discovery completion
Participants who find a relevant Space without assistance ÷ participants attempting the task.
Tests whether the feed, social bar, and search provide an understandable route.
Membership comprehension
Participants who correctly explain public, pending, and joined states ÷ participants shown each state.
Checks expectations before interpreting a click as successful participation.
Owner decision accuracy
Participants who correctly predict access after approval or a privacy change ÷ participants attempting the scenario.
Tests the permission model rather than visual preference.
A practical path to validation
- Agree the public/private membership and access model with engineering.
- Run member discovery and private-request tasks, including a pending state.
- Ask owners to approve a request and explain privacy consequences.
- Test verification expiry and denied permissions; instrument actual usage only after release.
07 /
Detailed state design, supported by original artifacts.
The original files connect member discovery, public and private Spaces, owner controls, and onboarding recovery. They also preserve a documented verification revision. Together these show design depth across member and owner roles; release status and engagement outcomes remain unverified.
A community interface has to explain both a place and a relationship: what this Space is, whether I belong to it, and what I can do next.
Next product decisions
Project sources & context
I owned home, login, card/post creation, profiles, and settings. The shared-file exports also include Spaces and membership flows for product context. Sample content is preserved from the source. The file records a verification revision; its precise implementation constraint and release status are not documented.