# UX at KB Signaling · full page mockup

**Interactive page now available:** [ux.html](../ux.html) · [presenter guide and verification](ux-page-guide.md). The boards below remain the earlier layout concepts.

[Board 1: the story and ketchup test](reference/ux-kb-story-mockup.png) · [Board 2: RailLens through the build challenge](reference/ux-kb-raillens-mockup.png).

These generated boards show one connected page at two scroll positions. They are layout/content proposals, not working controls, researched product requirements or authoritative component styles. Build with the actual KB library and approved brand assets; do not sample component values from these images. The existing design-system landing page is unchanged.

## Experience and content

| Step | Page content | Proposed audience interaction |
|---|---|---|
| 01 · What is UX? | The experience people have while trying to accomplish something. Examples: find the right asset, understand what matters, know what to do next. | Discuss: what tool makes your work harder than it should? |
| 02 · The ketchup test | Large classic glass bottle and cap-down squeeze bottle. Same goal: get ketchup onto food. Compare grip, effort, waiting, dispensing control and cleanup. | Invite a choice and reasons; reveal the UI/UX explanation, then ask where our products make people “shake the bottle.” |
| 03 · When to do UX | Five entry points: new product, new feature, feedback, issue, problem. UX continues after release. | Selecting an entry point reveals a KB-relevant research question; it is not a gated linear workflow. |
| 04 · The UX process | Understand → Define → Explore → Prototype → Test → Learn, with a clear return loop. | Reveal the question and output of each stage. The loop accommodates new evidence. |
| 05 · Meet RailLens | Fictional information companion for preparing a site visit, understanding context and recording findings. Optional AR concept image. It does not control signaling equipment. | Introduce the unfamiliar-site assignment; ask what we need to learn before designing. |
| 06 · Users, goals & journeys | Hypothesized field technician, maintenance coordinator and engineering specialist. Begin with the technician goal: prepare and record a clear handoff. Journey: assignment, prepare, locate, inspect, document, support, handoff. | Select a role/stage; reveal needs, friction and research questions. Introduce poor connectivity, gloves, sunlight or an unfamiliar site as a constraint. |
| 07 · Explore, prototype & test | Compare rough asset-dashboard and visit-workspace approaches before polish. Task: find the assignment, identify missing preparation information and record a finding. | Audience chooses an approach and explains the reasoning; label it discussion preference, not validation. Define completion, wrong turns, requests for help and next-step clarity. |
| 08 · Bring in the design system | User goal → journey → screen structure → shared components. Assignment/cards, findings/fields, next steps/actions, supporting detail/dialogs. | Inspect or open the real accepted component examples. The system supports UX; it does not replace research. |
| 09 · Build together | Optional Visual Studio/coding-assistant challenge using the actual KB skill, a narrow brief and fictional data. Prototype preview is explicitly proposed. | Copy a prepared prompt, build one screen if time permits, then evaluate it against the task. Keep a working fallback ready. |

## Exact ketchup reveal

**UI:** the interface someone interacts with—its controls, labels, visual hierarchy and feedback. In this physical analogy, bottle shape, grip, cap and opening contribute to the interaction.

**UX:** the broader experience of accomplishing the goal, in context—getting the right amount onto the food with reasonable effort, control and cleanup.

**Both bottles have UI and UX.** Do not label the glass bottle “UI” and the squeeze bottle “UX.” The cap-down design changes trade-offs; it is not universally superior for every user/context. Use the example to ask about tasks and evidence, not to certify a design from a popularity vote.

Transition: “What is the equivalent of shaking the bottle in our tools?”

## RailLens assumptions

The users, scenario, site labels, journeys and AR product illustration are invented teaching material. Treat them as hypotheses to investigate. The page must not imply actual KB product capabilities, validated field procedures, live asset data or safety decisions. A future UI demo uses local fictional state and clear feedback; no real device actions are needed.

Selecting poor connectivity can introduce questions about information freshness, preparation downloads and pending work. Do not present offline reliability/synchronization as implemented just because a status badge exists. Likewise, gloves/sunlight prompts raise design/testing needs; an illustration is not evidence of field usability.

## Presenter and responsive behavior

- Standard mode: retained KB header/sidebar, meaningful anchors and normal scrolling. Nine story steps are visibly grouped into introduction and exercise.
- Presenter mode proposal: reduce shell clutter, show one story step at a time with Previous/Next and an explicit Exit presenter mode control. Support keyboard navigation while avoiding interference with typing or native controls.
- Keep reveals operable with native buttons, aria-expanded and a useful focus order. Choices need semantic selection states, not color alone.
- Mobile: collapsed sidebar; stack bottle and persona cards; use horizontally scrollable or stacked journey stages with clear labels; keep a single-column task form.
- Use actual theme/component sources for dark mode, dimensions, fonts, borders and controls. These boards show the light desktop story, not verified dark/mobile states.
- The session can finish without the live coding stretch. Show the closing reflection either way: “What did we need to understand before we were ready to build?”

## Next implementation slice

Create a separate ux.html page, leaving index.html intact, with the educational story and native reveals first. Add persona/journey/constraint exploration second. Link to the accepted design-system examples third. Presenter mode and the coding demonstration follow after the core story is usable. Verify both themes, keyboard/reveal behavior, mobile layout, local assets and honest prototype labels before presentation.

[Starter build prompt](raillens-starter-prompt.md). No application implementation or publication occurred in this mockup run.