Support requests,
finally in one place.
Sidewalk is an AI-powered SaaS for residential real estate agents. Its support requests arrived over email, Slack and WhatsApp, spread across channels. I designed the ticketing module that brought them into the product, where every conversation stays with its ticket.
The ticket queue and an in-ticket conversation, rebuilt from my Figma file. All names and messages are placeholders; Sidewalk is under NDA.
The design foundation
The product lived in Adobe XD. It had to become a workspace.
I joined a product that already existed. Its design files were in Adobe XD, and I moved them into Figma. The import came through, but not in a form anyone could keep designing in: most elements arrived fragmented and poorly organised, as loose shapes, paths and layers rather than editable text and components.
Before I could design anything new, I rebuilt the file so the next person to open it could find, edit and reuse what they needed.
Left: what an XD import typically looks like (layer names are illustrative). Right: a rebuilt ticket screen, named by the library’s convention.
Vector 212 · outlined shapes, no font, can’t be edited or restyled.
Text · Roboto Medium · a real text layer, ready for type styles.
File architecture
Structured like a design system, not a folder of screens.
I split the file into a library and the work built from it. Foundations and components come first; each product module is assembled from them in its own section. One naming pattern runs through every layer, so anyone can find a part, switch a variant or trace a screen back to its components.
Design system
One set of parts, so every screen agrees.
With the file readable, the next step was consistency. I pulled the pieces that repeat across the product into a shared library, gave the palette names, and built screens from those parts instead of drawing them again.
This is an overview of that system: colour roles, type, spacing, icons and the core components with their states. Hex values and parts come from the Figma file; interaction states are drawn out here for reference. Every screen on this page is built from these tokens.
Few colours, clear jobs.
Green leads, blue selects, red warns. Each brand colour has one job, and the greys carry everything else.
Main actions, the active nav item, applied filters, focus rings, the selected-ticket marker.
Row and list selection, counts, outgoing messages, medium priority.
Destructive actions like delete, and high priority.
Waiting states, such as a pending ticket.
One family, six steps.
Roboto across the product. Hierarchy comes from size and weight, not colour, so dense tables stay calm.
A 4px rhythm.
Sizes snap to a small scale, and every admin screen shares the same frame: bar, filters, content, drawer.
Redrawn to one standard.
The icons rebuilt during the migration share a grid, a stroke and four sizes.
The library, with its states.
A curated set of the parts the ticketing screens are made of. Hover the buttons: the states are live.
New module · Support ticketing
Support, without leaving the product.
Support requests came in over email, Slack and WhatsApp, across several channels. Context got lost between them, and replies were slow. I designed the ticketing module in the admin console so every request lands in one place: a queue to triage, a ticket to act on, and a conversation that stays attached to it.
A · Triage
One queue, narrowed in two clicks.
Type, assignee, status, priority and date filters sit beside the list, each with a count. Select a few tickets and the bulk bar appears to reassign or delete them; columns can be switched on and off and reordered.
The version I threw away
A ticket page was one screen too many.
My first version opened each ticket on its own screen. Support handles several tickets at once, and loading a new screen for each one made going back and forth slow. The rest of the product already worked in left and right drawers, and they worked well, so the ticket opens in a drawer beside the queue instead.
B · The ticket
Read it, change it, or connect it.
The ticket opens in a drawer beside the queue, so context is never lost. The same component has three states: view, edit (assignee search, type, status and priority), and a state for tickets raised by someone with no matching account.
For those tickets, Find user opens a search across users. Results narrow as you type, and the ticket is linked with one update.
C · The conversation
The thread lives on the ticket.
Messages sit in the same drawer as the details, one tab away. Besides text, a thread can carry links that unfurl into preview cards, single images and galleries, and files like quotes.
Switch the tabs to see how the drawer works. The queue stays put while you move between details and messages.
Interactive: click “Details” and “Messages” in the drawer. Photos are replaced with neutral placeholders.
My contribution
What changed.
My role, plainly
Alongside the founder and engineers.
I didn’t design Sidewalk from scratch. I inherited a working product and made its design reliable: I migrated and rebuilt the files, set up the component system the team designed with, and designed the support ticketing module end to end.
I worked directly with the founder on what to build and with the engineering team on how it would ship.