Rosterix — Enterprise Workforce Decision System

01

Discover

Understand the workflow and evidence

The first discovery question was not “how should the roster look?” It was “where does a workforce decision lose context as it moves through the organisation?”

6

role perspectives modelled

9

AI opportunity areas identified in the strategy

4

cross-persona UX patterns

1

connected decision chain

Evidence base

What I used to understand the problem

SRS and HLD requirements, the Rosterix AI UX strategy, the UX research report, workforce scheduling research, AI trust patterns, enterprise UX considerations and accessibility requirements.

Research integrity

What the evidence does — and does not — claim

The research synthesises workflow friction across 6 core personas, business constraints, and live error logs before production rollout. It serves as an empirical foundation to safeguard user accountability rather than claiming unverified autonomy.

“Rosterix is a decision-making system where information becomes progressively fragmented as it moves through the organisation.”

01

Context arrives too late

Users often discover the information they need only after taking an action or receiving a rejection.

02

Memory lives in people

Recurring roster and tagging decisions rely heavily on personal knowledge and previous spreadsheets.

03

Problems surface downstream

Conflicts and payroll consequences can appear after the original workforce decision was made.

04

Trust must be earned

AI needs to propose and explain before it earns the right to automate higher-risk actions.

Role	Observed / modelled friction	UX implication
Project Manager	Rebuilds rosters and employee assignments from memory.	Reuse context and generate reviewable drafts.
Line Manager	Approval requests arrive without enough risk context.	Bring evidence and risk signals into approval.
HRBP	Institutional history lives outside the workflow.	Surface decision history at the point of review.
Regional Head	Final decisions can rely on second-hand summaries.	Progressive disclosure of relevant context.
HRSS Admin	Movements and backtagging can create downstream conflicts.	Preview ripple effects before commit.
Employee	Limited self-service visibility into shifts and allowance context.	Make outcomes understandable, not opaque.

02

Define

Frame the real decision-making problems

The problem was bigger than roster creation. Rosterix required users to reconstruct context, detect risk and justify decisions manually across a fragmented workflow.

Problem 01

Context fragmentation

Relevant information is distributed across projects, employee records, roster history, approvals and payroll-related workflows.

Problem 02

Delayed feedback

Business-rule violations and downstream conflicts can become visible only after a submission or later process step.

Problem 03

Untrusted automation

A recommendation without explanation creates uncertainty about accountability and makes consequential AI harder to adopt.

How might we

How might we help every Rosterix user make faster, safer and more informed workforce decisions by bringing the right context and risk signals into the moment of decision — while keeping humans accountable for consequential actions?

01 • Context before action

Give users the information they need before they commit.

02 • Risk before submission

Move validation upstream into the decision itself.

03 • AI proposes, humans decide

Keep consequential actions reviewable and reversible.

04 • Explain the why

Make recommendations inspectable rather than magical.

North Star: Move Rosterix from a system that records workforce decisions to a system that helps users make better workforce decisions.

03

Prioritize

Identify the highest-value / highest-risk opportunities

Prioritisation combined business impact, risk, workflow frequency and AI suitability. The matrix is a design synthesis, not a validated quantitative score.

Priority	Opportunity	Why it matters	AI role
P0	AI roster generation	High-frequency manual work with clear repeatable patterns.	Draft
P0	Real-time constraint validation	Prevents known business-rule failures before submission.	Validate
P0	Employee tagging recommendations	Reduces repetitive assignment work and surfaces conflicts.	Recommend
P0	Conflict detection / resolution	Protects downstream payroll and workforce integrity.	Explain
P0	Approval risk / context	Helps approvers focus attention without automating approval.	Prioritise
P1	Cost & allowance prediction	Connects workforce decisions to financial consequences.	Predict
P1	Anomaly detection	Moves organisation-wide monitoring beyond manual project checks.	Detect
P1	Smart project setup	Reuses patterns users currently reconstruct from memory.	Suggest
P2	Shift preference learning	Useful once foundational recommendation and feedback loops exist.	Learn

01PLAN

02ASSIGN

03BUILD

04VALIDATE

05PREDICT

06APPROVE

07LEARN

08AUDIT

09IMPROVE

04

Map

Connect projects, people, rosters, allowance, approvals and payroll

Mapping revealed that the roster is only one node in a much larger decision chain.

01PROJECT

02TAG

03EMPLOYEES

04ROSTER

05VALIDATION

06ALLOWANCE

07APPROVAL

08PAYROLL

09EXCEPTION / HISTORY

Journey 01 — Blank roster to paid allowance

Primary decision chain for Project Managers and Line Managers.

01

Plan

Project configuration is rebuilt from memory.

Smart setup

02

Tag

Employees are manually assigned and cross-checked.

Recommendations

03

Build

Roster patterns are recreated month after month.

Draft roster

04

Validate

Rules and conflicts need to be caught before submission.

Live validation

05

Approve

Requests need context, not just a button.

Risk context

06

Close loop

Decisions should remain traceable into allowance and payroll.

Explainable history

Journey 02 — Change a live project without breaking payroll

HRSS movement and backtagging workflow.

CHANGE→ PREVIEW IMPACT→ DETECT CONFLICTS→ UNDERSTAND WHY→ RESOLVE→ COMMIT

PM

Needs efficient project setup, tagging, roster creation and exception visibility.

LM / HRBP

Needs enough context to make responsible approval decisions quickly.

HRSS / Employee

Needs downstream consequences and workforce outcomes to remain understandable.

05

Explore

Generate interaction concepts

The concepts focused on embedding intelligence into existing decisions rather than creating a separate “AI product” inside Rosterix.

CONCEPT 01

AI

AI Roster Assistant

Generate a draft roster that users can inspect, edit and selectively accept.

CONCEPT 02

?

Explainability Layer

Expose summary, reason and evidence without overwhelming the primary workflow.

CONCEPT 03

✓

Real-time Validation

Move known constraints into the interaction instead of waiting for submission.

CONCEPT 04

!

Conflict Resolution

Surface overlapping tags and related impacts at the point of decision.

CONCEPT 05

↔

Simulation Mode

Preview downstream impact before committing movements and backtagging changes.

CONCEPT 06

R

Risk-aware Approval

Use context to direct attention without replacing human approval authority.

Core interaction model

AI SUGGESTS→ CONTEXT→ EXPLAIN WHY→ USER REVIEWS→ VALIDATE→ APPROVE→ AUDIT

Progressive automation

Inform → Recommend → Draft → Validate → Bounded automation

Autonomy should increase only as the product earns trust and accumulates evidence.

Trust pattern

Confidence is not permission

A confidence score tells the user where to look. It should never silently convert a recommendation into a decision.

06

Validate

Test assumptions and trust patterns

The riskiest concept was the AI Roster Assistant. Validation focused on accountability, explainability, conflict detection, override behaviour and dense-data comprehension.

01Hypothesis

Can users tell what AI decided?

02Prototype

Make the AI state visible.

03Review

Inspect trust and comprehension.

04Iterate

Expose the missing context.

05Retest

Confirm the interaction model.

V1 • Fully auto-filledREJECTED

M

T

W

T

F

Ravi

Asha

Dev

No distinction between AI and human decisions.

Rejected because accountability became ambiguous and users felt out of control.

V2 • Draft + warningITERATE

M

T

W

T

F

Ravi

!

Asha

Dev

!

The warning says something is wrong — but not why.

Distinguishing draft from final solved visibility, not explainability.

V3 • Explainable draftFINAL

M

T

W

T

F

Ravi

✓

Asha

✓

Dev

!

Why? Matches previous approved pattern + availability. Review conflict before accepting.

AI state + reason + override become first-class.

The interaction supports both fast bulk review and careful per-row inspection.

Validation integrity: The source research describes the primary research panel as synthetic/simulated because Rosterix 2.0 did not yet have a live user base. Real moderated interviews and usability testing remain required for production validation.

07

Design

Build the end-to-end experience

The final experience treats AI as a decision-support layer across the existing workflow, not as a standalone chatbot or hidden automation engine.

October roster • Night Ops AI draft • 92%

Employee

Mon

Tue

Wed

Thu

Fri

Sat

R. Kumar

Shift A

Valid ✓

Shift A

Off

A. Rao

Valid ✓

Shift B

Valid ✓

Shift B

D. Shah

Shift A

Conflict !

Shift A

Off

Shift A

Constraint Warning: D. Shah reaches 5 consecutive working days on Thursday. See why →

01 • Roster

AI draft + live validation

Suggested cells, validated states and conflicts remain visually distinct. Problems appear inline instead of blocking the whole workflow.

02 • Tagging

Recommendations + conflict signals

Each recommendation carries a one-line reason. Employees already tagged elsewhere surface before submission.

03 • Approvals

Risk context, not automated approval

Confidence helps approvers decide where to look first. It never replaces their authority.

Simulation

Before / after impact

Backtagging and movements show affected records and conflicts before commit.

Explainability

Summary → reason → evidence

The system answers “why?” without turning every decision into a long explanation.

Control

Accept → edit → reject

Users retain a clear path to override recommendations at any granular level.

08

Systemize

Turn successful patterns into reusable components

The challenge was consistency across multiple roles, modules and AI use cases. I treated AI interaction patterns as system primitives rather than feature-specific UI.

State model

SuggestedAI recommendation

ValidatedRule engine confirms constraints

Needs reviewHuman judgement required

ConflictRule / data relationship requires resolution

User editedHuman modified the recommendation

Reusable patterns

Confidence indicatorPercentage + label, never colour alone

Explainability tooltipReason on hover / focus / tap

AI Assistant PanelTask-focused, progressive disclosure

Violation bannerInline + reason + action

Status chipRule-engine state distinct from AI state

Design system principle

AI confidence and business-rule validation are different states and must never be represented as the same thing.

Ink

#172238
Primary information & text

AI accent

#7657D9
AI moments / suggestions

Validated

#19736A
Confirmed rule state

Alert

#A94335
Conflict / attention required

09

Handoff

Translate UX decisions into implementation rules

The handoff is designed around behaviour, not screenshots. Every important component needs a shared understanding of anatomy, state, behaviour, rules, accessibility and content.

Anatomy

What elements make up the component?

States

Default, loading, suggested, validated, conflict, edited, approved.

Behaviour

What happens on hover, focus, click, accept, reject and override?

Rules

Which business and validation rules affect the interaction?

Accessibility

Keyboard behaviour, focus, semantics, target size and non-colour states.

Content

Labels, reasons, error language, confidence framing and progressive disclosure.

Figma library

Components, variants, tokens and interaction states.

Behaviour spec

Interaction rules, edge cases and AI state transitions.

Acceptance criteria

Testable outcomes shared with engineering and QA.

10

Build

Partner with engineering and ML

Rosterix sits at the intersection of interface, business rules, workforce data, AI recommendations, approvals and payroll. Engineering collaboration therefore begins before visual handoff.

UX + Product

Define the decision

What decision is the system helping the user make, and what accountability must remain human?

UX + Engineering

Define the constraint

Which information can be surfaced in real time, and what happens when a dependency is unavailable?

UX + ML

Define the AI contract

Recommendation inputs, confidence, explanation data, uncertainty, fallback and override logging.

AI interaction contract

INPUT→ RECOMMENDATION→ CONFIDENCE→ EXPLANATION→ USER ACTION→ OUTCOME

Graceful degradation: If the AI service fails, the core Rosterix workflow should remain usable. AI should accelerate work, not become the only way to complete it.

11

QA

Validate functionality, UX, AI behaviour and accessibility

QA expands beyond pixel matching. The question is whether the product behaves predictably when workforce data, business rules and AI recommendations collide.

01

Functional

Does the workflow behave according to SRS requirements and business rules?

02

UX

Can users understand what happened, why, what needs attention and what happens next?

03

AI UX

Are recommendation, confidence, uncertainty and human override communicated correctly?

04

Accessibility

Can the same decision be completed with keyboard, assistive technology and non-colour cues?

Edge case	Expected UX behaviour
Overlapping employee tags	Surface conflict before submission and explain the affected relationship.
Backdated movement	Show before/after impact and affected records before commit.
Missing information	Identify what is missing and provide a clear recovery path.
AI has no valid solution	Explain the limitation and return control to manual decision-making.
AI recommendation rejected	Allow user override without breaking the workflow.
AI service unavailable	Core workflow remains usable without AI.
Dense roster interaction	Keyboard-accessible, visible focus, readable states and adequate target sizes.

12

Measure

Track behavioural and business outcomes

The current Rosterix materials describe projected outcomes and roadmap targets rather than measured production results. The measurement framework therefore separates targets from evidence.

Time to roster

Measure the time required to create and finalise a roster.

AI acceptance / edit / reject

Understand whether recommendations are genuinely useful or simply being accepted.

Pre-submission conflicts

Track how many conflicts are detected before they reach downstream workflows.

Approval turnaround

Measure the time from submission to authorised decision.

Downstream exceptions

Track payroll / allowance issues linked to upstream workforce decisions.

Explainability usage

Understand whether users inspect reasons and evidence when reviewing AI decisions.

Projected targets — not measured outcomes

60–80%

target reduction in manual roster entry time

40%

target reduction in incorrect allowance submissions

35%

target faster approval turnaround

50%

target reduction in dual-tagging conflicts

Source basis: Rosterix AI HLD v1.0, Section 7 — Implementation Roadmap & Expected Outcomes. Treat these as design / rollout targets, not production results.

Important: AI acceptance rate should never be treated as the sole success metric. High acceptance can mean usefulness — or it can mean users stopped checking the system. Pair acceptance with overrides, downstream errors, explanation usage and review behaviour.

13

Iterate

Feed real-world evidence back into the product

The product does not end at launch. Every decision creates evidence that can improve the experience, the rules and eventually the AI.

OBSERVE→ MEASURE→ IDENTIFY→ HYPOTHESISE→ DESIGN→ VALIDATE→ RELEASE↺

Product learning

Repeated overrides reveal missing context

If managers repeatedly override a recommendation for the same operational reason, the product may be missing an explicit business rule or context signal.

AI learning

Decisions become feedback

Recommendation → user decision → override → downstream outcome can become a feedback loop for future model and UX improvements.

Trust learning

Autonomy must be earned

Progress from informing to bounded automation only when behavioural evidence supports the next level of autonomy.

What I would validate next

01 • Qualitative interviews

Run moderated interviews with real stakeholders to validate the pain-point matrix.

02 • Trust calibration

Usability-test the AI Assistant and explainability patterns for trust calibration.

03 • Design system scale

Extend the design system from the snapshot into complete component specifications before later recommendation-layer phases.

The final product direction is not “more AI.” It is better decisions — with the right context, the right risk signal, and the right amount of automation at the right moment.

IMPACT

Project Impact

From workflow redesign to measurable product impact

60–80%

Manual roster effort

Projected reduction in manual roster entry time through AI-assisted roster generation and review.

PROJECTED TARGET

40%

Incorrect allowance submissions

Projected reduction through anomaly detection, validation and earlier risk visibility.

PROJECTED TARGET

35%

Approval turnaround

Projected improvement through approval context and risk-aware review.

PROJECTED TARGET

50%

Dual-tagging conflicts

Projected reduction through employee-tagging recommendations and conflict detection.

PROJECTED TARGET

THE PRODUCT SHIFT

What changed in the experience

BeforeUsers reconstructed context, checked rules manually and discovered many problems downstream.

AfterUsers receive contextual recommendations, risk signals and impact previews before consequential decisions.

AI roleAI proposes, explains and validates; humans retain review and approval responsibility.

System roleRosterix becomes a decision-support layer across project setup, tagging, roster, allowance, approvals and payroll.

Evidence boundary: The source case-study material identifies these numbers as expected/projected outcomes. They should not be presented as validated business results as production measurement becomes available.

REFLECTION

Reflection & Learnings

Accountability in Enterprise AI

The work changed how I think about AI in enterprise products. The opportunity was not simply to automate the most manual task. It was to understand where a decision becomes risky, what context the user needs to make that decision, and where the system must deliberately keep a human in control.

01

Automation is not the goal.

The most valuable AI moments are the ones that remove repetitive reconstruction of context while preserving the user's ability to inspect, edit and approve the result.

02

Trust is an interaction pattern.

Confidence indicators alone are not enough. Users need to see why a recommendation was made, what evidence supports it and what could happen if they accept it.

03

Enterprise UX is about relationships.

A roster change is rarely an isolated action. It can affect tagging, allowance, approvals and payroll. The interface has to expose those relationships at the moment they matter.

04

Design systems are part of the product strategy.

Once patterns such as validation, explainability, risk states and AI recommendations repeat across workflows, systemizing them becomes essential for consistency and implementation quality.

WHAT I WOULD DO NEXT

Validate the highest-risk workflows with Rosterix stakeholders and production evidence: measure recommendation acceptance, override behaviour, validation catches, approval turnaround, accessibility issues and downstream payroll exceptions. Those signals would determine where Rosterix should remain assistive and where bounded automation could safely expand.