UI guidelines that BPM human services (coaches) benefit from, distilled from portal-style task applications:
- One task, one screen, one primary action: the coach shows what the user must decide, the decision buttons are at the bottom right (primary style for the "happy" action, default for Save / Cancel), everything else is secondary. Multi-page only for genuine wizards.
- Read-only context first: request summary, customer, amounts on top (Output Text, not disabled inputs); editable fields below; attachments and history in collapsible sections or tabs.
- Layout: two-column responsive grid (labels on top on narrow screens), consistent widths, related fields grouped in Sections with titles, 12-column Bootstrap spacing from the toolkit - no pixel positioning.
- Validation: inline, immediate, next to the field (setValid), with a summary at the top for several errors; never only a modal; mark required fields.
- Feedback: busy indicator on every service call, success / error alerts that do not block, disable the submit button while processing.
- Tables: paged, sortable, with a filter box; inline edit only for simple values; row detail in a modal or master-detail.
- Language: labels in business terms, no field ids; consistent capitalisation; help text as tooltips (control help option), not paragraphs.
- Accessibility: keyboard order = visual order, labels bound to inputs (the toolkit does this), sufficient contrast, no colour-only signals (icon + text).
- Consistency across apps: a house style toolkit with header / footer views, variants for buttons and tables, one date format, one currency format (from the user's locale).
- Performance as UX: coaches under 1 s to first render (question 1405); load details on demand.
Process-level: task subjects that say what to do ("Approve order 4711 for Acme"), due dates visible in the task list, and instructions in the task narrative rather than in the coach.
References