NL
All work
03

Unified Picker

One content-selection system replacing six inconsistent pickers across Flow Designer and Playbook Automation Designer. Shipped as a reusable component, then audited to confirm it held.

Design lead Flow Designer & Playbook Automation Designer Research fielded 19 Aug 2025 with Yifan Deng, Riya Kapoor

Customer problem

Six places in Workflow Automation ask a user to pick content, and six different pickers had grown to serve them. Before proposing anything unified, I audited what each one actually contained. The inconsistency that surfaced is the argument for the whole project.

Field-by-field audit of the six existing pickers
PickerFields present
TriggerCategory (record / scheduled / application), Application, Name, Description
ActionsRecent/Popular, Installed/Uninstalled, Application, Name, Category as an unlabelled grey divider bar, Description
LogicCategory (always empty), Application (always global), Name, Description (only visible in diagram view)
SubflowApplication, Flow type, Category (not used: shows only “default”, source unknown)
StepsCategory (ServiceNow Data / Utilities / Integrations), Name, Description
ActivitiesApplication, Category (interactive / non-interactive), Name, Description, Create new

That fourth row is worth keeping honest. The audit could not fully explain the existing Subflow picker’s behaviour, and said so rather than assuming the legacy logic made sense.

On top of the structural mess, users reported concrete damage:

  • Action names truncated.
  • Current designs considered too sparse, with low information density.
  • The picker is not big enough.
  • Search defaulting to recent selections, which was actively causing mis-selections.

The brief

Establish UX consistency of selecting content for Workflow Automation products, while enabling future integration for proactive content recommendations.

This is not a feature. It is a design-system consolidation across Triggers, Actions, Logic, Subflows, Steps and Activities, spanning two products.

Personas

Three named professionals were interviewed. The most valuable finding was not a consensus. It was a genuine disagreement about how far to lean into AI, and resolving it without picking a side became the spine of the design.

Experienced developer

Eric Riemer, Product Excellence
Needs
Density, full names, and basics that don’t regress while attention goes to AI.
Position
AI-first approaches might not work for all customers, especially experienced developers.

Implementation architect

Shamma Negi, Accenture
Needs
Natural-language search; results that are current rather than cached-stale.
Gap
Search defaulting to recent selections was producing wrong picks.

Non-technical builder

via Laszlo Balla, Developer Advocacy
Needs
To describe intent in plain language instead of knowing which spoke to look in.
Wants next
Conversational editing and generating new actions on the fly.

Instance admin

Governance
Needs
To decide whether AI search is switched on for their instance at all.
Gap
A feature silently hidden from non-admins never gets adopted.

Solution

  1. Four principles the whole component is built on. Groups: content organised by a defined value like Application, or a determined one like Recommended, Recent and Favourites. Details: a description shown on demand, per item. Create: a role-gated shortcut to make new content of the selected type inline. Switch: change content type mid-selection where that is contextually relevant.
  2. The AI disagreement resolved by not forcing a single answer. The detail pane stays closed behind an “i” rather than being permanently open or permanently gone. Global search returns a flat, capped list with “View all” instead of an AI-only experience. AI is additive; it is never the only path to a result.
  3. Role-based AI rollout that invites rather than hides. Admins activate AI search; non-admins get an awareness modal prompting them to enable it. Nobody has AI forced on them, and nobody is left unaware the capability exists. That is a direct answer to the alienation concern.
  4. Two-pane per-artifact results with a manual refresh. Engineering validated it as feasible without a performance hit, and it answers the stale-results complaint directly.
  5. Sizing that hugs content with a max width, answering “the picker is not big enough” without letting it sprawl. Favourites and custom categories merged into one experience rather than separate tabs, per leadership review.
  6. A complete state permutation matrix, self-documented by filename. Six axes multiply out: type, AI search, sidebar mode, results layout, info panel and fixed summary. Every state in the prop spec exists as a rendered screen, not just a schema on paper.
  7. Shipped as a genuinely reusable component, not a screen: a full prop API (config, quickActionTabsContent, artifactToLabelMap, itemActions, searchResults, isSingleEntity, aisConfig), an event-dispatch contract, and two production instances: triggers-picker for single-entity and actions-picker for multi-entity.

The state permutation matrix

Forty-two rendered states, self-documented by filename: Type × AI search × sidebar mode × results layout × info panel × fixed summary. Eleven of them are below, ordered so that one variable changes at a time — which is what the matrix was for.

Every state named in the prop spec exists here as a rendered screen. That is what turned this from a set of mockups into a contract engineering could build against.

Frame 1 of 11 — Multi-entity, AI search off, Quick access, no results, no info panel. The default a flow author meets: Recommendations / Popular / Rec Frame 2 of 11 — One variable moves — the info panel opens. It is closed by default and lives behind an “i”, which is the middle ground between wanting Frame 3 of 11 — Info panel back off, fixed summary on. A persistent strip for what has been selected, independent of everything else. Frame 4 of 11 — Quick access → Browse. Same component, different left rail: browsing by application and category rather than by recency and popularity Frame 5 of 11 — Results arrive as a flat single pane with a cap and “View all”. This is the deliberate non-AI fallback — the answer to “AI-first appro Frame 6 of 11 — Same search, double pane: results split per artefact type. Engineering confirmed this was feasible without a performance hit, with a m Frame 7 of 11 — Double-pane results with the info panel open — the densest state the component supports, and a direct answer to “current designs consi Frame 8 of 11 — AI search switched on. The natural-language prompt sits above the same Quick access structure rather than replacing it: additive, neve Frame 9 of 11 — AI search with double-pane results and details open. Every state in the prop spec exists as a rendered screen, which is what made this Frame 10 of 11 — The same component as <code>isSingleEntity={true}</code> — the production triggers-picker. One artefact type, so no type grouping, bu Frame 11 of 11 — Single-entity, AI off, browsing with results. Note the width across these frames: the picker hugs its content up to a max, which is w
01/11
Baseline Multi-entity, AI search off, Quick access, no results, no info panel. The default a flow author meets: Recommendations / Popular / Recent / Favourites, grouped by artefact type.

User flows

Browse the default path, no AI required
  1. Add a step
  2. Picker opens in Quick access
  3. Recommendations / Popular / Recent / Favourites
  4. Grouped by artefact type
  5. “i” for details
  6. Inserted on the canvas
Search in plain language where AI search is enabled
  1. Describe what you want to do
  2. Results, single or double pane
  3. Scoped by spoke
  4. Expand details
  5. Insert
Create inline role-gated
  1. Search a name
  2. No result
  3. Create action / Create subflow
  4. Action Designer
Switch content type mid-selection
  1. Picker open on Activity
  2. Switch
  3. Subflow
  4. Same picker, new type

KPIs

Measured 6 → 1

inconsistent pickers consolidated into a single component

Measured 2

production instances wired up from one component: triggers and actions

Measured 7 / 10

post-migration parity checks passed outright

Measured 0

new regressions; all 3 flagged items were pre-existing functional gaps

This is the only project here with a genuine post-implementation verification step. The parity audit, by Yifan Deng, confirmed that add-step entry points, picker categories, browsing, search and canvas insertion all held up. Two things were flagged: a missing collapsed “uninstalled spokes” section, and missing Create Action and Create Subflow paths on an empty search. Both were absent in the legacy UI too, so the audit recommended escalating them to PM and engineering rather than treating them as design defects.

Still open

  • Cross-product scoping. Raised by Brian Bimschleger, and not cosmetic. If a user creates a custom category in Flow Designer, does it appear in the Playbook picker? Is a custom category personal or shared? Are favourites per-builder or global? These are information architecture decisions about where personalisation lives.
  • The flagged parity gaps. Whether PM and engineering picked them up.
  • AI Prompt as a navigation item. Riya Kapoor explored making it top-level and pickable, on Jake Burman’s proposal. Outcome unknown.