Work

KumoHQ · Internal tool redesign

Redesigning KumoHQ's project tool so the whole team uses it

Kumo Board is the tool KumoHQ uses to run client projects. In practice only the PM used it. Everyone else, clients included, worked from chat messages and calls. People complained about it every day, so I worked with our PM to redesign it.

The core loop, in 11 seconds. Open a ticket from My work, move it to the next stage, and it lands with the next person, with a note. The PM is told without anyone sending a message.
My role
Product designer, end to end
Team
Me, with our PM
Duration
4 months, alongside client work
Status
Approved, in development
What
A redesign of the agency's project tool, for the team and for the clients we build for.
Why
Work, updates and feedback lived in Discord, Slack and calls. Things got missed, and our Associate PM pieced it all together.
The idea
Every ticket follows one track from Brief to Done and always knows whose turn it is. Clients see progress and give feedback through links, not chat.
The hard call
For clients, I chose review links with no account over a full client portal.

The problem

Only the PM used the tool. Everyone else worked around it.

The PM assigned tickets in the tool, then posted the links on Discord, and the team worked from those messages. Clients got their updates on calls and in Slack.

Counted from my own account

10client workspaces, each with its own inbox
99+unread in one client's inbox, 43 in another
~5steps to hand one ticket to the next person
6 of 7changes on one ticket made by the PM
  1. Hand-offs ran through the PM

    Passing work on meant changing its team in a hidden menu, and nobody was told.

    From the teamTickets get shared on Discord, we go and find them, and things get missed in the back and forth.

  2. Finding your own work meant building the view yourself

    A cross-client dashboard existed, but it showed where every ticket sat, not what was yours today.

    From the teamMost of us worked from the PM's Discord link, not the dashboard.

  3. Clients couldn't see where their project stood

    Progress reached them on calls and in Slack, with nothing they could check themselves.

    From clientsThey couldn't review progress, missed things, and it made them anxious.

  4. Client feedback arrived everywhere

    Clients, mostly outside India, review when it suits them: ideas in Slack, updates on WhatsApp, hour-long calls.

    From our PMsOur Associate PM gathered every comment from calls and Slack, then turned them into tickets by hand.

What it looked like

A tracker people found clunky.

The problem underneath

The team didn't work in sprints. Work passed along a line: brief, design, client review, build, test. The tool had no way to pass it.

How we chose

For each problem I wrote two or three directions and where each might break. AI turned those notes into rough wireframes, so our PM and I could compare them side by side. The ideas and the pick were ours, and I designed every final screen. The ruled-out drafts close each section.

01 · Hand-offs

Work should move to the next person on its own, not wait for the PM

Before · the live tool, redrawn with placeholder names The old ticket: the designer's status list ends at Design Completed, and the next step is written in the description
1 The designer's status list stops at Design Completed. Ready for Dev belongs to another team. 2 So the next step gets written into the description, and the PM moves it.

Give every ticket the same track

Brief, Design, Client review, Build, Test, Done. The same six stages for every client, each owned by someone from that client's project team. The ticket always shows whose turn it is.

One ticket, Brief to Done, in 18 seconds. Each stage has one owner, and the ticket moves on to the next without the PM passing it along. When the client asks for a change, it goes back a stage with the note attached.
A ticket open in a side panel, with the six-stage track at the top
The ticket. The track shows where it is and whose turn it is, on every screen it appears. The next step is one button, not a status buried in a menu.

Let a ticket skip what it doesn't need

Six stages for every ticket only works if a ticket can miss one. Skipping asks why, marks the stage as skipped on the track rather than hiding it, and tells the PM. A copy-only change can go straight from Brief to Client review, and anyone opening it later can see that was a decision.

Skip Design on this ticket: the track shows Design struck through, with a field asking why it isn't needed
Skipping a stage. The reason is optional but it sits on the ticket, so nobody has to ask why Design was missed.

Hand off in one step, with the next person already filled in

The usual owner of the next stage is pre-filled, and you leave a short note. The ticket leaves your list, and the next person and the PM are told. No Discord message needed.

Move to the next stageMove sheet with the next owner pre-filled and a note field
Then it's someone else's turnMy work after the move, with the ticket in the Handed off list
Left: the next owner is already filled in from the project team, and you leave a short note so context travels with the work. They're told without anyone sending a message. Right: the ticket leaves your list and appears under "Handed off this week".

Reach people where they already are

A better tool doesn't pull anyone out of Discord on its own. So the hand-off goes to them: Kumo connects to Discord and sends the update as a direct message. Hand-offs and work sent back are on everywhere by default, because those are the ones that stop someone else working. Everything else is a choice, per channel.

Notification settings: each kind of update can be switched on for Kumo, email and Discord
Notifications. Discord gets only what you switch on here. The aim isn't to stop people using Discord, it's to stop the tool needing someone to post in it.

Ruled out · drafted with AI from my notes

AI-drafted low-fi sketch: A Hand off button

A "Hand off" buttonEach team still had its own statuses, so the button would hide the problem, not solve it.

AI-drafted low-fi sketch: A your turn queue

A "your turn" queueA view on top of data nobody kept up to date. It became the My work page instead.

02 · One workspace

One workspace for the agency, with clients as a list

Drag to compare · the live tool, redrawn with placeholder names
After: My work, one list of today's tickets across every client
Before: a workspace switcher listing ten workspaces, over an inbox showing 99+ unread
BeforeAfter
Left: ten workspaces, each with its own inbox, teams and list of issues. To find your work you opened them one by one. Right: one list, every client, the ticket due first at the top.

Start the day on your own work, across every client

My work answers one question: what's mine today? The ticket due first is up top, then everything else at your stage, then what you handed off this week.

Switch clients in one click

Clients sit in the sidebar with a count of what's waiting. Teams exist once. A client's board has the six stages as its columns.

A client board with six stage columns
A client's board. The columns are the six stages, each labelled with the role that owns it. Switching clients is one click in the sidebar.

Ruled out · drafted with AI from my notes

AI-drafted low-fi sketch: A My work page on top of the ten workspaces

A "My work" page on top of the ten workspacesQuick to ship, but teams and inboxes would still exist ten times over.

AI-drafted low-fi sketch: A client rail with counts

A client rail with countsShowed where work was waiting, but that wasn't enough on its own. The counts moved into the sidebar.

03 · Client progress

Clients should see progress against the dates they agreed, not wait for a call

Before · the live tool, redrawn with placeholder names Old analytics: a cycle 142 days overdue at 0% complete, with a flat burndown
1 A sprint 142 days overdue and 0% done. 2 The chart meant to show progress never moved. Nobody here planned in sprints, so the only real progress report was the PM on a call.

Draft the plan from the signed scope of work

At kickoff, the AI reads that signed document and drafts the phases and deliverables, showing the line each one came from. Dates it can't find stay empty until a person agrees them.

Plan kickoff: AI drafted phases and deliverables from the scope of work
Kickoff. Every deliverable cites the line of the signed document it came from, so the PM can check the draft rather than trust it. Dates the AI couldn't find stay as "Set date" until a person agrees them.

Let progress add itself up

Tickets inherit their deliverable's date, so the plan stays true as work moves along the track. It shows what's late and what's waiting on the client.

A client plan: phases, deliverables with dates, and a timeline
The client plan. Phases and deliverables against the dates we agreed. The timeline marks what's at risk and what's waiting on the client, so the two never look the same.

Keep cycles for the teams that actually use them

Sprints weren't the problem, client work was. Cycles stay in the product, switched off by default for client projects and on for our in-house ones. When they're on, the cycle sits as a filter above the same six stages, so a team can plan in two-week blocks without changing how work moves.

A client board with cycles switched on: a cycle bar above the six stage columns
Cycles on. The bar above the board shows the current cycle and its dates, and filters the same six columns. Turn it off and the board is unchanged.

Send clients a weekly update they can read anytime

The update is drafted from the plan: what got done, what's next, what we need from them. The PM checks it and sends it as a link. Nothing goes out on its own.

The client tab: items waiting on the client, work shared for review, and a weekly update ready to send
The client tab. What the client owes us, what's out for review, and this week's update, in one place.

Ruled out · drafted with AI from my notes

AI-drafted low-fi sketch: Repair the sprint charts

Repair the sprint chartsThe tool was built for sprints, but client work runs on agreed dates per phase. Accurate charts still answer the wrong question for client work, where dates are agreed per phase. So cycles stayed, scoped to the teams they suit.

AI-drafted low-fi sketch: An AI that keeps tickets tidy

An AI that keeps tickets tidyConstant suggestions feel like noise. AI helps once, at kickoff.

04 · Client feedback

Feedback should land on the ticket, wherever and whenever the client gives it

Before · the live tool, redrawn with placeholder names The old ticket with call feedback typed into the description
1 Feedback from a client call, typed into the ticket description by hand. Anything sent later on Slack had to be copied in the same way.

Ask for a decision with one link

The PM picks what to show and asks one question. The client opens the link on their phone, in their own time zone, and approves with an email code. Their words land on the ticket and the track moves on.

The PM shares the workShare for review sheet with two design options and a question for the client
The answer lands on the ticketThe client's approval with a note, shown on the ticket
Both screens here are the PM's side of the loop.

Turn a call into ticket updates in one go

After a feedback call, the PM pastes their notes. The AI suggests which ticket each point belongs to, and the PM checks every one before saving. Anything it files wrongly can be pointed at another ticket, or left off, before it reaches anyone. That's the Associate PM's evening of copying, in one pass.

Log call feedback: call notes split into suggested updates on three tickets
Log call feedback. The PM pastes the notes straight from the call. The AI suggests which ticket each point belongs to, and each one can be re-pointed or unticked before saving. Saved notes are marked as coming from a call, not the client's own words.

Ruled out · drafted with AI from my notes

AI-drafted low-fi sketch: Tools for the PM only

Tools for the PM onlyThe client stayed outside and the PM logged what they said. On its own, the PM was still the switchboard.

AI-drafted low-fi sketch: A client portal

A client portalThe biggest build, and one more login for clients to ignore. See the hard call below.

The hard call

Review links, not a client portal

A portal, where clients log in and see the whole board, was the obvious answer to both client problems. It was also the biggest build.

Decision
Give clients a link per review and a weekly update link, with no account.
Why
Clients already juggle three channels with us: WhatsApp when they want a quick answer, Slack day to day, email for anything formal. A fourth place, and one they'd have to learn, was never going to win against the three they already have open. A full board would also show them internal work they don't need.
What it changed
The client side became two small pages instead of a second product. The portal stays an option for later, if clients ask for more.

Working with our PM

The last review changed four things, and none of them were the direction

I walked our PM through all 116 screens. Our PM was in this from the first set of directions: we picked the approach for each problem together, and I brought work back to them at every stage. The last pass came back as “approved with minor refinements”, so the structure, the six stages and the review links stayed. These are the four things that pass changed.

What they flaggedBeforeAfter
Sending work backOnly Client review and Test could send work backEvery working stage can, including Build. The sheet names the next owner, asks why, and says what happens to the stage it leaves.
What clients can seeThe share sheet didn't say what stays privateIt says comments, notes and activity stay private, and the PM can turn a link off at any time.
Why a plan is lateHealth labels with no reasonEvery label says whose side the delay is on. Waiting on the client is never shown as Late.
Missing statesHappy path for comments, links and AI draftsScreens for a comment that didn't post, a link that didn't send and a weekly update the AI couldn't draft.
Sending work back from BuildSend back from Build sheet with the next owner, a reason and what happens to Build
Turning a review link offClient tab with a review link turned off, shown on the row with Undo
Left: the developer sends work back to design, with a reason. Build waits, and nothing done so far is lost. Right: the PM turns a link off and the row confirms it, with Undo.

Next: a two-week pilot with one client's crew, watching how many hand-offs happen without a Discord message, and how many review links get answered.

How we'll know

What we'll measure once it ships

MeasureTodayTarget
Handing work on~5 steps, then a Discord message1 move and a note
Finding my workA dashboard you had to filter yourselfMy work, already filtered, as the page you land on
Who moves ticketsThe PM, 6 of 7 changesThe person doing the work
Client progressTold on calls and in SlackA plan and a weekly update link
Client feedbackGathered by hand from Slack and callsLands on the ticket
Who uses the toolThe PM, plus ticket links posted in DiscordEveryone at their own stage, with Discord carrying updates, not instructions

Today's numbers are counted from my own account and the tickets I work on. "~" marks an estimate.

What I learned

Three things I'll carry into the next project

  1. When people work around a tool, follow the workaround

    The Discord links and Slack threads already described the tool people wanted. I audited the screens first; the workarounds would have got me there faster.

  2. Look at what people use, not what the tool offers

    The sprint features sat unused, while the team had added its own Designer, Developer and QA fields to every ticket.

  3. The right fix isn't always the biggest one

    Review links beat a client portal because they fit how clients already behave.

You made it to the end. Thanks for reading :)