Lake Eola Park Live Hub

Project background

Lake Eola Park is the cultural heart of Downtown Orlando — a central public space hosting weekly markets, performances, and daily recreational use. Yet its digital presence is restricted to a text-heavy sub-page within the orlando.gov directory, and event information is fragmented across multiple city pages and third-party platforms, making it difficult to access timely, relevant information on mobile.

See the current orlando.gov Lake Eola Park page ↗

Market opportunity: by centralizing fragmented data from park-sanctioned events and local businesses, this platform reduces “information labor” for over 100,000 monthly visitors. Why this brief: it targets a genuine void in civic UX and urban utility, where responsive design and information architecture can meaningfully improve community interaction with a public space — drawing on a professional background in architecture and human-centered systems.

The design problem

Lake Eola lacks a dedicated, mobile-optimized platform for real-time event discovery and visit planning. Users must manually search across multiple sources to answer simple questions: what’s happening right now or this weekend, where should I go and what can I do, how do I plan my visit quickly, and where do I park. This creates friction, decision fatigue, and limits accessibility and spontaneous engagement.

Focus areas

Understanding the visit

Competitive analysis

A review of major urban park platforms surfaced consistent strategic opportunities rather than a single feature gap:

• Minimized information labor — micro-chunking replaces long-form text with actionable event cards for immediate decisions.
• Real-time live context — a dedicated “Happening Now” feed addresses the lack of live updates on standard park sites.
• Reduced cognitive load — a task-oriented UI targets high-friction activities like parking and amenity discovery.
• Simplified spatial utility — select-to-path navigation gives spatial orientation without real-time GPS complexity.
• Dedicated platform identity — a standalone hub instead of a buried municipal directory page.
• Enhanced mapping interaction — hi-fi bottom sheets for map pins identify restrooms and food without leaving the map.

User interviews

5 participants, moderated and remote — urban residents who regularly visit local city parks and/or rely on digital schedules for events. Interviews covered discovery & filtering, planning friction, on-site spatial navigation, and information value.

Research synthesis

View full affinity map ↗

Event discovery & filtering

Park websites fail to surface relevant, real-time events; third-party platforms fill the gap.

Visit planning & friction

Parking logistics, safety vetting, and fragmented critical details drive the go/no-go decision.

On-site navigation

GPS orientation is confusing while walking; people want low-effort, landmark-based guidance instead.

Who this is for

Maya Chen, 29

The Experience-Driven Explorer

Dog owner, car-light — relies on transit, biking, and walking; discovers events through social platforms and physical signage since official sites feel text-heavy and lack real-time context.

“I hate this website. There's nothing here about events really.”

• Pain points
  • Can't tell what's happening today without reading a wall of text, so she checks Instagram instead.
  • Has no sense of cost or crowd level until she's already committed to the trip out.
• Goal: discover something spontaneous, worth leaving the house for, in under a minute of browsing.
• Needs: immediately visible cost & time on event cards, a clear “Happening Now” distinction, and combined category/amenity filters.

Alina Hussain, 37

The Group-Oriented Planner

Car-dependent, plans for a group — the logistical anchor for family and friends, often coordinating a toddler or elderly parents; a park visit is a planned outing, not a drop-in.

“If something big is happening and I know it'll be overcrowded, I won't even go.”

• Pain points
  • One missing detail — parking, restroom access, accessibility — can cancel the whole outing once everyone's already in the car.
  • Dreads arriving to an overcrowded park with a toddler and no backup plan.
• Goal: confirm logistics once, upfront, so the day doesn't fall apart on-site.
• Needs: centralized logistics (parking, access, amenities) visible upfront, confirmed restroom/accessibility info, and a simplified static A-to-B route rather than live GPS.

Framing the problem

1. Fragmented event discovery — park visitors struggle to discover timely, relevant events because information is scattered across official sites, social media, third-party platforms, and physical signage, making spontaneous participation difficult.
2. High-friction visit planning — new visitors face high cognitive load because logistics (parking, amenities, accessibility, crowd level, weather) are hard to find or scattered, and even one missing detail can cancel a family outing.

Project goals

Feature roadmap

Prioritized MoSCoW roadmap, translating the goals above into what actually made it into scope:

Sitemap

User flow

The flow maps three task paths rather than one happy path, because the research showed visitors arrive with different questions:

• Discover & decide — land on Home → scan the “Happening Now” feed → filter Events by free and by date → open an event → read cost, end time and parking on the same screen → decide to go. This is the path a visitor takes when they have an evening free and no plan.
• Plan a visit — open a recurring event (Sunday Farmers Market) → check hours and accessibility → jump to the Park Map for parking and entrances → back to the event with the logistics resolved. This is the path a family takes the night before.
• Navigate on site — from an event page → Park Map → filter to a single amenity → confirm it’s open → select a landmark to route from. This is the path someone takes standing in the park with one hand on their phone.

Each path shares the same three anchors — Home, Events, Park Map — so the map is never a dead end and every event stays one tap from its logistics. These are the same three flows carried forward into usability testing.

From sketches to testable flow

Lo-fi sketches

The static, select-a-landmark A-to-B route first took shape here in the lo-fi and mid-fi sketches, and felt like a genuinely novel idea at the time — a way to give spatial orientation without the complexity of live GPS. It carried through to the Version 1 build, but usability testing later told a different story (see Key design decisions).

Mid-fidelity wireframes

1. Home — Park conditions strip, Happening Now, and upcoming events

2. Events, default — browsing all upcoming events

3. Events, filtered — This Weekend + Free applied

4. Event detail sheet — opens as a bottom sheet, keeping list context

5. Park map, default — landmark directory and Find Route

6. Park map, route fields — route inputs and parking tied to a selected event

7. Park map, active route — a set route with along-the-way amenities listed

Home, events (default & filtered), event detail sheet, and park map (default, route fields, and an active route).

What the mid-fi sketches were testing

Mid-fi usability testing

Moderated remote testing across three task flows: finding a free event this weekend, planning a family visit to the Sunday Farmers Market, and on-site navigation to find a restroom from the park entrance.

Signal to address next iteration:

• Multiple participants paused and looked for a “you are here” indicator on the static map before proceeding — strong enough to warrant a default location pin even without live GPS.
• The event bottom sheet could only show a snippet of event details — great for visibility, but it obscured important information (e.g. road closures) that exists on the current government site. Mobile screens are also meant to be responsive on desktop, so for both information discovery and responsiveness the decision was made to move to full pages instead of bottom sheets.

High-fidelity screens — Version 1

Visual system

Orlando Blue (derived from the City of Orlando's own brand) anchors navigation, headers, and trust; Jungle Green — pulled from the park's fountain and lawns — is reserved for calls to action; Bright Amber adds warmth for tags and attention-getting moments, used sparingly after failing WCAG contrast as a primary color. Barlow Condensed carries display headers; Inter carries body copy, each with its own mobile/tablet/desktop type scale.

Translating the current webpage into a live hub

The City's existing Lake Eola Park page is a single long, mostly-static scroll. The redesign keeps its information but restructures it around what a visitor actually does on-site: check what's happening now, then plan.

Events & park map, in full

1. Default view — landmarks & parking pins on the map

2. Filters — toggle amenities & categories

3. Restrooms filter applied — only matching pins remain

4. Tapped pin — status & hours for that restroom

Default view, the filters modal, a Restrooms filter applied, and a tapped pin's status card — the same route-finder pattern as the mobile flow above.

Desktop & A/B testing

What we tried to change — the current orlando.gov page is a single long, mostly-static scroll with no live event or parking data, all delivered as generic municipal copy. For the desktop redesign, the goal was the same dashboard-first restructuring used on mobile, translated to the wider canvas: surface what’s happening now, then make planning (parking, transit, accessibility) easy to find, instead of burying it in a wall of text.

Critical decision point: Layout Variant A (Bento Box format) won by a clear 4-to-1 margin in testing and became the core desktop homepage foundation.

Key design decisions

• Bento Box layout adopted — Variant A won 4-to-1 in testing and became the desktop foundation.
• Wider text-column padding — added for more comfortable reading at desktop width.
• Hover pop-up data preview cards — surfaced on hover, where a tap target isn't needed.
• Persistent map legend — kept visible on the map rather than tucked behind a toggle.

Iteration

Usability testing on the Version 1 screens surfaced real friction — some of it in the interaction patterns, some of it in the amount of iconography and unfamiliar features. Rather than restating every screen again wholesale, each frame below carries a marked snippet of its Version 1 counterpart so the “before” is visible right next to the “after,” in the same order as the sections above: homepage, events list, event detail, park map.

Homepage

Events list

Event details

Park map

Desktop, final screens

The same iteration pass carried through to desktop, where the wider canvas allowed the parking and transit accordions to sit side by side rather than stacked.

• Happening Now promoted — surfaces above the conditions grid, same as the mobile update.
• Live status tiles added — Swan Boats, weather, and crowd level became first-class dashboard cards.
• Popular Activities added — a scrolling strip of top attractions right on the homepage.
• Know Before You Go, expanded panels — Park Information, Parking Today, and Park Map open as detailed accordions instead of a single generic block.

Key design decisions

Ordered by priority — the fix that mattered most in testing, first.

• 1. Getting Around accordion, replacing “Find Route” entirely — the highest-priority fix this round. Version 1's static routing tool still read as a GPS promise it couldn't keep; it was dropped and rebuilt as a plain-language accordion of walking directions between landmarks.
• 2. Filter chips, flattened again — a second simplification pass after testers still hesitated on the Version 1 chip layout, down to a single, flat, scannable row.
• 3. Parking & transit, split into two accordions — separated so a driver and a transit rider can each find their own information without reading past the other's.
• 4. Dashboard cards, promoted to the homepage — live status (Swan Boats, weather, crowd level) moved from buried in accordions to first-class cards at the top of the page.
• 5. Parking data, curated per page context — grounded in the same underlying research used for the Version 1 civic details (real LYMMO schedules, real vendor counts), but the presentation is deliberately tailored to what each page is for — a quick status glance on the homepage, fuller detail on an event page, spatial context on the map — rather than repeating identical copy everywhere.

High-fidelity usability testing

Results

Feeding into iteration

The friction points above became the concrete next-iteration list: make map amenity icons read as tappable rather than flat/decorative, drop the static A-to-B route feature since most participants misread it as GPS-based location tracking rather than a landmark-to-landmark sketch, and strengthen date-tag visibility on event cards so the calendar-entry steps need fewer corrections.

Validation

Beyond the task-based usability tests above, a persona-mapped mockup was paired with the interactive prototype to check something more specific: does the finished design actually serve what Maya and Alina each came here for?

Maya — discovery

The homepage's Happening Now banner and filterable Upcoming Events list let Maya find something spontaneous to do in well under a minute of browsing, with the visuals (hero carousel, event photography) doing most of the persuading — exactly the kind of scan-and-go discovery she needs.

Alina — planning & prep

The event detail page's split parking/transit accordions and the map's amenity filters let Alina confirm logistics — parking, restrooms, accessibility — in one pass before she commits the family to the trip, instead of discovering a gap once they've already arrived.

Walking the prototype against each persona's own goals, side by side, made the case plainly: the same set of screens serves two different jobs — browsing for something to do, and de-risking a trip already half-decided — without asking either persona to dig for what they need.

View Hi-Fi Prototype ↗

Reflection & final results

Growth as a designer

This project pushed past “make it look nice” into defending every decision with evidence. Early calls — which parking street to recommend, what the restroom hours were — were made on gut feeling and got corrected more than once for stating things that hadn't actually been verified. By the end, checking a claim before shipping it became automatic. Design-systems thinking grew alongside it: a typography hierarchy from H1 through Meta across mobile and desktop scales, color rules (Jungle Green for CTAs only, Bright Amber as decoration-only after a WCAG contrast failure, Prussian Blue for hover states), and consistent spacing conventions kept dozens of components coherent across a large file instead of drifting apart.

Research insight

The strongest insight was that generic-sounding advice was often wrong once actually checked. “Park closest to your destination” sounds like good default parking advice — until you learn the closest, free streets around a major event are exactly the ones that fill first, and the better advice is to recommend a garage or street slightly farther out.

What was enjoyable

The iterative refinement loops on the Park Conditions cards — Weather, Crowd Level, Park Hours, Swan Boats — through rounds of “this looks empty,” “this text is filler,” “this doesn't have enough contrast,” watching a component earn its place on the page. Also the research digging itself: finding the real LYMMO holiday transit schedule, the actual Downtown Orlando Farmers Market vendor count, or that Central Florida's afternoon-thunderstorm pattern could genuinely justify the weather strip's icon sequence — grounding UI copy in real facts made the whole thing feel like a real product decision, not a mockup.

Key challenge

Translating mobile to desktop properly, rather than just stretching, was the most challenging part of the process. Resizing a component and calling it done consistently produced either dead space or cramped mobile-scale text inside an oversized box. Building a real desktop type scale and spacing system, and applying it component by component, was the only thing that actually solved it — validated by the Layout A vs. B desktop A/B test.

Next steps

• Social sharing & email updates — add share-to-social options on individual events, plus an opt-in newsletter for park updates, so discovery isn't limited to people who already thought to check the site.
• A functional hero carousel — users responded strongly to the visuals in testing; the hero should actually rotate and be swipeable, not just represent a carousel in a static mock.
• The Info page — the next big text-heavy challenge — it's part of the main navigation and currently not built for this prototype’s flows. Possibly worth exploring a curated AI chat here, similar to the one on the City's own website, but scoped specifically to Lake Eola Park questions.