← All work

Shipping a discussion-platform that lets learners reach out to people 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, 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.

Everything past the text box

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

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 reply box that cannot reply

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. I found that only by using the app.

A closed PSA thread where the learner has read-only membership, showing the composer still present and inviting a reply the server will refuse.

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

Two views of the same channel

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

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 renames it and manages people; the learner only sees who is in it. The control is not greyed out, it is absent.

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 reaches the other three, and whether an admin’s changes land for everyone.

The same session from underneath. Every message carries its channel, sender and sequence, so ordering could be checked rather than assumed.

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.