2025

Tool redesign · Web + Mobile · 20k active users

Two months of design. One week of live testing. A tool that has to work the first time, every year.

Sole designer and de facto product manager for the Activities Tool, Slush's event discovery and management platform serving 500+ events and four distinct audiences: attendees browsing and registering, partners tracking leads and promoting their events, community organizers reaching a niche audience, and Slush's own team curating and supporting the function.

I owned the full platform-facing surface end to end: browsing, search, filtering, event pages, registration, event creation, and organizer management. I set the design direction, defined the constraints, and made the prioritization calls. There was no PM on this project; I filled that role. The CTO and Head of Tech were my primary review partners, pressure-testing designs and flagging gaps before handoff.

key outcomes overview

50+ screens and states designed across 5 surfaces.

Full set of toast and push notification copy rewritten.

New component patterns for cards, filters, registration, and creation flows.

Search, waitlist logic documents & documentation for handoff.

Some context

Slush is a global startup and tech event connecting founders, investors, and operators. The event runs on a digital platform: a suite of tools that serves over twenty thousand attendees each year. The Activities Tool is where those users discover, register for, and manage 500+ events happening during the Slush week.

The tool fell behind the user's expectations.

The Activities Tool had grown into two disconnected halves. The browsing side listed hundreds of events but didn't help anyone find the right ones: no personalization, a tab system with almost no engagement, and a layout that treated every event the same regardless of the user's role or interests. The creation and management side was even worse.

PROJECT
CHALLENGES

Challenge 01

One shot per year to get it right

Challenge 02

No mature product function to lean on

Challenge 04

Four audiences, one surface

From three years of signal to a unified event tool

Post-event feedback, platform analytics, and partner requests accumulated over three years gave me a clear starting point. I synthesized the data and scoped the redesign with the CTO, prioritizing the browsing side first for its breadth of visual changes and user impact, while the creation and management scope finalized in parallel.

Analysis & prioritization

Analysis &

prioritization

Browsing redesign (iterative)

Creation & management

Documentation and DS update

Documentation

and DS update

Handoff

Analysis & prioritization

Three years of post-event feedback, Metabase analytics, and accumulated partner requests provided the signal. Filter and tab usage data revealed what users actually reached for and what they ignored, which set the direction for the browsing redesign. I scoped and prioritized features with the CTO.

Iterative design

The browsing side carried the most surface area and the hardest audience tensions, so it started first. The creation and management side followed once scope was locked. The design process was iterative; this phase took the most time and produced the largest volume of decisions.

Handoff & support

Handoff extended over several months alongside other projects. I supported engineers on interaction details and edge cases as features went live, going back and forth between this and other work as implementation progressed.

So, a lot happened. This is how it's organized.

This section works like the product it describes. Pick a surface from the sidebar, open the decisions that interest you, skip the rest (or maybe don't?). It's a case study about browsing; it would be strange if you couldn't browse it.

Activities Tool ›

Discovery

Landing page

Toolbar

Collections

“For You” page

Landing page as a funnel

The previous landing page was a flat list of events organized by tab. No hierarchy, no guided entry points, no distinction between a first-time visitor and someone who knew what they wanted.

The redesigned landing page sequences content from curated to open: Slush-organized events first, then Signature Side Events, then curated collections for topical browsing, then "Browse by day" for schedule-driven users, and finally the full grid of all side events. Each layer gives a different type of user a reason to stop scrolling and engage without compromising the visibility of any of the event types.

Activities Tool ›

Discovery

Landing page

Toolbar

Collections

“For You” page

Landing page as a funnel

The previous landing page was a flat list of events organized by tab. No hierarchy, no guided entry points, no distinction between a first-time visitor and someone who knew what they wanted.

Activities Tool ›

Search & filtering

Cross-category search

Card redesign

Cross-category search

Results across all event types; filter suggestions when keywords match structured terms.

The previous search was scoped to the active tab. A user on the "Side Events" tab couldn't find an Investor Day event because it lived on a different tab. Search and content were structurally misaligned.

Search now returns results across all event categories in a single view. When a keyword matches a filter term, the search suggests that filter directly, so users move from a keyword to a structured query in one step. This closes the gap between searching and filtering; they're no longer separate actions.

The filter suggestion mechanic runs on pre-mapped aliases. Users searching "startup" might mean "Target audience:founders" or "Ticket requirement: startup". Suggesting the structured filter when the keyword matches avoids the dead-end of a text search.

Activities Tool ›

Search & filtering

Card redesign

Cross-category search

Results across all event types; filter suggestions when keywords match structured terms.

Activities Tool ›

Event creation

Two-step creation flow

Additional fields

Two-step creation flow

Industry standard for event creation to avoid one massive scroll.

Step 1 carries the controls that shape the event's behavior on the platform: whether it's visible in browse, whether registration is application-based or open, whether it's limited to Slush ticket holders, what the capacity is, and who manages it. These are structural decisions an organizer makes once.

Step 2 carries the content that makes the event discoverable: timing, location, industry, tags, and the custom questions. Keeping these separate means an organizer can set up the event structure, save, and return later to fill in content details as they're finalized.

Activities Tool ›

Event creation

Two-step creation flow

Additional fields

Two-step creation flow

Industry standard for event creation to avoid one massive scroll.

Activities Tool ›

Management

Multi-manager support

Waitlist and capacity controls

Multi-manager support

Team members manage registrations independently; creator retains ownership.

Previously, one person managed each event. For partners running multiple events simultaneously with team members in different roles, that single point of management was a bottleneck.

Organizers can now add managers directly during event creation (step 1) or after. Each manager can review registrations, manage attendees, and access the event's data independently. The creator retains ownership; added managers operate with the same management capabilities without needing the creator's credentials or availability.

Activities Tool ›

Management

Multi-manager support

Waitlist and capacity controls

Multi-manager support

Team members manage registrations independently; creator retains ownership.

Previously, one person managed each event. For partners running multiple events simultaneously with team members in different roles, that single point of management was a bottleneck.

Activities Tool ›

Event page

Event page as a side panel

Browsing context stays visible; sequential navigation through results without closing.

The previous event page was a full-page view. Clicking an event took the user away from the browsing flow; getting back meant reloading the page and losing scroll position and active filters.

The event page now opens as a side panel overlaying the browse view. The browsing context stays visible behind it: active filters, scroll position, the card grid. Navigation arrows let users step through results sequentially without closing the panel. This keeps discovery continuous , and addresses one of the most-reported user complaint from previous years.

The side panel carries the registration block, which requires attendees to opt in or out of appearing on the public attendee list before the register button activates. This is a privacy-first design: the choice is explicit, not buried in a terms page, because attendees at a business event need to control their visibility.

Activities Tool ›

Event page

Event page as a side panel

Browsing context stays visible; sequential navigation through results without closing.

The previous event page was a full-page view. Clicking an event took the user away from the browsing flow; getting back meant reloading the page and losing scroll position and active filters.

Cross-department requests for comparison work dropped by more than half within three months of launch.

The redesigned Activities Tool went live for 2026 and is currently in its first full event cycle. Quantitative impact (registration rates, fill times, no-show reduction, creation-to-publish time) is being measured against 2024–2025 baselines and will be updated after the event.

Initial feedback from partners and internal teams has focused on the event creation and management views: the on-platform registration fields and multi-manager support resolved pain points that had been flagged for multiple years. The tool was tested with the tech team and key stakeholders in a structured session after which some elements of the creation flow were moved around.

Personal thoughts

The design was handed over in parts so that engineering could start building while other surfaces were still being finalized. On a tool this size, with independent views (browsing, creation, management, event page), that parallel handoff kept the compressed timeline viable. I'd do it again, but earlier: scoping the handoff sequence at the start of the project rather than deciding it as design progressed would have reduced the back-and-forth during implementation. On a yearly cycle with one live window, every week of implementation friction is a week of testing lost.

XXX

Impact is still to be measured.