Workflow Sandbox

Edit the stages on the left. Give each stage one reviewer or several, and decide whether any reviewer or all of them must approve. Then run the sample submission and act as each reviewer — every transition explains itself in the activity log.

Illustrative personal experiment — intended benefits are marked as such, not as measured results.

1. 01

   The problem

   Approval processes are everywhere in enterprise products: publishing, procurement, pricing changes, content, releases. Most of them are described in a wiki page and understood differently by everyone who touches them.

   Two questions cause most of the friction. First, when a stage has more than one reviewer, does the work move forward when *any* of them approves, or only when *all* of them do? Second, when someone asks for changes, where exactly does the submission go back to, and who owns getting it moving again?

   The people who feel this are the submitter waiting without a status, the reviewer who is not sure the decision is theirs to make, and the PM who owns the process but cannot see where it stalls.

2. 02

   The hypothesis

   If someone can build an approval flow in under a minute and then watch one submission move through it — with a plain-language reason for every transition — the effect of "any vs all" and "one vs many reviewers" becomes obvious by seeing it, not by arguing about it in a meeting.

3. 03

   The scope

   In the first version: add, rename, reorder, and remove stages; set each stage to one reviewer or several; choose whether any or all reviewers must approve; run one sample submission; approve, reject, or request changes at each stage; a visible reason for every transition; reset to the example; and export the configuration as JSON.

   Deliberately deferred: parallel stages, conditional routing ("skip legal under $10k"), real users and roles, SLAs and timeouts, notifications, more than one submission in flight, and any persistence beyond this browser. Each of those is a real feature — none of them is needed to make the core rules legible.

4. 04

   The decisions

   Reorder with buttons, not drag-and-drop. Move-up / move-down is keyboard-accessible with no extra work and is perfectly adequate for three to six stages. Drag-and-drop would be a larger, less accessible build for a smaller gain.

   "Request changes" returns the submission to the previous stage, not to the start. This models the common "one step back" review and keeps the simulation short enough to follow. Returning to the author was the alternative — noted for the next iteration as a builder-selectable option.

   Local state only, no account and no backend. It keeps the experiment honest about what it is, and removes every barrier to trying it.

   One sample submission rather than a queue. The subject of this tool is the *rules*, not throughput. A queue would add realism and distract from the point.

5. 05

   The design

   Two panels: a builder and a runner, side by side on desktop and stacked on smaller screens. Between them sits a flow strip — the shared object both panels point at, with the current stage marked and cleared stages checked.

   Every action writes one plain sentence to an activity log: "Stage cleared — all 2 reviewers approved", "Returned to Brand review — changes requested by Alex", "Workflow rejected by Sam at Legal review". The reasoning is never hidden inside a state diagram.

   The current-stage panel only ever offers the actions that are actually available, and names the reviewers still pending, so the "what happens next" is always on screen.

6. 06

   The implementation

   An Astro component with no UI framework. The logic is vanilla TypeScript in a single module script. State is one plain object; a `render()` function redraws the DOM from it after every change. The stage-to-stage connectors are SVG paths recomputed from `getBoundingClientRect()` on each render and through a `ResizeObserver`, so they track the layout at any width.

   The workflow configuration is saved to `localStorage` under `issnij:lab:workflow-sandbox:v1` on every edit and restored on load; the run itself (whose turn, which decisions) is kept in memory only, so a refresh returns you to a clean run of your saved workflow. Export builds a JSON object and triggers a file download; a copy-to-clipboard fallback is offered alongside it.

   Reduced-motion preference removes the node transitions and the connector redraw animation. Every control is a native button, input, or select; the transition reason is announced through an `aria-live` region and focus moves to the current-stage heading when the stage changes.

7. 07

   The validation

   Tested by hand: the state machine across single / multi reviewers and any / all rules; the three decisions at each stage; reordering and removing stages mid-run; the empty state with no stages; export and reset; and the reduced-motion path.

   Still uncertain: a full screen-reader walkthrough (the announcements are wired but not audited end to end), very large workflows, and right-to-left layout.

   What I would measure with real users: whether someone can correctly predict the outcome of an "all reviewers" stage before running it; time to build a three-stage flow from scratch; and whether the activity log actually gets read or just scrolled past.

8. 08

   The next iteration

   Add "return to author" as a second route for requested changes, and let the builder choose per stage.

   Add one conditional rule to a stage ("skip when amount is under a threshold") to show how routing logic changes the picture.

   Run two submissions at once so the practical difference between "any" and "all" is visible under load, not just in theory.

9. 09

   My role & AI assistance

   Concept, product decisions, scope, interaction design, and copy are mine. I used AI assistance (Claude) to scaffold the component and implement the state machine; I reviewed and adjusted the behaviour and wrote the content. This is an illustrative personal experiment, not a client deliverable.