# UX review: old console vs first native UI (2026-09-29)

Reviewer: Bernd. Recorded by Claude. Compared `security-bootstrap-console`
(NetKingdom, `:8876`) with the first `rtut ui` (`:8877`) on the NetKingdom packs.

## The comparison is unequal

The old console is more accessible and more professional on first impression, and
it models a far more complicated procedure. Each of its stages is about the size
of one of the new example runbooks. The new UI was built for flat sequences and
looks like a config form with comments as content. Design polish (spacing, dark
mode, visual guidance) is a renderer job. **The specification must not be
complicated to enable eye-candy**; a clear specification should render well.

## Findings

| # | Finding | Consequence |
| --- | --- | --- |
| 1 | The new flows are the basic element only: simple sequences with no hierarchy, no alternatives. The old console's stages give progress feedback and structure | The spec needs stages, hierarchy, alternatives and parallelism |
| 2 | Two different states are needed: `nil/set/err/ok` is about **setting the parameter** (a datapoint); `todo/running/done/failed` is about **applying** it (a step) | Datapoints get their own state, separate from step state |
| 3 | Next-action guidance is necessary. Several actions may be available once their prerequisites are met, but exactly one is *recommended* | The pack captures parallelism; a canonical, optional serialization gives a single operator one path |
| 4 | An overview with very clear state transparency, in several views by dimension (from canon standards where available), is a core feature. Hierarchical organization of complex runbooks is how orientation and learning happen | Overview and hierarchy are first-class |
| 5 | The pack must define and explain actors, roles, privileges; otherwise nothing says what is relevant | Actors and roles are part of the pack |
| 6 | Showing what a run produced and where it lives is what makes the UI more valuable than a wizard, script or config files | Artefacts (non-secret references) are part of the pack |
| 7 | Both confirmation styles are needed: a confirm button for reversible actions, a typed phrase for irreversible ones | Derive the style from reversibility; default confirm |
| 8 | Layout: the new UI is unpolished and gives too little visual guidance | Renderer work, after the spec |
| 9 | **Two views, two use cases.** A serial guided questionnaire is the main interface. A dimension/tag organized, random-access view of the collected datapoints is a second interface, independent of the flow. In the old console the two are intermingled | Separate the flow from the data view |
| 10 | Gates are not clearly tied to stages or to quality-assurance goals in the old console, and gates are missing from the new UI entirely | QA gates become a first-class concept, attached to stages and goals |
| 11 | Threat checks in the footer are misplaced: they are framing to keep in mind, not a final gate to pass | Show framing at the start; keep gates separate |

## Usability defects in the first UI (to fix in the renderer)

- Ticking the manual confirm box shows "passed" but the step stays `running`
  until "Mark done" is pressed. Unticking then changes nothing. The
  check, record and lock-in cycle is not visible.
- Steps after the first show no Start button and no reason. A blocked step must
  say what it is waiting for.
- The good part, to keep: parameter form, then a run view with copy command,
  run in terminal, feedback, confirm.

## Later extension (noted, not scheduled)

Operator feedback on a step feeds a runbook-aware assistant that may diagnose
the deployment, giving a feedback, retry, feedback, confirm loop.