One designer, one engineer, zero budget and lots of passion for our craft.

We built a Planning Poker app as a side project, curious about what our version could feel like.

Planning Poker - Hero Image

Planning Poker, at a glance

Planning Poker is a collaborative estimation tool for software teams. I designed the host and guest experience, from creating and joining a room to voting and revealing estimates.

This case study follows the design of the room itself: a shared table and participant seats that communicate what’s happening in the round, who has voted, and which seat is yours. The challenge was to make that information easy to follow while keeping the interface friendly and leaving space for the team’s conversation.

Starting with the stories

My first ideas centred on the story being estimated. I imagined a place where the team could add stories before a session, move through them one by one, and always see the active one on screen.

It seemed like a natural starting point. Planning Poker is used to estimate stories, so shouldn’t the story be right there?

Early concept featuring stories

Early wireframe with the estimated story prominent on screen

I walked through the flow with the developer. He questioned some of the features I’d included, and I realised I’d designed around my understanding of Planning Poker without seeing how his team actually used it.

I asked him to record their next session so I could see what the interface actually needed to support.

Watching a real session

In the recording, the team discussed what they were estimating as they went. They weren’t relying on the tool to tell them, and they didn’t need a prepared list of stories. The feature I’d given so much space would have added setup for information they were already handling in conversation.

So what does this screen need to tell someone that the conversation can't?

Putting everyone around a table

The recording shifted my attention to the people in the room and the round they were playing. Those became the centre of the interface.

Planning Poker already had a useful structure to borrow: people estimating together with cards around a table. I brought that arrangement onto the screen, giving each participant a seat around a shared space.

At first, I used the centre for the host’s Reveal estimates button. The action affected everyone, so placing it in the shared space felt natural.

Wireframe showcasing the table holding the "reveal" button, with the timer above it

Early wireframe with the Reveal estimates button in the centre of the table and the timer above it

What I didn’t expect was how useful that space would become. As I worked through the different stages of a round, I realised I was treating the table as empty decoration while trying to squeeze useful information around it. People needed to know whether they were waiting for the host, choosing a card, or looking at revealed estimates.

I moved the messages into the centre, giving the session’s changing status a consistent place on screen. Even the timer eventually joined them when it turned out its original position above the table was taking up too much space on smaller desktop screens.

The table now communicated what was happening in the round. Next, I needed the seats to show what was happening with each person.

The centre of the table communicates the changing stages of a round.

The seats had more work to do

At first, I considered showing each revealed estimate on a separate card beside the person who chose it. That kept the vote connected to the participant, but added another object to every occupied seat. Each person already had an avatar on the table, so I wondered if it could carry the estimate instead.

The avatar also needed to show who had voted while keeping their estimate hidden. Inspired by the outline around someone speaking in a Teams meeting, I used a purple border to mark a submitted vote.

In the final design, when the host reveals the votes, each initial becomes the chosen number, keeping the estimate attached to the person without adding a separate card. Anyone who hasn’t voted shows a dash instead.

Participant seat states: empty, joined, voted, revealed estimate, and no estimate

Wait… which one am I?

During our final design review, the developer spotted something I’d missed:

What happens if two people in the room have the same name?

The voting states showed what each person had done, but people also needed to recognise their own seat. I worked through the solution during the meeting, giving the current user a distinct purple-filled avatar and checking how it combined with the host’s crown.

One avatar now had to communicate who you are, your role in the room, and whether you’ve voted.

Avatar treatments for the host, current user, and current user who is also the host

Keeping voting in the room

Choosing a card also needed to work within this shared space.

The first version used a modal. A participant clicked the question-mark card, chose an estimate from the deck, confirmed it, and returned to the room.

Earlier flow: choosing an estimate in a separate window.

But that meant covering the room during its main interaction: voting. That’s why I moved the deck onto the main screen. Clicking the question-mark card now opened the estimates right next to where it sat, so no one lost sight of the room while choosing.

During our final review, the developer questioned the remaining step: if the host had already started the round, why did guests still need to click the question-mark card to open their decks?

We considered drawing more attention to it with a subtle animation, a hint, or a label, but each solution meant adding another thing for the user to notice. So we cut the click instead.

In the final design, the deck opens automatically when the host starts a round.

Final flow: the deck opens automatically and closes after a card is selected.

Small decisions at the door

Before anyone reaches the table, they need to create or join a room. I wanted that setup to ask as little of them as possible.

The name fields originally started empty, but we later decided to replace them with editable suggestions, so choosing a team name - or deciding what to call yourself - could be optional. Keep the suggestion or make it your own.

Curious CapybaraSprint WizardsSleepy SlothThe Merge MonstersNoble NarwhalCtrl Alt EliteDaring DolphinRubber Duck SquadWitty WombatThe Bug Busters

Teams can also choose between a standard deck and a meme deck during setup. Both use the same voting interaction; the cards simply give the room a different personality.

Standard and meme card decks

What’s next?

The design is ready to build. What it’s missing is a real team using it.

Once it’s built, I’ll be watching for three things: whether people know what’s happening without having to ask, whether voting starts without hesitation, and whether everyone can identify their own seat and recognise when they’ve voted. I’d also watch whether the avatar animations make changes easier to follow or draw attention away from the conversation.

Final Scrum Poker home page with Create Room and Join Room actions