Gather — Native iOS Product & Visual Design

01 / THE OPPORTUNITY

Making a plan shouldn’t be the hard part.

A group chat is great for conversation. It’s a difficult place to keep track of a decision. Gather brings interests, practical constraints, and private choices into one focused journey.

The premise: Ideas, timing, and budgets become scattered. Unspoken requirements can be missed, while more suggestions do not necessarily create agreement.
The design response: A shared lobby, requirement-aware recommendations, private voting, aggregate consensus, and a final actionable plan.
Contribution: De’Andre Perry supplied the product brief and directed the project. Codex assisted with initial implementation, procedural artwork, sample content, testing, and case-study production.

Independent concept developed from a product brief. These premises are hypotheses, not interview findings. Venues, people, votes, and accessibility metadata are sample data; this is not an App Store release or Apple-affiliated project.

02 / THE EXPERIENCE

One continuous path to a shared plan.

Home establishes the next step. The lobby brings the group together. Voting makes room for an honest preference; consensus turns the aggregate result into a plan.

See the aggregate result after all ballots are complete.

Original, unretouched Simulator captures. Select a screen to enlarge it. The group-match score reflects shared preferences in the demo. It does not verify a venue’s accessibility or suitability.

03 / DESIGN REASONING

Small choices. Meaningful differences.

01 / DECISION

Give the group one next step.

Home prioritizes the active plan; Start Voting appears before recommendations in the lobby. Browsing remains available without becoming a prerequisite.

Trade-off: Less content up front, more direction.

02 / DECISION

Make room for an honest pass.

Love, Good, and Pass express different levels of interest. Individual choices remain private, with aggregate results withheld until all ballots are complete.

Trade-off: The group waits for everyone before seeing the result.

03 / DECISION

A must-have isn’t a nice-to-have.

Preferences affect ranking; requirements determine eligibility. Missing required accessibility information excludes an option rather than assuming suitability.

Trade-off: A smaller set of ideas may be the appropriate answer.

04 / VISUAL LANGUAGE

Warm in character. Clear in purpose.

Forest-green actions anchor a warm illustrated identity. Familiar iOS controls provide structure, while conversational copy gives the app its voice.

Forest

#1F5C4D

Apricot

#F5975E

Midnight

#262E4D

Cream

#FADEA6

Typography: Semantic iOS text styles establish hierarchy and adapt to Dynamic Type. The portfolio retains its own Plus Jakarta Sans typography.
Rhythm: 24-point page gutters and a 12, 16, 24, 32 spacing rhythm group content with whitespace instead of extra borders.
Appearance: System surfaces and labels adapt to appearance. The separate dark accent is pale green (#94D1AD); warm illustration colors remain expressive.

Home in dark appearance with Increase Contrast enabled.

05 / DUO DESIGN EXPLORATION

More room. Same plan.

An interactive layout study explores compact, expanded, and fold-aware arrangements while keeping the selected plan consistent.

Compact: A focused plan view with a clear route back to the plan list.
Expanded: The list and selected plan sit together when space allows and stack on narrow previews. More context appears without adding tasks or exposing private votes.
Fold-aware: A schematic separation explores how content could adapt across a larger canvas.

This is a web proposal, not a native Duo implementation or device capture. Dimensions, transitions, and assistive-technology behavior still need native validation.

Try the interactive Duo exploration

06 / INCLUSION

Consideration is part of the interface.

Requirements inform the eligible options without appearing in participant summaries or shared invitations. Voting uses words and symbols together, exposes selected values to assistive technology, and excludes decorative artwork from the reading order.

Semantic text can grow. Voting responses stack at accessibility sizes, primary labels receive the full available width, and reduced-motion settings disable voting transitions. Native tabs, navigation stacks, and a dismissible voting sheet retain familiar interaction patterns.

Final plan at the largest accessibility text size on the smaller iPhone 17e Simulator.

VoiceOver, Switch Control, Reduce Transparency, landscape, permissions, and physical-device behavior still require manual validation. This is an implementation review, not an accessibility certification.

07 / REFINEMENT & QA

The polish is in the follow-through.

Running the app exposed details beyond static compositions. The supplied QA record documents these refinements.

Secondary text was too quiet.: Strengthened secondary-text contrast following the native accessibility audit.
The action came after browsing.: Moved Start Voting above the recommendation list.
Large labels needed more room.: Removed competing icons from primary buttons at accessibility text sizes.
Confirmation inherited scroll position.: Returned the plan to its heading when its state changed.

Unit tests passed: 12
UI tests passed: 4
Smaller-device journey runs: 2

Reported in the supplied QA record, September 15, 2026. These are implementation checks, not usability or impact metrics. The native audit excludes contrast findings for elements overlapping the translucent tab bar, which received separate visual review.

Download the QA record ↓

08 / OUTCOME & REFLECTION

A working idea. A clear next chapter.

The functional native concept connects private choices, group consensus, and final-plan actions. Its core journey runs offline using sample participants and venues.

Creation, discovery, preferences, saved activities, and final-plan actions extend beyond the central walkthrough. Live collaboration, real venue providers, reservations, widgets, and Live Activities remain future work.

What I would test next

Do people understand the difference between a preference and a requirement?
Does private voting help people express a real preference?
Can organizers recover confidently from a tie or an all-pass round?