Users were losing time before work even started

Enterprise users , geologists, geophysicists, and technical operators , needed a faster and clearer way to discover applications, resume recent work, view updates, and monitor product status. But the existing workspace experience was fragmented, forcing users to rely on manual search, repeated navigation, and disconnected tools just to begin everyday tasks.

The business consequence was direct: users were hesitant to adopt the cloud workspace because the experience created friction in daily workflows , too many steps before they could start work, weak visibility of recent projects, fragmented application access, and unclear system status.

Cloud infrastructure was ready. Adoption wasn't. The gap was entirely in the user experience , and it was measurable: 21 clicks to complete a core task that should have taken 3.

What I owned ,
and what I fought for.

I led endtoend UX strategy for the workspace redesign , owning research direction, design principles, prioritisation calls, and validation. My remit was the user experience. In practice, it also meant being the person who kept surfacing the research when the conversation drifted toward surfacelevel fixes.

The 24month timeline reflects the reality of enterprise B2B: stakeholder alignment, legacy dependency mapping, phased rollouts, and iteration on real usage data. The design took 4 months. Getting it built correctly took the rest , and that gap is where most of the real design work happened.

Starting with listening , not assumptions

My process started with listening to users and understanding how they moved across tools, projects, and cloud workflows. To understand why users were facing friction, I studied how geologists, geophysicists, and enterprise users moved from login to actual work , analyzing the workspace not just as a dashboard, but as a daily productivity environment.

Listen and think

The research focused on four areas: how users accessed applications, how they resumed recent projects, how they understood cloudsession status, and where they lost time in the workflow.

Interview Methods

I conducted feedback synthesis from 40 professional geologists and geophysicists , combining 1:1 interviews, workflow walkthroughs, supportticket analysis, contextual inquiry, and review of product usage data. I collaborated closely with internal domain experts throughout.

Research document

Before any interviews were conducted, a structured research document was prepared to align the team on what we were trying to learn and why.

Interview framework

Each interview followed a structured framework to ensure consistency across 40+ sessions while leaving room for the conversation to go where the user's experience led.

Five major friction areas , all measurable

I audited the existing workspace experience across navigation, app access, recent work visibility, system feedback, and user confidence. The audit surfaced five critical failure points , not aesthetic issues, but structural problems in how the workspace communicated and responded to users.

What the data actually said

Mapping user struggles to business impacts made the cost of inaction impossible to ignore. Every friction point in the user experience had a direct operational consequence for the business , stalled cloud migration, unused infrastructure, and rising support load.

How Might We

How might we

Translating user needs into design decisions

Each insight from research was mapped directly to a design intervention , and each intervention was evaluated against the value it would deliver to users. This kept the work anchored to outcomes, not features.

Affinity Map

The workspace serves three distinct user types.

Designing a single workspace that works for all three required mapping each role's mental model before any wireframe was drawn. The IA had to accommodate their different entry points without creating three separate products.

The navigation architecture before the redesign.

The existing IA forced every user through the same fourstage flow regardless of their goal: Login → Subscription launch → VM boot → Content access. There was no rolebased differentiation, no state persistence, and no separation between infrastructure controls and work tools. The architecture treated every session as a first session.

Four design principles.
Every decision ran through them.

Based on research with all three user types, I defined four principles that governed every design decision. Not aspirational guidelines , actual filters. If a proposed solution didn't hold up against all four, it didn't ship.

Initial wireframes
which provided a direction

Workspace layout

Apps and Projects

App settings

Workspace settings

The calls that changed adoption

Every design decision was tied to a specific friction point identified in research. The goal wasn't to redesign the interface , it was to remove the obstacles between users and their work.

Flow Comparison , 85% step reduction from redesign

The friction map documents the exact journey users had to take before and after the redesign. It reveals where unnecessary steps, repeated navigation, and unclear states were costing users time , and shows exactly how the redesign collapsed a fourstage, 21click process into a twostage, ~3click flow.

Before: Users navigated through Login → Launch Subscription → Boot Virtual Machine → Open Recent Work , accumulating 21 clicks, multiple redirects, and significant wait time before starting actual work.

After: Login & VM launch are combined into a single step. The workspace loads readytouse with apps and recent projects visible. One click to start working.

The redesign converted a flat adoption trend into measurable growth

Within six months of launch, the redesign delivered results that were measurable across every dimension , user behaviour, satisfaction, and business adoption. The data validated not just the design decisions, but the research approach that preceded them.

The adoption rate chart below tells the fuller story , a flat growth curve from 2020–2024 that sharply inflected upward immediately after the redesign launch, reaching +13,000 new users by December 2024.

What I'd do differently

Four honest calls , things I'd change if the project started today.

The Product

This case study covers a Sales Force Automation (SFA) platform used by pharmaceutical companies across India and SouthEast Asia. The platform enables sales managers and compliance leads to configure business rules that govern which medical representatives (MRs) visit which doctors, under what conditions, and during which coverage periods.

Business rules are the backbone of compliant field operations..They determine territory coverage, customer eligibility, product promotion boundaries, and visit frequency targets. A misconfigured rule doesn't just create bad data , it can result in regulatory exposure, incorrect incentive payouts, or MRs visiting the wrong customers for months before anyone notices.

The Strategic trigger

The product team identified a sharp bottleneck: Rule creation was the #1 support ticket category. Admins , the primary rule authors , were spending an average of 47 minutes per rule. New hires took over 3 weeks to become independent on the rules module. The product roadmap had an AI capability investment cycle opening, and leadership asked the design team to answer one question:

This case study documents how we answered that question , and what we shipped.

Wrong rules. Wrong customers.
Measurable commercial damage.

The interface couldn't handle nested rule structures , so users simplified their rules to fit what the tool could express, not what the business actually needed. The result was systematic field misalignment: reps visiting the wrong doctors, incentive payouts calculated on bad data, and compliance exposure that could run for months before surfacing.

The problem wasn't user skill. It was that the interface was designed around the tool's data model , not around how managers actually think about territory coverage. That mental model mismatch was upstream of every downstream failure.

3 weeks of mixedmethod research

Two users. Incompatible navigation architectures.

Research surfaced two distinct user types , but the real finding wasn't a personality difference. It was a structural one. Their needs don't just diverge , they require opposite things from the same interface at the same decision point.

Design Audit

A Design audit using established heuristics revealed three critical failures in the existing interface: Visibility (partially passed , key rule state was not always visible), Flexibility (failed , no support for nested or grouped rules), and Learnability (failed , required training and prior knowledge to use correctly).

Old UI

Old UI

The root cause wasn't the UI.
It was the mental model it assumed.

Every path through the 5Whys landed at the same place. The interface was built on the rule's data schema , conditions, operators, values, effective dates , because that's how the database represents a rule. But that's not how a manager thinks about coverage.

Once the root cause was clear, the design direction followed: don't simplify the interface , change what the interface is an interface of. The tool needed to think in coverage terms, not data terms. That reframe is what made AI assistance viable , because natural language is how managers already describe coverage, and it's what the NL parser would receive.

Five principles.
Every decision ran through them.

Not aspirational values , actual filters used to evaluate every design option, including the three prototypes we built and tested before committing to direction.

Three options.
One clear winner.

We prototyped three distinct approaches and tested each with both user types before committing to direction. The evaluation criteria for each rejection was personaspecific , not a general usability call.

The shipped solution adds AI surfaces to the existing rule builder without modifying the standard creation flow. Both are optin and clearly labelled. The standard builder remains the primary path for power users.

Surface 1
Standard builder with AI suggested tag

Surface 2
AI : Natural Language Mode

Surface 3
AI Suggestions panel

One I fought for.
One I got wrong.

Both shaped the product more than any screen decision did.

Usability testing (prelaunch)

We ran moderated usability testing with 8 admins (mix of power users and relative newcomers) across 2 sessions. Tasks: create a rule from scratch using natural language, add a condition from the suggestions panel, review and save.

Postlaunch signals (6 weeks)

Qualitative wins

, Priya, Sales Ops Admin, Mumbai

, Regional compliance reviewer, Pune

What I'm proud of

What I'd do differently

Roadmap thinking

What Globeia does , and why it's hard to design for.

Globeia provides mobile fingerprinting services for regulated purposes , immigration, professional licensing, background checks. This is not a consumer booking app. Every user is anxious, timesensitive, and nonexpert in compliance.

I walked the live booking flow as a firsttime user across three sessions before forming any design opinions. The audit drove the solution.

The existing flow , as a firsttime user.

Login

Three friction points , all measurable, all fixable.

Friction 01 , High Impact

Login wall before any value is shown

Impact: High dropoff before the flow even begins.

Friction 02 , Critical

Package selection: compliance language, no guidance, stepper reset

Impact: Maximum confusion, maximum dropoff. This is where conversions die.

Friction 03 , Structural

Flow fragmented into too many microsteps

Impact: Cognitive overload throughout. Users lose context and confidence at multiple points.

Who is this user , and what are they actually feeling?

A firsttime user with a specific life goal , immigration, job abroad, professional license. Not a compliance expert. Arrives with a goal, not technical knowledge, and cannot afford to get the process wrong. Business priority: reduce abandonment at package selection , the point where confusion peaks and commitment is still fragile.

What the analogous research said

The redefined problem.

People come to Globeia with a personal goal , a job offer, a visa, a license. They're not here to learn compliance. But the booking flow asks exactly that. A login wall before any value. Steps that reset and contradict. And at the most critical moment , choosing a package , technical jargon instead of a clear answer to the only question that matters: What do I need, and why? So they hesitate. And they leave.

Globeia isn't one flow. It's three.

Globeia's flow branches by purpose , each path has different packages, pricing, and compliance requirements. Before redesigning any screen, I mapped the full system.

Before vs. After , proposed flow

Current flow , 14 decision points, friction callouts in red

Proposed flow , 5 steps, improvements in green

Four principles. Every decision ran through them.

Three screens (for both mobile and web), three specific dropoff points.
Each one has a single job.

Screen 01 , Package & Members

Replaces the compliance question with two plainlanguage cards and a Recommended badge. Rejection history moves inline as a checkbox. Each member gets their own package selection. A live running total updates as members are added. The AI Package Assistant trigger is available for users who remain uncertain.

Redesigned · Package & Members

Package & Members screen , plain language cards, permember selection, live total

AI Assistant , recommendation state

AI Package Assistant , two questions, one recommendation, applied in one click

Screen 02 , Slot Selection

One shared slot for all members. Four calendar states (available, limited, unavailable, selected) replace the original two floating options. A confirmation block answers "do I need separate slots?" before it's asked.

Redesigned · Slot Selection

Slot selection , 4 calendar states, time grid with availability, shared slot confirmation

Screen 03 , Review & Booking Summary

Single column, read top to bottom. Three editable review cards with permember breakdown and fully itemised pricing. T&C inline , no modal. CTA shows the exact amount to pay.

Redesigned · Review

Review screen , permember breakdown, itemised pricing, inline T&C, exact CTA amount

The Package Assistant , eliminating the highestanxiety decision.

AI Package Assistant , trigger → questions → recommendation → applied. Full interaction flow.

Clear labels only go so far. Some users need guidance, not just information. The AI Package Assistant asks two contextual questions and recommends the right package , inline, optional, and transparent.

The flow I didn't design , and why it matters more.

The "Other Purpose" flow was a proof of concept. Postengagement, I identified the Police Verification flow , Globeia's primary use case , as the more complex and higherstakes design challenge.

My concept direction for the police verification package screen addresses three specific problems:

Concept direction · not fully designed

Police verification package concept , outcomeframed cards, visible compliance pipeline, staged pricing as timeline

Full flow architecture , how each purpose branches into a different service journey

What I'd do differently.

Projected impact.

Projected outcomes , based on Baymard Institute checkout research and published B2B booking flow data:

These are projected, not measured. Whether the conversion uplift holds requires a live A/B test.

Sales managers were fighting the tool , not the work

Pharma sales managers needed to create and manage complex business rules that decided which customers a medical representative should visit. The existing system , built on a 3rd party rule engine bolted onto an alignment manager , made this nearly impossible to do well.

Rule creation was error-prone, slow, and opaque. Managers couldn't see what rules were active, couldn't predict the impact of a change, and couldn't write a nested AND/OR condition without help from technical staff. Complex logic was authored in a free-text field with a regex-like syntax. Errors silently propagated into customer alignment data , the operational consequence was direct.

The business consequence: rule creation took 25 minutes on average. Errors required rework cycles. Support load was rising. And the dependency on a 3rd party rule engine drove cost up while keeping flexibility down. A redesign wasn't a UI refresh , it was a fundamental architectural rebuild.

End-to-end ownership across research, IA, and UI

I led the UX design end-to-end across a 7-month timeline , owning user research, information architecture, wireframes, high-fidelity UI, and usability validation. I worked alongside one other UX designer, a visual designer, and partnered closely with product management and engineering.

The team was small. The product surface was large. The work spanned a complete reimagining of the admin experience , how categories of rules are organised, how individual rules are authored, how nested conditions are expressed visually, and how the entire flow is decoupled from the 3rd party dependency that was the root of much of the friction.

What I owned

Listening to the people writing the rules

Research began with understanding the actual workflow , who creates rules, why, how often, and what gets in the way. I conducted contextual interviews with rule administrators alongside secondary research with the ZS UX Excellence team and product managers. The goal was to surface the real workflow, not the documented one.

Insights from interviews

Five categories of friction surfaced consistently across interviews , each with a measurable business cost.

Three heuristic failures , structural, not cosmetic

Before redesigning, I audited the existing Javelin Alignment Manager and rule builder against Nielsen's heuristics. The audit revealed three structural failures that no amount of visual polish would fix.

Audit · Flexibility

Audit · Learnability

Two personas. Opposite needs.
One product to serve both.

Research surfaced two clearly distinct user types , and the central design challenge of the project was balancing their opposing needs without compromising either. This wasn't a "primary and secondary user" situation. Both were equally critical to the product's value.

Five "why"s to a structural root cause

To go past surface symptoms, I ran a 5-Whys analysis starting from the most visible business pain , customer filtering errors , and working back to the structural cause in the UX.

Problem statement

Pharma sales managers needed to create and manage complex business rules. The existing system made this process fragmented and unintuitive. Users had to jump between multiple steps, decipher inconsistent interfaces, and often lost track of progress. This inefficiency not only slowed down rule creation but also increased the risk of errors, reduced trust in the platform, and discouraged adoption of its cloud features.

Diverging widely before converging deliberately

Ideation used the Lotus Blossom technique to expand outward from the core problem , brainstorming sub-ideas for each major feature area before evaluating them against research insights and engineering constraints.

Mind mapping the rule builder feature set

From the ideation grid, I mapped detailed feature flows for the most critical surface , the rule builder itself , including rule status, sequencing, notifications, and the inside-a-rule view.

Rule Category mind map

Inside-a-Rule mind map

User flow , before and after

The redesigned flow eliminated the 3rd party dependency entirely , every step now happens within a single, consistent interface. The number of decision points dropped, navigation became predictable, and rule authoring moved from a textarea to a structured visual builder.

Before · Fragmented, 3rd party dependency

After · Unified, no 3rd party dependency

Design principles , that governed every decision

Four principles emerged from research synthesis. Every design call was tested against them. If a proposed solution didn't hold up against all four, it was reworked.

The key screens that shipped

Visual designs translated the IA and principles into a working product. Five surfaces did the structural heavy lifting , the rule builder itself, the categories view, the rules list, the rule details, and the create-category flow.

Rule builder , core authoring surface

Rule categories , structure for a flat list

Rules list , filtered and scannable

Add new rule , full flow

Add details

Add conditions

A complete shift across every measurable dimension

The redesign was validated through usability testing with 10 users across 10 representative tasks, and measured through structured outcomes post-launch. The results changed how rule administrators experienced the product , and the data backed it up.

Usability testing , 10 users, 10 tasks. Green = task completed successfully without intervention. Yellow = completed with hesitation. Red = task failed or required guidance. The matrix surfaced exactly where the design still needed iteration.

User emotional journey , before and after

Post-launch validation tracked emotional state across the journey , Discovery, Dashboard, Navigation, Landing, and Task completion. The before-state plateaued at "Happy" only briefly before dipping into "Satisfactory" mid-flow. The after-state stayed consistently Happy , rising at completion.

Before · Emotional dip mid-flow

After · Sustained positive state

What I'd do differently today

Three honest reflections , things I'd approach differently if this project started today.

Key takeaways