Sub-Study · TrialComplete · T-Systems ICT India · Oct 2025

Study Users:
safe user assignment

High-frequency, high-risk admin task. Wrong role in a clinical trial means a compliance failure. This is the redesign that made the workflow trustworthy.

Interaction Design State Management Journey Mapping Service Blueprint
4 states
Toggle cases
modelled
50 to 70%
Estimated reduction
in task steps
Zero
Role loss when a
user is toggled off
3 docs
Journey · Flow
Blueprint

At a glance

Problem

Study Users sat four levels deep, and admins avoided the include toggle because they believed it deleted role assignments. It never did, but the system never said so.

My role

Led UX end to end, defining system behaviour and every interaction state with the Product Owner before any interface was drawn.

Key decisions
  1. Made inclusion an explicit state, so an admin can answer "is this person in the study" without reading carefully.
  2. Preserved roles on toggle off rather than deleting them, which is the change that fixed the trust problem.
  3. Moved roles inline as chips and added bulk assignment, replacing one modal per user.
Outcome

An estimated 50 to 70% fewer task steps for multi user scenarios, and admins stopped avoiding the toggle.

The Problem

What was
actually broken.

Study Users was buried four levels deep, and when you got there the interface made a straightforward task harder than it needed to be.

Study Users, problems annotated
Before state, annotated: no inclusion visibility, roles as comma text, modal only, one user at a time · click to expand
Five problems
No inclusion model

No clear "included vs not included" state

All users sat in one list. Admins couldn't answer "is this person in the study" without reading carefully.

Fragmented model

Adding users and assigning roles felt disconnected

Admins think "add Bob as Study Coordinator". The system forced two steps with nothing linking them.

Modal bottleneck

One user at a time, every time

Every addition opened a modal, once per user. For studies with 15 or more people this was genuinely slow.

Poor scanability

Roles as comma-separated text

"CatalogsManager, ProcedureManager, SystemSettingsManager, TestExecutor, Viewer" is hard to scan, with no inline editing.

Trust breakdown

Admins thought the toggle deleted roles

It didn't, but the system never said so. The result was hesitation, avoided changes, and support escalations.

Key Insight

One decision,
not two steps.

Inclusion and role assignment aren't separate tasks. They're one mental action, and the system needed to reflect that.

Design Principle

Never delete silently. Always preserve.

My Role

What I did.

Led end-to-end UX for the Study Users redesign
Defined system behaviour and interaction states before touching the UI
Mapped the Study Administrator journey and full user flow
Service blueprint to align UX, Product, and Engineering on backend logic
Validated all toggle cases and edge conditions with the Product Owner

The Solution

Toggle inclusion with
inline roles.

Six decisions changed how the workflow felt.

  • Inline role chips. Add or remove roles in the row, no modal required
  • Bulk assignment. Several users in one interaction, previously one per modal
  • "5 of 25 users included". Admins said the header count alone made them more confident

The other three decisions are all toggle behaviour, set out case by case below.

Redesigned Study Users, final delivered version with annotations
Final delivered design, annotated: inclusion state, inline chips, bulk assignment, reversible toggle, Case 4 validation · click to expand
Four toggle states defined
Toggle behaviour and interaction rules, 4 cases
Toggle behaviour and interaction rules, 4 cases plus edge case · click to expand

Case 01 · Default

Toggle OFF

User not in the study. Roles hidden. Dropdown disabled. Placeholder: "Turn on Include in Study to assign roles."

Case 02 · Active

Toggle ON

User included. Default roles appear as chips, added or removed inline.

Target state for most admins

Case 03 · Reversal

Toggle OFF after ON

User removed. Roles hidden, not deleted. Toggle back on and they reappear.

The critical trust fix

Case 04 · Validation

Toggle ON, zero roles

User stays included but Save is blocked. Inline: "Select at least one role to include the user."

Prevents invalid state

Process

Three artefacts.
Before any UI.

The interface came last. First the team had to agree on what the system should do, and what it must never do.

User Journey Map
User Journey Map ⊕
User Flow
User Flow ⊕
Service Blueprint
Service Blueprint ⊕
  • Journey map. Seven stages across the task, which surfaced study context verification as the riskiest moment
  • User flow. All four toggle cases with explicit decision gates, which made Case 3 and Case 4 first class states rather than edge cases
  • Service blueprint. Aligned role persistence with the atomic save transaction, and engineering confirmed it before a pixel moved

Impact

What changed.

Efficiency

Bulk inline editing replaced the one user modal flow. An estimated 50 to 70% fewer task steps for multi user scenarios.

Trust

Roles preserved on toggle-off. Admins stopped avoiding the toggle. Support tickets about accidental role loss dropped post-release.

Clarity

Clear included vs excluded state. "X of Y" count in header. Study access status visible at a glance.

Safety

Case 4 blocks saving a user with no roles. The save is atomic, so changes commit together or not at all.

Scalability

More users, more roles, larger study configurations. The pattern was reused across other admin modules.

Reflection

What it actually was.

Came in as a UI cleanup request. Turned out to be three things:

  • A state management problem. Toggle behaviour had to be predictable, reversible, and confirmed by the backend
  • A trust problem. Admins avoided a control because they didn't know what it would do
  • A system alignment problem. UX, Product, and Engineering needed shared definitions before any code was written
Key Takeaways

Reversibility builds trust in enterprise systems faster than visual polish

State clarity reduces cognitive load more than interface changes

Service blueprints make backend behaviour a shared responsibility

System thinking is how you get from "fix the UI" to "fix the thing that matters"

The real work wasn't designing the interface. It was defining behaviour people could rely on.