Kyiv time9:41am•5 November, 2026
All work
Case study

Romper

A web platform where teams narrow a long list of ideas down to the few worth building, phase by phase.

Romper is a client platform built at Trinetix. I was one of two product designers, working with a design lead, developers and client stakeholders. I owned the admin dashboards, the personas page and the persona creation flow.

Client dashboard, Projects tab: the third project row in hover, its long name underlined and shown in full in a tooltip, with Personas, Strategy and Ideas progress bars for every project and client totals on the right.
Client dashboard. Every project shows how far it has moved through Personas, Strategy and Ideas.
Problem
Teams collected ideas in canvas tools. Ideas got lost, and nobody could see which ones had the team's support.
What I did
Designed client and project dashboards and the persona creation flow, based on a client brief and three interviews.
Outcome
Dashboards approved after four iterations. Persona management moved into the platform. Partly launched.
01Context & role

Picking the ideas worth building

Romper helps teams choose which ideas to take forward. Each project moves through personas and strategy, then ideas go through three phases, and each phase narrows the list.

I was one of two designers on the product. My part was the admin dashboards, the personas page and the flow for creating a persona. The ideas board and strategy screens belong to the other designer.

02Problem & users

Ideas on a canvas, support nobody could see

Before Romper, teams gathered ideas on canvases in Miro, FigJam or Notion. Ideas got lost between boards and nothing kept them in order. It was hard to tell which ideas the team liked and which they rejected, so it was unclear which ones had real support.

  • Admin

    Runs the idea process. Sets up projects, assigns teammates, manages personas and experts.

  • Teammate

    Discusses and reacts to ideas. A project can have any number of teammates.

  • Subject matter expert

    Brings domain knowledge to the ideas.

03Research

Same product, different questions

  • Client brief

    One session with the client to set the scope.

  • 3 interviews

    One admin, one teammate, one subject matter expert.

The roles wanted different things from the same screen. Admins open Romper to check progress: where each project stands and how many ideas made it to the next phase. Teammates only want to know which projects are waiting for them. That split shaped the dashboard decisions that followed.

04Key decisions

Two decisions that shaped the product

Decision 01

A progress view instead of a control panel

The problem

Early versions treated the dashboard as a menu: shortcuts to users, clients and personas, quick actions, counters. They answered "where can I go", while admins came to find out "what is happening".

Shipped
Shipped client dashboard: each project with Personas, Strategy and Ideas progress bars, and tabs for projects, personas, experts and team.
Each project shows three bars: Personas, Strategy, Ideas. Management moved into tabs and one "Add new" button.
  • Rejected
    Rejected dashboard: a carousel of project cards with one stage bar each, counter blocks with manage buttons, and six identical Add new buttons.
    A hub of shortcuts. Six identical "Add new" buttons and one progress bar per project.
  • Rejected
    Rejected dashboard: a project list with a percentage ring per project, quick action links and counter cards.
    A percentage per project doesn't say which stage the project is stuck in.
  • Rejected
    Rejected dashboard: projects with colored stage tags and four KPI tiles mixing personal and total numbers.
    KPIs mixed "my" and "total" numbers, so they were hard to read at a glance.
  • Rejected
    Rejected client dashboard: projects, quick actions, KPI tiles, a tips carousel, team, personas and experts on one page.
    Everything about a client on one page: projects, team, personas, experts, tips. Too much to scan.

Why

Three bars show where a project is and what's left, which a single number can't. Moving management into tabs freed the main view for progress. The final version went through four iterations and was approved with stakeholders.

Decision 02

Persona creation as a step-by-step wizard

The problem

Personas sit at the center of a project: the team asks them about ideas in the side chat. Admins needed to create them inside Romper.

Why

A persona needs a lot of input: details, answers to core questions, a client and an image. I split it into short steps in a modal over the personas page, so the admin never leaves the list they're building. The last step generates an image from the earlier answers. The admin can refine it with a prompt or upload a photo instead.

  1. Step 01
    Create persona, step 1: name, age, behaviour profile, occupation and location.
    Persona details
  2. Step 02
    Create persona, step 2: core questions about the persona's day, trusted sources and channels.
    Core questions: how this person thinks and decides
  3. Step 03
    Create persona, step 3: assigning the persona to a client.
    Client: who the persona belongs to
  4. Step 04
    Create persona, step 4: generating the persona's image from a description, or uploading one.
    Image: generated from the answers
  5. Step 05
    Create persona, step 5: the generated image, ready to save.
    Image ready: refine or upload instead
Creating a persona: five screens of one modal, from details to a generated image.
05Final UI

Two levels of dashboards

Each level answers one question: what's happening at this client, and what's happening in this project.

One client

Projects for one client with Personas, Strategy and Ideas progress. Personas, experts and team sit in tabs.

Client dashboard, Personas tab: persona cards with photos, roles, locations and View profile buttons, with client totals on the right.
Client dashboard, Team tab: team members with roles, emails, activation toggles and edit actions, with client totals on the right.

One project

Objectives, current status, ideas per phase and who on the team is active.

Project dashboard: objectives, current status, ideas and bookmarks per phase, active users by ideas, likes and comments, and activity over five weeks.

Personas

Active personas and experts at the top, available ones below. "Set journey" places a persona at a stage of the customer journey: awareness, interest or trial.

Personas page: active personas and experts at the top with Set journey buttons, available ones below, and the persona chat on the right.
06Results

What came out of it

  • Client and project dashboards, approved after four iterations with stakeholders.
  • Persona management moved into the platform: admins create and edit personas themselves.
  • Dashboard content defined by a client brief and three interviews.
  • Part of the flows has shipped; the rest is in development.

We didn't track product metrics. I'd measure time from first idea to shortlist, the share of ideas with team feedback, and how many teammates take part in each phase.

07What I'd do differently

What I'd do differently

  1. Agree on a success metric before designing. Without one, the results here stay qualitative.
  2. Test dashboard iterations with users, not only review them with stakeholders. Four rounds would likely have been fewer.
Next caseGAAPT Start a conversation