Primoro MVP — Web vs Tablet vs Mobile

Module‑by‑Module UI / UX Comparison

1️⃣ Task Manager (highest surface divergence)

Why this matters for design

Web must handle complexity without overwhelm (planner‑grade UI)

Tablet must strip this down to binary execution

Mobile must feel like “what do I need to do now?”

This split is explicitly required because Task Manager is the calendar‑backed system of record, while execution context varies dramatically by device %20v1.0.docx&action=default&mobileredirect=true&DefaultItemOpen=1)

2️⃣ Communication Hub

Why

Communication Hub is not chat — it is a work generator

Designing it for tablets would violate the “no shared inbox” principle

Mobile is intentionally lightweight: respond, don’t manage

3️⃣ Appointment Manager

Why

Booking authority lives in web

Tablets are not booking tools — they are execution surfaces

Mobile booking must never expose raw diary complexity

/MVP/Task%20Manager%20%E2%80%93%20Technical%20Specification%20v2.2.docx)

4️⃣ Surgery & Decon Day View (tablet‑first module)

Why

This module exists explicitly for shared, wall‑mounted and in‑surgery tablets

Mandatory tooth‑level context, auditability, and shared‑device security make mobile inappropriate

%20v1.0.docx&action=default&mobileredirect=true&DefaultItemOpen=1)

5️⃣ Staff App Mode (mobile‑first)

Why

This explicitly replaces WhatsApp

Must respect rota‑aware quiet hours and personal device boundaries

Design must feel calm and utility‑driven, not social

%20v1.0.docx&action=default&mobileredirect=true&DefaultItemOpen=1)

6️⃣ Digital Forms

Why

Same module, three different mental models

Tablet ≠ management

Mobile ≠ document viewer (must feel native, not PDF‑like)

7️⃣ Aftercare Manager

Why

Aftercare is patient‑first

Staff mostly monitor exceptions

Tablet triggers, but should not manage content

/MVP/Surgery%20%26%20Decon%20Day%20View%20%E2%80%93%20Technical%20Specification%20v2.0.docx)

8️⃣ Smart Dashboards

Why

Dashboards are not reports

Mobile must summarise, not visualise deeply

%20v1.0.docx&action=default&mobileredirect=true&DefaultItemOpen=1)

9️⃣ Document Hub

Why

Governance lives on web

Tablets expose reference docs only

Patients access only their documents

🔟 Family Profiles

1️⃣1️⃣ Access Manager & Security (invisible, everywhere)

/MVP/Staff%20App%20Mode%20%E2%80%93%20Technical%20Specification%20v2.0.docx)%20v1.0.docx&action=default&mobileredirect=true&DefaultItemOpen=1)

🔑 Designer Summary (for handover)

Big design effort areas

Task Manager (web complexity vs mobile simplicity)

Communication Hub (actions inside conversations)

Appointment Manager (rules without clutter)

Surgery & Decon Day View (tablet‑first, zero noise)

Key principle to design around

🔹 Same modules, very different mental models per surfaceWeb = governanceTablet = executionMobile = guidance + response

If you want next, I can:

Turn this into a single-page matrix PDF for designers

Produce wireframe guardrails per surface

Highlight anti‑patterns (what not to design on each device)

Just say the word.

| Surface | Exists? | UX Role | Design Notes | | Web | ✅ Full | Primary operating surface | Multi‑view (list / board / calendar‑linked), work packages, checklists, evidence, templates | | Tablet | ⚠️ Limited | Execution only | Task completion only (no planning, no board views) | | Mobile (Staff App) | ✅ Focused | Personal work | My tasks, quick complete, reminders, no structural editing |

| Surface | Exists? | UX Role | Design Notes | | Web | ✅ Full | Work orchestration | Threads + inline actions (create task, callback, appointment) | | Tablet | ❌ No | — | Avoids clutter on shared clinical devices | | Mobile (Staff App) | ✅ Core | Notifications + response | Reply, acknowledge, act — not manage |

| Surface | Exists? | UX Role | Design Notes | | Web | ✅ Full | Governance + booking | Rules, constraints, audit visibility | | Tablet | ⚠️ Context‑only | Awareness | View today’s appointments, no booking | | Mobile (Patient App) | ✅ Guided | Self‑service | Booking flows via AI‑guided, constrained UI |

| Surface | Exists? | UX Role | Design Notes | | Web | ⚠️ Limited | Oversight | Read‑only operational view | | Tablet | ✅ Primary | Real‑time ops | Large touch targets, zero navigation depth | | Mobile | ❌ No | — | Unsafe and unnecessary |

| Surface | Exists? | UX Role | Design Notes | | Web | ⚠️ Minimal | Admin/support | Secondary surface | | Tablet | ❌ No | — | Tablets are operational, not personal | | Mobile | ✅ Full | Daily staff experience | Tasks, messages, rotas, requests |

| Surface | Exists? | UX Role | Design Notes | | Web | ✅ Full | Authoring + review | Template building, completeness checks | | Tablet | ✅ In‑flow | Chairside completion | One form at a time, no browsing | | Mobile (Patient App) | ✅ Primary | Completion | Guided, resumable, readable |

| Surface | Exists? | UX Role | Design Notes | | Web | ✅ Oversight | Monitoring | Escalations, audit | | Tablet | ⚠️ Trigger‑only | Completion | Aftercare sent on appointment completion | | Mobile (Patient App) | ✅ Primary | Ongoing care | Readable, reassuring, re‑accessible |

| Surface | Exists? | UX Role | Design Notes | | Web | ✅ Primary | Operational overview | Exceptions, risks, today/this week | | Tablet | ❌ No | — | Redundant with Surgery Day View | | Mobile (Staff App) | ✅ Lite | Glance | “What needs attention?” |

| Surface | Exists? | UX Role | Design Notes | | Web | ✅ Full | Source of truth | Ingestion, governance | | Tablet | ⚠️ Read‑only | Reference | View only, no uploads | | Mobile | ✅ Selected | Patient access | Download / view own docs |

| Surface | Exists? | UX Role | Design Notes | | Web | ✅ Full | Administration | Linking, permissions | | Tablet | ⚠️ Context | Awareness | “Who am I acting for?” indicator | | Mobile (Patient App) | ✅ Core | Carer actions | Switch person context |

| Surface | Exists? | UX Role | Design Notes | | Web | ✅ Foundational | Identity | Roles, permissions | | Tablet | ✅ Critical | Shared device security | Auto‑logout, attribution | | Mobile | ✅ Foundational | Trust | Silent, low friction |