Designing a Palette Business Users Can Actually Use

The hardest interface in any self-service workflow tool is not the canvas. It is the small list of things a user can drag onto it.

Get that list wrong and everything downstream fails quietly: people build the wrong shape of process, or they build nothing at all and file a ticket instead. The palette is where a business user decides whether this tool is for them.

Two ways to get it wrong

The first failure is modelling completeness. BPMN 2.0 has a rich vocabulary — inclusive gateways, boundary events, event sub-processes, compensation. Exposing all of it is defensible on the grounds that it is standard and expressive. It is also how you produce a palette with forty entries, which a business-unit administrator will read as a signal that this tool is for someone else. They came to add an approval step, and they are being asked to distinguish an inclusive gateway from a complex one.

The second failure is over-simplification. Reduce it to five friendly boxes and you get a palette that cannot express a real process. The first time someone needs two approvals in parallel and finds no way to say it, they stop using the tool. Worse, they build a wrong-but-expressible approximation, and now the system contains a process that does not match the business.

The target is a vocabulary small enough to scan and complete enough for the processes people actually have — a much narrower set than BPMN was designed to cover.

Choosing the vocabulary

The useful discipline is to derive the palette from real processes rather than from the specification. Take twenty workflows the organisation genuinely runs and ask what shapes are needed to express them.

In practice, for internal business processes, the answer converges quickly: a start and an end, a decision, a parallel split and join, a timer, and a set of task types — receive data, extract from a document, transform data, call an external system, request an approval, ask a human to fill a form, run an audit check, send a notification.

Notice what is absent. No inclusive gateways: nobody asked for them, their semantics are hard to explain and harder to debug. No compensation: the processes that need it are not the ones being built self-service. A construct earns its place by appearing in real processes, not by existing in the standard.

Presenting it

We shipped an icon grid first. It was compact and it tested badly, for a reason obvious in hindsight: a two-column tile layout caps how long a label can be, so Extract from document becomes Extract, and Extract does not tell a business user what the step does. Compactness had been bought with the only thing that made the palette legible.

What replaced it was less clever and works better: single-line rows, around 38 pixels tall, each with a small coloured icon chip, a full-length label, and a drag handle. Rows sit inside two soft group cards — Structure for the graph constructs, Tasks for everything that does work.

Three details did most of the work.

Full labels, always. If a label needs a tooltip to be understood, the label is wrong. Tooltips carry the longer description — the sentence explaining what the step does and when to use it — but the row itself is comprehensible without hovering.

Two groups, not eight. An earlier version grouped tasks by category: extraction, integration, audit, human. With eight task types that produced more group headers than items per group, and the categories were more meaningful to us than to the user. One Tasks group with a colour-coded icon per category carries the same information without fragmenting the list.

A search field above the list. Trivial to build, and it changes how the palette scales. It also quietly tells you what users expect to exist: search terms that return nothing are a feature request list.

The canvas has to feel good

A palette is only half the interaction. If dragging an item onto the canvas is fiddly, the vocabulary does not matter.

Two things mattered more than expected. Alignment guides with snapping — the light lines that appear when a node lines up with another, and the small pull that makes it click into place. Without them, users spend real effort nudging boxes and produce diagrams that look untidy, which they read as their own failure. With them, everything looks deliberate.

One implementation detail is worth knowing: apply the snap in the node-change handler rather than during the drag event. React Flow emits a final unsnapped position before drag-stop, so snapping during the drag gets silently undone at the last frame.

The second is orthogonal return edges. Loops back to an earlier step are common — rejected, wait, resubmit — and rendered as bezier curves they slash diagonally across the diagram, colliding with labels and making the graph look broken. Routing them as right angles through a horizontal lane below the graph, with a draggable grip to move the lane, keeps the loop readable without inviting anyone to hand-route every edge into spaghetti.

The test

The measure of a palette is not how much it can express. It is whether someone who has never seen it can build a correct three-step approval flow without being taught.

Everything else — the vocabulary, the grouping, the labels, the snapping — is in service of that. If they hesitate, the palette is asking them a question they should not have to answer.

Naming is most of the work

Once the vocabulary is settled, the single highest-leverage thing left is what each item is called. Labels are the entire interface for a business user; everything else is decoration.

Three rules survived contact with real users.

Name the outcome, not the mechanism. Call external system beats REST connector. The user knows they need to get something from another system; they do not know or care that it happens over HTTP. Mechanism names feel more precise to engineers and are simply opaque to everyone else.

Use the verb the business uses. If the organisation says “sign-off”, the label is Sign-off, not Approval. This feels like a triviality and is not: a user scanning for the thing they need matches on their own vocabulary, and a near-miss costs them a full read of the list.

Never let two items differ only by a qualifier. Parallel split and Parallel join are fine because they are genuinely a pair and users learn them together. Data extraction and Advanced data extraction are not, because the user has no way to tell which one their case needs, and the cost of guessing wrong is discovered much later.

The empty state is a design surface

A new flow opens on an empty canvas, and that moment decides whether the user proceeds or closes the tab.

An empty canvas with a palette beside it is a competence test. The user does not know whether to start with Start, whether the graph flows left to right, or how many steps is normal. Everything they need to know is discoverable, and discovery costs confidence they may not have.

Two things fixed most of this. A pre-placed Start node, so the canvas is never truly empty and the direction of flow is implied by its handle. And a one-line instruction under the palette — drag an item onto the canvas, or ask the assistant to build it for you — which is the cheapest onboarding available and removes the two most common first questions.

The related discipline: a seeded example flow. Not a tutorial, an actual flow they can open, inspect and copy. Users learn the vocabulary far faster from one worked example than from any documentation, because the example answers the question they actually have, which is what does a normal one look like?

Errors that teach

Validation messages are where a self-service tool either earns trust or generates tickets, and the difference is almost entirely in the writing.

A message must do three things: name the specific node, describe the problem in the user’s vocabulary, and take them to it. “Manager approval has no assignee” with a click that selects and centres that node beats “Validation error: node.config.assignee is required” so completely that they are not really the same feature.

The subtler rule is to state the problem, not the schema. Users do not have a mental model of the config contract; they have a mental model of the process. “This decision has no default branch, so a case matching none of the conditions would have nowhere to go” teaches the semantics in the moment they are relevant. The schema path teaches nothing.

What we would test differently next time

The icon-grid palette failed a usability test, which is the cheap way to find out. Two things we did not test early enough:

Whether users could read a flow someone else built. We optimised for authoring and assumed reading was easier. It is not. Reading requires inferring intent from structure, and a graph that was obvious to its author is frequently opaque to a colleague. Per-node descriptions and a readable summary view matter more than we assumed.

Whether users could find an existing flow to copy. In practice, copying is the dominant creation path — almost nobody starts from empty when a similar flow exists. That makes the flow list, not the canvas, the real entry point, and it deserved the design attention we spent on the palette.

EFTEDRA builds workflow automation on IBM Business Automation Workflow and Claude — assistant tasks and coach views that install into the processes you already run. See what we build, or try the live demo.