Project: Community Events Platform Version: v1 Date: March 15, 2026 Previous summary version: No
We are designing a community events platform for a mid-sized city (population roughly 200,000). The platform helps local organizations post events and helps residents discover things to do. It is not a ticketing platform. The core value proposition is curation and discoverability, not transactions.
The project is currently in the planning and design phase. No code has been written. We have completed the core concept, user research synthesis, feature prioritization, and initial information architecture. The next phase is wireframing the three primary screens.
Event Organizer: Any local organization, business, or community group that creates and posts events to the platform. Organizers are verified through a lightweight application process (not self-service registration). We chose verification to maintain quality, even though it creates friction.
Explorer: A resident who uses the platform to discover and browse events. Explorers do not need an account to browse. Account creation is only required to save events, follow organizers, or set notification preferences.
Curation Score: An internal ranking signal (not visible to users) that determines event placement in browse and search results. The score is based on three factors weighted equally: organizer verification tier, event completeness (how many optional fields are filled), and community engagement (saves and shares). We explicitly rejected using paid promotion as a curation factor.
Neighborhood Zone: A geographic grouping used for filtering and discovery. The city is divided into 12 zones based on existing neighborhood boundaries, not zip codes. We chose neighborhood boundaries because they align with how residents actually think about location. The zone list was finalized in our conversation and should not be changed without a full review.
Quiet Hours: The platform does not send push notifications between 9:00 PM and 8:00 AM local time regardless of user settings. This is a hard constraint, not a default that users can override.
Must-have / Should-have / Could-have: [reconstructed] The prioritization framework used during feature planning. Must-haves are required for launch, should-haves are important but deferrable, could-haves are desirable but not committed. The specific feature assignments were completed but are documented in the feature prioritization artifact, not repeated here.
Residents first. Every design decision prioritizes the experience of Explorers over the convenience of Organizers. When these conflict, the Explorer experience wins. This principle was established early in the conversation as the foundational design stance after reviewing user research showing that most competing platforms are organizer-centric.
No dark patterns. The platform will not use urgency cues ("only 3 spots left"), artificial scarcity, or manipulative notification strategies to drive engagement. Reasoning: these tactics optimize for clicks at the expense of trust, which directly conflicts with the curation-first positioning.
Accessibility as a requirement, not a feature. All screens must meet WCAG 2.1 AA as a minimum. This is not negotiable and applies from the first wireframe, not as a later audit.
Bilingual from day one. All user-facing content must support both English and Spanish. This includes event descriptions (provided by organizers with a translation assistance tool) and all platform UI. This constraint was set based on city demographics and affects every screen design.
Lightweight by default. The platform should load and function well on a 3G connection and a five-year-old phone. This rules out heavy JavaScript frameworks, auto-playing video, and large image assets without lazy loading. This constraint was established after reviewing the user research finding that a significant portion of the target audience accesses the internet primarily via older mobile devices.
Decision: No ticketing or payment processing. We will link out to external ticketing platforms when events require tickets rather than building our own. Reasoning: ticketing introduces significant regulatory, security, and support complexity that would delay launch by months. The platform's value is discovery, not transactions. Rejected alternative: building a simple "RSVP only" system. We rejected this because even a free RSVP system creates user data obligations and support burden we're not ready to handle in v1.
Decision: Organizer verification is manual, not automated. New organizers submit a short application that a platform moderator reviews within 48 hours. Reasoning: automated verification (such as matching against a business registry) would miss community groups, informal collectives, and new organizations. Manual review also lets us catch spam and bad actors early. Rejected alternative: open self-service registration with post-hoc moderation. Rejected because it would allow low-quality or spam events to appear before being caught.