Qollabi list of assigned OKRs with the hierarchy popover open
Category
BRM B2B
Year
2023
Deliverables
Research Desktop App Design
Team
2 PMs 2 designers 3 developers

From Scattered Plans to Shared Clarity

Intro

Qollabi is a platform that helps companies collaborate with partners through shared plans, objectives, and KPIs. As the product designer on this project, I translated PM-authored user stories into concepts and design proposals, then worked directly with the PM team to align on final designs before handoff to engineering.

Impact

The redesigned system shifted collaboration from fragmented communication to structured, measurable execution:

↑

Plan Execution Rate

Clear ownership and embedded actions improved follow-through

$2.8M ARR

Revenue Impact

Supported by designing and executing the quarterly user stories and design KPIs

Problem

From Fragmented Communication to Shared Alignment

I don’t know if my partner is working on the same priorities unless I ask.
Channel Manager

Qollabi gives companies and their partners a shared space to plan, set objectives, and track KPIs together. But partners and internal teams both ran into the same underlying issue: the day-to-day work needed to hit those shared goals was scattered.

  • 10–25 active partner plans per manager
  • 5–10 hours per week spent on alignment
  • 3–5 tools used to manage collaboration

Key findings

One Central Place to See Everything Due

  1. There was no single place to see everything assigned to you. Assigned OKRs and quick actions each lived in their own space, so answering "what do I need to do today" meant checking multiple places

  2. The OKR hierarchy made that overview harder to build Objectives, activities, and sub-activities were nested several levels deep -knowing what needed attention today meant drilling into each objective individually

  3. Quick actions didn't belong to the hierarchy at all, but still needed to show up in the same overview

Exploration

Where Should the Central Overview Live?

The research pointed to one clear need: a central place where a partner could see everything assigned to them, OKRs and quick actions alike without checking multiple views. The open question was how to build that central place: keep OKRs and quick actions in their existing separate structures and hope users found what they needed, or design one unified overview that both types of work could live in.

OKRs and Quick actions are existing in their separate structures Objectives, Activities, and Sub-activities stay organized in their nested hierarchy with drill-down navigation; quick actions live in their own dedicated list, unrelated to the hierarchy
One central, flat overview by default, with hierarchy available on demand and a dedicated view for quick actions. Objectives, opportunities, partners, and quick actions all appear as rows in one central list, with the OKR hierarchy shown as a column rather than a tree to click through.

Solution

Designing for Shared Visibility and Action

Rather than picking flat or hierarchical outright, hierarchy was kept but demoted to an on-demand popover, and a dedicated Quick actions tab stayed alongside the central list for when a partner only cared about that subset. This delivered the central overview without discarding either the hierarchy's context or the value of filtering to one item type.

Introducing a flat hierarchy with clear ownership and easy switch between different work modes
Added inline quick actions to reduce friction between insight and execution

Learnings

Designing for Multi-Stakeholder Systems

A few clear principles emerged from observing how teams interact with complex systems and collaboration flows. 1. Problem statements can be a research input - dig into the user stories, don't stop at the label 2. Flat-vs-hierarchical wasn't really a binary - the popover gives the context on demand, anchored right where the user asked for it, without disrupting the flat list underneath. 3. One central place ≠ one identical structure (quick actions vs. OKRs staying visually distinct)