Expandi ProductInbox
Rebuilt Expandi's inbox as one component in three scopes, and handed engineering a working prototype instead of frames.
In an outreach tool, replies are the only reason the campaigns exist; the inbox is where a person takes over from the automation. The brief was to finish half-built flows, then add a workspace inbox and a campaign inbox. Built literally, that's three inboxes.
- inboxes built as one component
- 3 → 1
- Figma frames generated from the prototype
- 505
- roles and actions in the permission matrix
- 7 × 10
- Three inboxes meant three versions of every action and three sets of bugs.
- Roles and permissions weren't written down anywhere, so every screen re-argued who may do what.
- SDRs answering replies all day, and team leads triaging across several accounts.
- The backend couldn't support every action in every view, so the design had to say no gracefully.
- One component, with the scope deciding what's allowed. A seven-role, ten-action matrix became the single source of truth.
- One rule ended a dozen debates: if it can be undone, act and offer Undo; if it can't, ask hard.
- Thread, composer, tags, media and lead details in one layout across all three scopes.
- Bulk actions reuse the same bar and tag picker as lead lists.
- The handoff was the prototype itself, with 505 Figma frames generated from it as reference.
- In development: search is live and the main redesign is being built.
- Design questions during build fell by about half against the previous project, and support now answers "why can't I do this here" from the matrix.
(Keep browsing)
