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 end-to-end 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 surface-level fixes.

The 24-month 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 cloud-session 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, support-ticket 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 four-stage flow regardless of their goal: Login → Subscription launch → VM boot → Content access. There was no role-based 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 four-stage, 21-click process into a two-stage, ~3-click 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 ready-to-use 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 South-East 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 mixed-method 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 5-Whys 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 persona-specific — not a general usability call.

The shipped solution adds AI surfaces to the existing rule builder without modifying the standard creation flow. Both are opt-in 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 (pre-launch)

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.

Post-launch 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, time-sensitive, and non-expert in compliance.

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

The existing flow — as a first-time user.

Login

Three friction points — all measurable, all fixable.

Friction 01 — High Impact

Login wall before any value is shown

Impact: High drop-off before the flow even begins.

Friction 02 — Critical

Package selection: compliance language, no guidance, stepper reset

Impact: Maximum confusion, maximum drop-off. This is where conversions die.

Friction 03 — Structural

Flow fragmented into too many micro-steps

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

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

A first-time 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 drop-off points.
Each one has a single job.

Screen 01 — Package & Members

Replaces the compliance question with two plain-language 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, per-member 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 per-member breakdown and fully itemised pricing. T&C inline — no modal. CTA shows the exact amount to pay.

Redesigned · Review

Review screen — per-member breakdown, itemised pricing, inline T&C, exact CTA amount

The Package Assistant — eliminating the highest-anxiety 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. Post-engagement, I identified the Police Verification flow — Globeia's primary use case — as the more complex and higher-stakes design challenge.

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

Concept direction · not fully designed

Police verification package concept — outcome-framed 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.