← All work

Shipping a discussion-platform that lets learners reach every stakeholder, instructors to TAs, without switching channels

A discussion platform for Scaler, built end to end with Claude Code.

I made the design decisions in code, not in Figma:

  • A dashboard four audiences could share
  • Admin tools kept apart from learner tools
  • Where the interface and the server disagreed
Tools ClaudeVS CodeFigma

An exploration, not a shipped case study. Running locally and handed to developers, targeting Q4, so this one has no usage behind it yet.

The second half is the gap. The same reply typed into a closed channel and sent, where it never lands and nothing says why.

One dashboard, four audiences

Frontend · Claude Code · local instance
Scaler Conversations discussion hub from a learner account: a left rail of channels, lounges and direct messages beside an open cohort channel with welcome messages, above a full message composer.

The work at a glance

My role
Product designer
Scope
One dashboard · admin and learner tools apart
Built with
Claude Code, end to end

How it came together

  1. 01

    Took a shared idea from Claude to a written plan.

  2. 02

    Made the design decisions in code, not Figma.

  3. 03

    Pushed past the default and split admin from learner tools.

  4. 04

    Handed off with Figma as the export step.

I made the design decisions in code

Take on the frontend, give threads an ending, then split the screen by role.

Beat 01

A Slack-style dashboard for students, instructors and TAs, with no engineering capacity in the launch window. My co-designer built the backend, I built the frontend. Beyond a text box and a send button, nothing came unasked.

Beat 02

Claude left every channel open forever, so students could message TAs long after a thread ended. Threads now close with their mentor.

But the screen still offers a reply box, so the refusal lands as silence, which I found only by using the app.

Beat 03

Admin and learner views, because running a channel needs different tools than joining one. It tells developers what stays common and what must differ.

An active channel thread with mentor badges, an edited message, and a composer carrying a formatting toolbar plus attachment, emoji, mention, video, voice and screen-share controls.

Where the feature set landed. Formatting, attachments, emoji and mentions working, with the last three built but switched off.

A closed PSA thread where the learner has read-only membership, yet the composer is fully enabled and holds typed text with no disabled state or explanation shown.

The gap itself. The server has closed this thread and refuses the reply, but the box still invites one.

Admin Same channel, moderation tools
Admin channel settings panel: rename and topic fields with Save changes, a Current 23 member list with a remove control on each row, and an Add members section with a filter and checkboxes.
Learner Same channel, participation only
The same channel viewed by a learner: the member list is readable but there is no manage-members control, no add or remove affordance, and no channel settings.

The same channel, both roles. The admin can rename it and add or remove people; the learner can only see who is in it. The manage control is not greyed out, it is simply not there.

Captured from a local build, so the channel list still holds test channels and stray debug messages.

Four accounts in one room

A build that works for one signed-in user is not a discussion platform. The test was four people posting at once, and the table underneath.

In the room Four laptops, four accounts
Four laptops open side by side on an office table, each signed into a different account in the same running build: two showing the #project-pdt channel, one with the add-members panel open on the channel roster, one with a mention in the thread.
In the database The same messages, in order
The local Postgres database open in TablePlus: a query joining messages to conversations returns the session’s messages with channel name, kind, server sequence, sender and timestamp, mixing cohort-jan-2026 channel posts with direct messages to a mentor.

Four accounts in one channel is the only way to see whether a message posted on one screen arrives on the other three, and whether membership changes made by an admin land for everyone else.

The table is the same session from underneath. Every message carries its channel, sender and server sequence, so message ordering could be checked rather than assumed. The schema also holds the mentions, reactions, edits and read state the interface leans on.

What this entry was testing

01

How far past a first draft can careful prompting push a model?

Depth was never the default. Every feature past the basics had to be asked for by name.

02

What does it cost to learn the tools while shipping with them?

Every architectural call was one I was making for the first time.

03

Can you design who is allowed to do what before any of it has a screen?

Partly. The split is real and enforced, but flagging and archiving work underneath with no controls yet.

04

Where do the server and the screen stop agreeing?

Closed threads and archived channels are both enforced by the server and invisible on screen. That is the handover note.