Venue.sh
2024
Designing in-app notifications for Venue.sh
As Senior UX Designer on Venue.sh, I led the design of the in-app notifications experience — a bell-and-panel system in the global shell that surfaces what changed in the portal since you last visited, without adding another channel developers have to monitor. The work spanned notification types, header placement, unread states, and granular preferences (email, in-app, announcements) in Settings — balancing signal over noise for daily users and broadcast control for platform teams.
Overview
The portal should tell you what changed, not make you go looking
I treated notifications as part of Venue’s single pane of glass — not a separate product. The design goal was to close the loop on in-portal events: scorecard failures, template runs, import completion, assignments, and platform announcements — surfaced where users already work, with a clear path to the underlying entity. Success meant fewer “did you see…?” Slack messages and a credible complement to the Home “since you last visited” activity feed, without competing with the Assistant or global search for header attention.
Problem
Important updates were scattered, easy to miss, and hard to control
Venue already generated meaningful events across catalog, scorecards, templates, and imports — but users had no consistent in-product way to know something needed their attention. Platform engineers broadcast changes through Slack or email; developers missed scorecard regressions or completed jobs because nothing pulled them back into context. A Aug 2026 product brainstorm flagged Settings as a gap: no granular notification preferences (email, in-app, announcements). The underlying issue wasn’t missing data — it was no designed delivery layer that respected persona differences and alert fatigue.
Research
Not everyone wants the same interruption
I mapped notification needs across personas: Developer Don wants actionable, entity-linked updates (ownership changes, template outcomes); Manager Mel cares about team scorecard movement; Platform Engineer needs to send announcements and avoid becoming a human notification router. Journey mapping surfaced tension with existing surfaces — Activity Log is audit-oriented, email is async and easy to ignore, Slack is where noise already lives. The design insight: in-app notifications should be event summaries with deep links, not a second inbox — and preferences had to be first-class, not a post-launch afterthought.
Ideation
Three layers: notify, triage, control
I explored a header bell with unread badge, a scrollable notification panel grouped by time and type, and a Settings matrix for channel preferences (email / in-app / announcements). Event categories were scoped deliberately — operational (imports, sync), governance (scorecards, assignments), and broadcast (platform announcements) — each with different default urgency. I paired in-app delivery with “mark read / mark all read” and entity deep links so a notification was always a shortcut back to work, not a dead-end toast. Platform admins needed a path to org-wide announcements without duplicating email blasts.
Designs
Shell-native, scannable, and quiet by default
Key decisions: place the bell in GlobalHeader alongside Assistant and account menu — visible but subordinate to primary navigation; use Badge (dot vs count) per design system guidance, with accessible naming for screen readers. The panel used dense List rows — icon, title, timestamp, read/unread state — with clear empty and “all caught up” states. Settings IA was streamlined to host granular prefs without duplicating user overview elsewhere (another whiteboard gap). I designed read/unread and grouping so the feed stayed scannable at a glance, and made announcement-type notifications visually distinct from personal actionable items.
Lessons
Notifications are a trust contract with the user’s attention
The biggest lesson: every notification competes with flow state — if we surfaced low-value events, users would mute everything, including critical scorecard failures. Preferences aren’t polish; they’re core UX for an IDP serving engineers with real alert fatigue. Header real estate forced discipline — notifications had to earn their place next to Assistant and global shortcut search, which meant ruthless event prioritisation with product. Finally, in-app and Home activity feed had to tell a coherent story: one answers “what needs me now,” the other “what happened while I was away” — designing them in isolation would have duplicated confusion.
