/
Playbooks vs Checklists Options

Playbooks vs Checklists Options

Problem

Terminology Clash:

  • The team tried to rebrand "Playbook Runs" to "Checklists" to make the product more accessible

  • This created massive confusion because:

    • The icon changed from Playbooks to a checklist icon in the RHS (Right-Hand Side)

    • The main action button said "New Checklist" but the submenu still referenced "Start Run"

    • When you clicked "Start a Run," it asked for "Checklist Name" instead of "Run name"

    • The product appeared to be rebranded from "Playbooks" to "Checklists" when it wasn't.

The Core Problem

Two different concepts got merged in a confusing way:

  1. Playbook Runs = Executing a pre-defined, structured, repeatable workflow template (for teams/processes)

  2. Checklists = Lightweight, ad-hoc task lists that anyone can create quickly (for personal/simple tasks)

What went wrong:

  • Instead of keeping these as separate, distinct features, the team tried to unify them under "Checklists"

  • This obscured the value of Playbooks for existing power users

  • Created inconsistent terminology throughout the UI (Run vs Checklist vs Playbook)

  • Made it harder to discover what each feature was for

  • Confused internal team members and may confuse external customers

Decision Made

The team decided to revert:

  • Bring back "Playbooks" and "Runs" terminology

  • Keep the Playbooks icon and branding

  • Now they need to decide: What to do with the Checklists feature?

Option 1: Combine both checklists and playbook runs into one

Pros

  • Single source of truth - Users don't have to context-switch between different locations to find their work items

  • Reduced cognitive load - One mental model for "things I need to complete"

  • Better discoverability - Users naturally encounter both types without needing to know they exist separately

  • Simpler navigation - Fewer top-level menu items and navigation paths

  • Unified search/filtering - Can search across all task-based items in one place

  • Lower learning curve - New users only need to learn one interface

Cons

  • Conceptual ambiguity - Blurs the distinction between lightweight checklists and structured playbook runs

  • Potentially cluttered views - Could become noisy if users have many items of both types

  • Different contexts mixed - Checklists (personal/ad-hoc) and runs (team/process) serve different purposes

  • Harder to optimize UX - Difficult to design for two different use cases in one interface

  • Action/filtering complexity - Bulk actions and filters need to accommodate both types

  • May not scale well - If usage grows significantly for either type


[U+200C]

Option 2: Separate Playbooks and Checklists

Pros

  • Clear mental model - Distinct boundaries: Checklists = personal/simple, Playbooks = team/structured

  • Optimized experiences - Each interface can be tailored to its specific use case

  • Better scalability - Each product can grow independently without constraints

  • Targeted permissions/governance - Easier to apply different access controls and policies

  • Reduced noise - Users only see what's relevant to their current context

  • Clearer product positioning - Easier to explain, market, and document two distinct features

Cons

  • Fragmented experience - Users need to remember where to go for different types of work

  • Increased navigation overhead - More clicks and context-switching between products

  • Potential confusion about boundaries - Users may not know which to use for certain scenarios

  • Duplicated patterns - Similar UI components and patterns need to be maintained in two places

  • Discovery challenge - Users might not realize both capabilities exist

  •