Primoro Task Manager

Master Design Brief – Work Packages, Checklists & Shared Accountability

Audience: Product / UX / UI Designers

Related Specs: Task Manager – Technical Specification v2.2 · Features – Task Manager v1.0

1. Purpose of this Brief

This document defines how work packages, tasks, and checklists should be presented visually across Primoro (tablet, mobile, and web) — using real operational examples from live dental workflows.

The goal is to ensure designers clearly understand:

What a work package is (and is not)

How shared / role‑based execution works

How individual accountability is preserved

What should be visible at point of work vs management views

This is a single source of truth for Task Manager execution UX.

2. Core Design Principles (Non‑Negotiable)

Designs must support the following platform rules:

2.1 Calendar‑Backed Work

Every task and work package represents real scheduled work

Nothing is a “floating” to‑do

Time windows matter

2.2 Role‑First Ownership, Individual Accountability

Tasks and work packages may be owned by a role (e.g. Front Desk)

Every action is attributed to a named user

Shared responsibility ≠ anonymous execution

2.3 Tablet‑First Execution

The primary execution surface is tablets (surgery, decon, reception)

UI must be fast, glanceable, low‑friction

No dense admin UI at point of work

2.4 Audit‑Ready by Default

Who did what, and when, must always be recoverable

Attribution should feel natural, not bureaucratic

3. Key Concepts (Designer Glossary)

Task

A single unit of operational work.

Has one owner (user or role)

Has a lifecycle (Created → In Progress → Completed)

May contain a checklist

Checklist

Execution evidence within a task.

Multiple tickable items

Each item is attributable

May capture notes or attachments

Work Package

A planned operational playbook.

Contains one or more tasks

Delivered as a single block of work

Often recurring (daily / weekly)

Examples: Opening checks, Decon routines, Diary reviews.

4. Work Package UX Model (High Level)

A work package consists of:

Package header (what block of work this is)

One or more tasks within it

Checklists inside tasks

Completion state and attribution

Design intent:

Users focus on doing, not managing

Structure is visible but lightweight

5. Shared Execution & Accountability (Critical Section)

5.1 The Problem to Solve

Many operational tasks are shared:

“Front Desk”

“Diary Team”

“Decon Team”

But regulation and good management require knowing:

Who actually did the work

Not just which team owned it

5.2 Canonical Solution

✅ Role‑based ownership for planning & visibility

✅ Individual attribution for execution & audit

5.3 Checklist Item Attribution (Point of Work)

When a checklist item is ticked:

The system records the user

The UI shows user initials next to the item

Design example (tablet / mobile):

Design notes:

Initials only (to reduce clutter)

Timestamp available on tap / long‑press

This applies only once completed

5.4 Task Completion Attribution

When a task is completed:

Show Completed by: Full Name

Show completion time

Example:

✅ Task completed by Sarah Grant at 17:42

This is immutable.

5.5 Work Package Summary (Web / Management Views)

In web portal views, show execution clarity without exposing checklist noise.

Example table layout:

6. Real‑World Work Package Examples (Canonical)

6.1 Diary Team Checks (Daily)

Role Owner: Front Desk / Diary Team

Time Window: Daily

Tasks:

Previous Day Review

Next 48–72 Hours Diary Review

Checklist behaviours:

Multiple users may complete different items

Initials shown per item

Task completion shows final responsible user

6.2 On Arrival Checklist (Daily – Opening)

Role Owner: Front Desk

Execution Surface: Reception tablet

Single task with checklist:

Open blinds

Unlock doors

Systems on

Waiting room ready

Design intent:

Extremely fast

No names until items are completed

6.3 Decontamination Checklist (Weekly)

Role Owner: Decon Team

Execution Surface: Decon wall tablet

Checklist with compliance importance:

Each checklist item shows initials

Optional photo evidence

Weekly recurrence generates new instance

7. Surface‑Specific Expectations

Tablets (Reception / Decon / Surgery)

Checklist‑first

Initials next to completed items

Minimal chrome

Clear completion state

Mobile (Staff App)

Personal + role queues

Same attribution rules

Optimised for quick actions

Web Portal

Planning, review, audit

Names over initials

Aggregated views

8. Explicit Anti‑Patterns (Do Not Design)

⛔ Anonymous checklist tick‑offs

⛔ Role names shown as executors

⛔ Task completion without user attribution

⛔ Overly verbose audit UI at point of work

⛔ Separate “audit screens” for basic accountability

9. Mental Model for Designers

Think aviation or hospital checklists, not Trello:

Structured

Accountable

Calm

Designed for the real world

If designed correctly:

Staff feel supported, not monitored. Managers feel informed, not blind. Auditors see order, not chaos.

10. Final Note

This brief intentionally uses real operational examples. Designs should reflect reality, not abstract task theory.

If a screen does not clearly answer:

“What work is this, who is responsible, and who actually did it?”

…it is not finished.

| 1 ☑ Check lab work status — HL 2 ☑ Deposits taken — SG 3 ☑ Missed payments reviewed — JL 4 |

| Task | Role Owner | Completed By | Checklist | | Opening Checks | Front Desk | SG | 12/12 | | Diary Review | Diary Team | JL | 8/9 | | Cashing Up | Front Desk | SG | 4/4 |