From thirty-four fields to two decisions.
A legacy role-assignment workflow exposed 34 fields in one long enterprise form. It worked for experienced administrators, but onboarding 20–25 new users, averaging around 26 years old, created an opportunity to rethink the experience before usage expanded globally.
I audited all 34 fields and found that many could be retrieved, inherited, derived or shown only under specific conditions. An initial progressive-disclosure concept reduced visual density but introduced uncertainty as fields appeared dynamically.
Testing led to a two-step guided workflow plus review instead. The final design preserved the business rules while reducing the core assignment task from 140–180 seconds to ~30–35 seconds, followed by a 4.72/5 experience rating across 25 rollout responses.
The problem wasn't how to redesign 34 fields. It was understanding why the user had to interact with all 34.
It worked. But familiarity was carrying the complexity.
The existing application had been used for years by experienced administrators. Employee information, access rules, geography, responsibilities and control information lived together in one long form.
Users had learned where things were, so the workflow wasn't necessarily perceived as "broken." But completing an assignment still required navigating a large amount of information regardless of whether every field was relevant.
The existing workflow exposed most assignment information together, making system-known, mandatory and conditional information appear equally important.
New users changed the cost of leaving the workflow untouched.
Around 20–25 new users were expected to start using role assignment, with an average age of approximately 26. Further global adoption was also foreseeable.
Rather than train another group to work around the existing complexity, the management and functional teams used this transition as an opportunity to modernise the workflow. This made the challenge more nuanced:
How do we simplify the experience for new users without disrupting the operational logic experienced users already trust?
Before changing the interface, I questioned the inputs.
I reviewed the 34-field workflow with the functional team rather than directly translating it into a cleaner UI. For every field, I asked: does the administrator actually decide this, or does the system already know it?
A field existing in the data model doesn't automatically mean it belongs in the user's workflow. This became the turning point of the redesign.
The next question wasn't what to remove. It was what could determine what.
Many fields couldn't simply disappear. Their values depended on employee information, role, geography, risk classification or combinations of previous decisions. I mapped these relationships to distinguish direct user decisions from system context, inherited values, derived values and exceptions.
The map helped identify where employee, role and geography could drive downstream values or trigger exceptional requirements.
Ask for decisions. Retrieve context. Derive what can be derived. Reveal exceptions only when necessary.
Could the familiar single-page model simply reveal less?
My first direction retained the idea of one continuous form. Instead of displaying everything immediately, the workflow began with high-priority inputs. As the administrator made selections, closely related fields appeared on the same page.
This wasn't a wizard. There were no artificial category-by-category steps; the page progressively expanded according to the user's decisions.
The hypothesis was: less information upfront → lower visual overload → faster completion. It worked visually. Interaction testing exposed a different problem.
Cleaner didn't necessarily mean easier to anticipate.
I tested the progressive-disclosure concept with 7 existing users, observing completion time, hesitation, backtracking and reactions to dynamically appearing fields.
Users immediately recognised that the screen was cleaner. But some began checking the interface after selections to understand what had appeared, disappeared or moved.
The concept reduced density, but made the workflow less predictable.
Why add another click when everyone wanted a simpler workflow?
The immediate functional assumption was reasonable: one continuous screen should be faster than two screens because it requires fewer clicks. Round 1 suggested otherwise.
The problem wasn't the number of clicks. It was the continuous show → decide → reveal → reorient → continue behaviour happening within the same page. A guided workflow could still use progressive disclosure — but introduce it through stable stages rather than a constantly changing canvas.
Fewer clicks weren't necessarily reducing effort. Predictability was.
Two guided input stages. One final checkpoint.
I reorganised the workflow around the administrator's decisions rather than the legacy system's field structure.
Details — Start with Employee + Role. Existing employee information such as organisation, type, status and location can be retrieved from system context rather than entered again.
Assignment — Ask for the operational decisions that determine the assignment: geography, responsibility, access and validity. Exceptional requirements remain conditional rather than competing with the standard path.
Review — Not a third data-entry step. It gives the administrator a stable summary of what will be created and an opportunity to correct something before committing.
More navigation. Less uncertainty.
I tested the wizard against the same core task structure used in Round 1. Users now knew where they were, what kind of decision belonged to the current stage, and what remained before completion.
Clearer stages reduced uncertainty — but repeat assignment exposed one final workflow problem.
Completing one assignment wasn't always the end of the task.
Some administrators create several role assignments consecutively. During validation, two users encountered an unnecessary loop: save, close the modal, return to the list, reopen Role Assignment, begin again.
The wizard had simplified an individual assignment but hadn't fully considered the administrator's sequence of work. That observation led to the final CTA amendment.
The workflow became a modal over the working context.
Instead of sending administrators to another large standalone page, Role Assignment opens above the user-management list. The surrounding application remains visible but inactive, preserving context while focusing attention on the current task.
Employee selection retrieves existing information automatically. The administrator confirms the user and selects the appropriate role before continuing.
The interface uses controls appropriate to the decision rather than turning every choice into another dropdown. Geography, responsibility, access, permissions and validity form the standard path — risk, monitoring, justification, supporting documents and attestation appear only when relevant.
The final state consolidates the assignment into a readable summary rather than another editable form. Users can return to either part of the workflow before committing.
Completes the current assignment.
Keeps reusable context, starts the next assignment right away.
Returns without losing the current configuration.
The final improvement came from looking beyond "Can users complete the form?" to "What do they need to do immediately afterwards?"
Did the UX proposal still satisfy the functional workflow?
Changing the interaction model couldn't remove the rules that made role assignment operationally valid. I compared the functional requirement against the corresponding UX behaviour, checking normal, conditional and repeat-assignment paths.
The reduction came from removing work, not making people type faster.
Completion time was measured from beginning a representative role assignment through successful completion.
The improvement came from several changes working together: retrieving system-known information, inheriting existing configuration, deriving values through business rules, isolating exceptional requirements and creating predictable decision stages. The result wasn't merely a shorter form. It was less work for the administrator.
Measure the experience after the work is done.
Rather than interrupting the role-assignment flow with a survey, feedback was captured after the assignment had been submitted and the modal closed. A small, non-blocking card appeared on the user-management list.
The mechanism remained lightweight enough to capture sentiment without becoming another task.
This was important because the legacy experience wasn't universally disliked. Long-term users had become comfortable with it. The challenge was therefore not simply replacing a "bad" interface, but helping users accept a fundamentally different way of completing a familiar task.
Adoption became evidence that simplification hadn't come at the expense of familiarity or control.
The visible change was smaller than the structural one.
What administrators used to face, reduced to a single guided decision.
140–180 seconds down to roughly 30–35 seconds per assignment.
Progressive disclosure looked lighter, but users still had to anticipate what might appear next — less visible didn't mean less cognitive work.
One extra step reduced reorientation and created clearer decision boundaries. Stable stages beat a shorter, shiftier page.
The real redesign wasn't the interface. It was deciding which inputs the system should own instead of the administrator.
Simplify the responsibility, not just the interface.
The legacy workflow treated most information as something administrators had to confront. This redesign separated human judgement from system responsibility — what the system already knew was retrieved, what rules could determine was inherited or derived, and what applied only occasionally stayed conditional.
What genuinely needed a person's judgement became the centre of the experience. The result wasn't a shorter form; it was a workflow that asked less of the people using it, while keeping every access, geography and compliance rule intact — proof that simplicity and control aren't opposites, just poorly divided.
The task was boring. The wait didn't have to be.