Design Highlights
- Information Architecture: reduced the public site to four categories so residents find time, place, notices, and contact quickly
- Public / Internal Split: kept booth, finance, and RSVP data in an internal dashboard instead of exposing operational detail
- Progressive Disclosure: used a single brand stage with modals, so details never require leaving the homepage
Positioning
A local event system, not just a landing page
This is a self-initiated concept project. I set the scenario myself — a village holding its first community second-hand market — and designed the digital side of it: a public website that helps residents understand the event quickly, and an internal dashboard where organizers track preparation. Within that concept I handled the information architecture, the public site design, the frontend implementation, and the contact flow. There was no client and no real event; the point is the system thinking, not an event outcome.
Problem & Goal
Make the event trustworthy and easy to scan, without exposing unfinished operations
Residents only need time, place, admission, rain plans, and a contact channel. Organizers also need booth, finance, RSVP, and risk tracking — details that should not sit on a public page. The goal was a memorable first screen with details that stay easy to find, and public content that stays stable even while preparation data keeps changing.
Key Decisions
Separate public understanding from internal decision-making
- Reduced public navigation to four categories — About, Event Info, Notices, and Contact — so residents are not distracted by preparation detail.
- Used modal-based progressive disclosure so residents can read full details without leaving the branded event stage.
- Moved booth progress, finance, RSVP, and risk reminders into an internal dashboard, keeping the public site stable.
Key Screens
A public website built around fast event comprehension
These screens show how brand impression, event details, notices, and the contact flow are separated into clear entry points for residents.
Operations Tooling
An internal dashboard for preparation decisions
The dashboard stays outside the public deployment and summarizes booth progress, finance, RSVP status, and risk reminders, giving organizers a compact view of what needs action.
- Used KPI cards, progress donuts, and action reminders to make preparation status scannable.
- Showed aggregate status first, so raw guest lists never need to be exposed.
Contact Flow
Turning uncertain questions into a trackable path
Rather than listing a phone number and hoping for the best, the public site routes questions into a form the organizer can actually follow up on.
These are the checks I ran against my own design, not results from a real event: whether the public site explains the event quickly, whether internal operations stay off the public page, and whether an organizer could keep maintaining the preparation data.
- 4 categories
- Public information architecture
- 24 booths
- Planned capacity set in the concept scenario
- 1 dashboard
- Internal operations view
Reflection
Next iteration should connect post-event data and maintenance
The current version covers pre-event communication and preparation. If the concept were actually run, the next step would be attendance estimates, organizer feedback, and a reusable content checklist for future community events.
- Test the assumptions with real residents and organizers, then compare them against actual attendance, booth flow, and inquiry patterns.
- Turn the site and dashboard into reusable templates for future village events.