I translated 20+ legacy event experiences into reusable, implementation-ready patterns within an evolving enterprise design system.
A mature global events platform was being migrated to a new enterprise design system.
Over time, event-specific requirements had accumulated across content, scheduling, responsive behavior, and lifecycle states, creating patterns that did not map cleanly to the new system.
My role was to separate genuine product requirements from legacy complexity, determine what could be reused, configured, composed, or selectively extended, and translate those decisions into reusable patterns, responsive rules, state models, and implementation-ready guidance.
01
The platform supported four connected stages of the attendee journey.
Find the content, people, and moments worth attention.
Key experiences
Turn discovery into a clear, personal agenda.
Key experiences
Stay oriented as the event changes in real time.
Key experiences
Continue learning after the live moment has passed.
Key experiences
separate variation from inconsistency
What the audit revealed
Many page-level inconsistencies came from a much smaller set of unresolved system decisions.
Session information, for example, appeared across catalogs, recommendations, schedules, search results, and detail experiences.
The unit of design shifted from the individual page to the recurring pattern.
02
Visual similarity was not enough to determine whether a system component could support a legacy requirement.
I evaluated each recurring need through six lenses before choosing a direction.
Product ↔ system decision model
Session cards were the strongest test of the system.
Depending on context, a session could require metadata, classification, speakers, scheduling, favorites, location, live availability, on-demand playback, and evaluation behavior.
The easiest solution would have been to rebuild the legacy card as a custom event component. I avoided that.
Session card transformation
Same product requirements.
Clearer system ownership.
▦Fri, Apr 18
◷1:00 PM - 2:00 PM
PST
⌗DEV302
Learn how product and engineering teams can use composable APIs, reusable patterns, and practical guardrails to build reliable AI workflows at scale...
Show moreDEV302April 18, 20261:00–2:00 PM PST
Use composable APIs and practical patterns to create reliable AI experiences at scale.
View session details →Moscone Center · San Francisco, CA
Moved into the existing system tagbar for discovery and onsite navigation.
Repositioned within the hierarchy instead of creating another UI region.
Mapped to a link-group pattern supporting imagery, multiple speakers, and overflow.
Controlled by lifecycle state instead of permanently occupying card space.
The card became simpler because the hierarchy became more deliberate, not because required information was removed.
04
A session card was not static. Its behavior changed as the event progressed.
Rather than designing a separate component for every moment, I modeled those moments as states of one underlying pattern. The same state model carried into Session Details, preventing contradictory behavior between discovery and the full session experience.
State model
The card structure remains consistent while the lower action region changes with lifecycle state.
BRK102
Tue · 10 AM · Room 401
Alex Morgan · Jordan Lee
BRK102
Tue · 10 AM · Room 401
Alex Morgan · Jordan Lee
BRK102
Tue · 10 AM · Room 401
Alex Morgan · Jordan Lee
BRK102
Tue · 10 AM · Room 401
Alex Morgan · Jordan Lee
05
My Schedule combined chronological organization, variable-height content, scheduling actions, and overlapping events.
Conflict behavior became a useful responsive test. On desktop, conflicting items remain within a shared timeline. On mobile, the timeline gives way to independently stacked cards while the same conflict remains legible through state.
Responsive behavior
The scheduling conflict stays constant. Only its expression changes with available space.
BRK102
10:00–11:00 AM · Room 401
Alex Morgan · Jordan Lee
✓ ScheduledWRK216
10:30–11:30 AM · Studio B
Casey Kim · Rowan Park
✓ ScheduledBRK102
Room 401
Alex Morgan · Jordan Lee
✓ ScheduledWRK216
Studio B
Casey Kim · Rowan Park
✓ Scheduled
The schedule also needed to support sessions, agenda items, and meetings.
Rather than create unrelated components or force every type into one universal card, I created variants built on the same structural foundation.
Full metadata + speakers + lifecycle behavior
Reduced content + scheduling
Reduced content + meeting-specific behavior
07
The legacy My Event floating tab had become a catch-all surface: profile setup, utility destinations, and an embedded schedule all competed inside the same compact overlay.
Rather than compressing more behavior into the tab, I separated the responsibilities. My Event retained the existing modal pattern for lightweight event utilities, while scheduling moved into a dedicated My Schedule experience designed around chronology, conflicts, and multiple content types.
Separation of concerns
Owns both Utilities + scheduling inside one floating surface
Owns Profile + event utilities
Owns Chronology + conflicts + content types
08
The same system logic extended beyond scheduling.
The legacy sponsor directory treated sponsorship tier as page position. Premier sponsors appeared first; lower tiers accumulated farther down the page and became harder to find.
I kept the reusable sponsor card, but rebuilt the navigation around it. Search, tier navigation, and filters made every sponsor reachable through the same result pattern.
Sponsor architecture
Tier moved out of page order and into navigation.
A reusable pattern is only useful if engineering can build it without reconstructing the reasoning behind it.
I documented component configuration, the conditions that change behavior, and the responsive rules that connect one view to the next.
Component anatomy · Required + conditional content
Lifecycle states · Selection + input conditions
Responsive rules · Overflow + navigation
Selected engineering handoff
Component choices, state changes, and responsive transitions, specified at the point engineering needs them.
01 / Session card
DEM302 · April 21 · 9:00–10:00 AM
Explore practical ways to bring AI into your development workflow. More session context appears here.
South building · Room 101 (example)
Speakers
Illustrative rule preview.
“Watch live now” appears as the primary action only while the session is live.
| When | Primary action | Secondary actions |
|---|---|---|
| Pre-event | None specified | Favorites · Schedule |
| Live | Watch live now | Favorites · Schedule |
| Session ended | None specified | Favorites |
| On-demand | Watch on demand | Favorites |
“leading element: tagbar (replaces badge)”
“session code in metadata” · “dedicated speakers label”
“watch live now” · “only appears when the session is live” · “always primary variation”
02 / Filter grid
Selected pills wrap above this list. The filter panel stays alongside it on desktop.
Pagination appears below the list when results overflow.
Selection demo; the results area illustrates the documented layout.
3 selections. Remove a pill, change a checkbox, or clear all.
Checkbox configuration, secondary buttons, and Twilight token references keep the implementation tied to existing components.
“multiple selected pills should wrap to additional rows as needed”
“clear all appears after the selected pills and clears all active selections at once”
“pagination (bottom of filter grid, present during overflow)”
03 / Messages
Your event details are ready. Let us know if you have any questions.
Example only. Nothing is sent.
A mobile view recreated to demonstrate list-to-detail navigation.
Default: show the filter and message list. Hide message detail until a message is selected.
The pillbar, icon list, text block, reply field, and primary button are configured together into one mobile flow.
“default view” · “pillbar (filter) visible” · “icon list (message list) visible” · “form (message detail) hidden”
“on message click” · “icon list: hidden” · “form: shown”
“default state when no input is present” · “triggered when user enters input”
10
A shared implementation model replaced page-by-page interpretation.
I reconciled legacy event requirements with the evolving enterprise system through reusable structures, defined states, and explicit implementation rules.
| Before Page-specific decisions | After Shared implementation model |
|---|---|
| One-off pages and patterns | Reusable structures across content types |
| Locally solved states and interactions | Shared lifecycle and responsive rules |
| Screen-focused handoffs | Explicit edge cases and implementation guidance |
At final handoff
Recurring components, schedule variants, and implementation rules were defined. The work had moved into engineering implementation and QA.
My contract concluded during implementation, so I do not claim post-launch metrics.
Reflection
Simplicity came from deciding where complexity belonged.
What stays consistent, what changes with context, and what the component, page, or system should own.
Create enough shared structure for different experiences to stay coherent, without erasing what makes them different.
