UX AGENT

Confidential enterprise product work Korn Ferry · Product design · Interaction design · UX/UI

Enterprise software can carry a lot of complexity. The person using it shouldn’t have to.

The goal: Simplify a high-stakes talent workflow inside an established enterprise platform, so people can understand their options, compare them with confidence, and move forward without fighting the interface.

See the case study View résumé
Enterprise Mature product + real constraints
NDA-safe Rebuilt, never reproduced
Senior IC Workflow through handoff
Illustrative enterprise workflow NDA-safe reconstruction
Recommended Search all
PS
Senior product leader
A
Recommended Profile A Strong overall fit
94 match
B
Alternative Profile B Relevant experience
87 match
C
Alternative Profile C Adjacent experience
82 match
A
Selected profile Profile A
Decision support

Why this option stands out

Role fit 94%
Leadership 90%
Experience 86%
Supporting context
  • Relevant leadership depth
  • Strong role alignment
  • Experience across complex teams
✦ Clearer recommendation Enough context to decide without opening five different screens.
✓ 1 option selected Review or choose another
Design problem Complex choice with too much cognitive load
Design direction Context, comparison, decision, next step

The assignment

The screens are confidential. The product decisions are not.

I am working inside a mature enterprise talent platform where every change has to respect existing workflows, established components, product rules, engineering constraints, and people who already know how to use the software. My job is to make complex decisions feel clearer without pretending the complexity does not exist.

EnterpriseEstablished product ecosystem
ActiveWork still evolving
NDA-safeNo client screens shown
System-levelStates, components, workflows
</>
Everything you see on this page is rebuilt for the portfolio.

The interface diagrams, journey maps, states, and product illustrations are original HTML and CSS. They communicate the design thinking without reproducing confidential Korn Ferry screens, data, or proprietary rules.

The problem

The product already had depth. The risk was making people carry that depth in their heads.

Enterprise users make decisions inside systems with history. There are existing rules, filters, terminology, edge cases, and downstream consequences. Adding one more option can create more work instead of less. The design problem was not “make it simpler.” It was to decide what should be visible now, what could wait, and what the interface needed to remember for the user.

The design tension Preserve the power of an enterprise workflow without asking the user to manage the complexity that makes it possible.
01

Existing mental models

Experienced users already know where things live. A redesign has to improve the path without making familiar work feel newly foreign.

Respect learned behavior
02

Decision density

Filters, recommendations, comparison, detail, selection, and confirmation can all be valid. The order determines whether they help or compete.

Hierarchy over feature count
03

System consistency

The new experience has to feel like the same product. Components, patterns, states, and accessibility rules are constraints and design tools.

Fit the system, improve the system
04

Confidentiality

The strongest portfolio story cannot depend on exposing client screens or proprietary rules. The thinking has to stand on its own.

Show judgment, not secrets

Evidence and framing

I started by mapping the decision. Not redrawing the screen.

The useful evidence came from the operating product, working sessions, existing flows, populated states, design-system patterns, technical constraints, edge cases, and the questions the team kept having to answer. I used that material to separate the real user decision from the software surrounding it.

01

Existing workflow review

I traced what the product asked someone to notice, remember, compare, select, and confirm. That exposed where the interface was carrying structure instead of supporting a decision.

Understand before changing
02

Working sessions

I used conversations with product and engineering to understand what was fixed, what was flexible, what had history behind it, and where a design change would create downstream work.

Constraints become design inputs
03

State and edge-case inventory

Empty, selected, refreshed, filtered, expanded, modal, confirmation, and return states mattered as much as the polished default screen.

Design the whole interaction
04

Component reality

I reviewed the patterns already available and where new needs should extend the system instead of creating one-off controls that would drift later.

Design for reuse
Illustrative synthesis

The inputs were messy. The design question became simple.

I did not need to reproduce every rule in the interface. I needed to help the user answer three things: what is recommended, what else can I explore, and what happens when I choose.

Representative user journey

The workflow makes more sense when you map the decision, not the screens.

Because the underlying product is confidential, this is a generalized reconstruction of the decision sequence I was designing around, not a client research artifact. It shows the questions the interface has to answer from first orientation through a committed choice.

01 Orient

What am I being asked to choose?

The user needs a clear starting mode and enough context to understand the job before the controls take over.

Design response Separate the recommended path from broader search.
02 Evaluate

Why is this option being recommended?

A suggestion has to carry enough evidence to be judged without forcing someone into a second workflow.

Design response Pair the recommendation with concise rationale and inspectable detail.
03 Compare

Is there a stronger alternative?

Experienced users still need control. The interface has to support comparison without erasing their current choice.

Design response Keep alternatives available while preserving selection state.
04 Commit

Am I confident enough to use this selection?

The action should feel like an explicit decision, not the accidental result of navigating around the screen.

Design response Anchor one primary action to the selected state.
05 Confirm

Did the system apply what I chose?

Enterprise workflows need closure. A success state has to confirm the change without making the user reorient from scratch.

Design response Confirm the outcome and preserve a clear route forward.

The product reframe

I stopped treating every option like it deserved equal weight. The interface needed a point of view.

A recommendation is only useful if it gives someone a place to start without taking control away. The direction became a two-path model: make the strongest recommendation easy to inspect, while keeping broader search and comparison available for people who need more control.

Illustrative interaction model

One product. Two useful ways into the decision.

Guided pathLower effort

Start with a recommendation

Give the user a strong first option, enough context to judge it, a clear way to inspect details, and a stable selected state.

Expert pathMore control

Search the full set

Keep the broader tool available for people who know what they want, need to apply more filters, or want to explore beyond the suggested starting point.

01

Separate modes clearly

Recommended options and full search serve different levels of intent. The interface should make that difference obvious without making either path feel secondary.

Two modes, one mental model
02

Selection stays visible

Once someone chooses, the product should remember that choice and keep the next action stable while they inspect alternatives or details.

Reduce memory work
03

Detail on demand

Deep information belongs close to the decision, but it does not have to occupy the first screen. The modal becomes a focused layer instead of a second page.

Reveal depth when needed
04

Refresh without reset

Changing a suggestion should not make the entire experience feel unstable. State, selection, and orientation need predictable rules.

Change one thing at a time

Human-in-the-loop AI

AI can narrow the field. The interface still has to earn the decision.

The important UX question was not how to make an AI suggestion look smarter. It was how to make the suggestion useful without presenting it as unquestionable. I treated AI as decision support: a strong starting point, visible reasons, alternatives, and an explicit human choice before anything changes.

✦

Recommendation is not authority

The AI path should help someone start faster, not hide the fact that there are other valid options.

Keep agency visible
?

Explain enough to judge

Users need a reason they can inspect. They do not need every internal rule or a fake sense of mathematical certainty.

Inspectability over spectacle
↔

Make disagreement easy

Search, comparison, refresh, and alternate choices remain part of the same flow instead of being treated as failure.

Design the escape hatch
✓

Make commitment explicit

A recommendation can be passive. Applying it should require a clear human action and produce a clear confirmation.

Human action closes the loop
AI UX risk model

The failure mode is not only a bad recommendation.

Trust can also break when the recommendation appears without context, when confidence looks more precise than the user can verify, when alternatives disappear, or when the system changes state without an obvious human commitment.

Design evolution

The early concept exposed the workflow. The refined concept exposed the decision.

These illustrations do not reproduce Korn Ferry screens. They show the design shift I can safely discuss: moving from a dense, all-at-once enterprise pattern toward a clearer hierarchy of recommendation, exploration, detail, selection, and confirmation.

EARLY DIRECTIONEverything visible
  • Search, filters, options, details, and actions compete at the same level.
  • The user has to decide what deserves attention before making the real decision.
  • Selection can feel temporary because too many elements remain equally active.
  • The screen describes the system better than it supports the task.
REFINED DIRECTIONDecision-first hierarchy
  • The starting mode is obvious: recommendation or full exploration.
  • The selected option has a stronger visual and behavioral state.
  • Details appear when requested instead of competing with the first choice.
  • The primary action remains stable and easy to find through the flow.
HIERARCHYFrom controls to intentThe interface starts with what the user is trying to decide, not everything the software can do.
AIFrom answer to evidenceA suggestion becomes more useful when the user can inspect why it belongs and still explore alternatives.
STATEFrom click to commitmentSelected, refreshed, detailed, and confirmed states work together instead of behaving like isolated screens.
SYSTEMFrom one-off screen to reusable patternTabs, filters, cards, modal behavior, buttons, and success states become parts of the same product language.

From concept to build-ready

The screen was never the deliverable. The behavior had to hold together.

I worked through the interaction as a system: tabs, filters, selected states, refresh behavior, detail overlays, persistent actions, cancel paths, success feedback, hover and focus states, and the reusable Figma components behind them. That is where a polished concept becomes something engineering can actually build.

01

Frame the interaction

Define the user decision, what should stay persistent, what can change, and which action ends the flow.

Start with behavior
02

Explore concepts

Test different ways to separate recommendation, search, details, selected state, and action without rewriting the whole product.

Compare before polishing
03

Prototype the flow

Connect tab changes, detail overlays, refresh behavior, selection, cancellation, and success so the sequence can be experienced instead of explained.

Make the states real
04

Refine the interface

Adjust spacing, card height, button hierarchy, modal positioning, iconography, contrast, hover states, and component consistency.

Details remove doubt
05

Update the components

Push approved changes into reusable components so the final screens and the pieces engineering references stay aligned.

Do not leave drift behind
06

Prepare the next problem

The engagement is expanding into adjacent enterprise workflows. Each solved interaction becomes a stronger pattern for the next one.

Active product work

Illustrative state map

A screen can look finished while the interaction is still unfinished.

I treated the states as the product. The default view was only one moment in a sequence that also had to survive a refresh, a different choice, deeper inspection, cancellation, and confirmation.

That work is easy to miss in a portfolio screenshot. It is also where a lot of enterprise UX succeeds or fails.

The component work mattered as much as the page.

I kept the final screens and the reusable pieces aligned so the design did not depend on somebody rebuilding the intent from screenshots. This illustration represents that system without showing the client library itself.

Cross-functional loop

Good enterprise UX gets stronger when the handoff starts before the design is done.

I use working sessions to turn product requirements, design intent, component constraints, and engineering questions into one shared sequence. The exact client process is confidential; this reconstruction shows the collaboration pattern I use to keep the interaction from drifting between teams.

01ProductGoal, rules, constraints
→
02DesignFlow, states, hierarchy
→
03EngineeringFeasibility, behavior, edge cases
→
04PrototypeInteraction made testable
→
05HandoffComponents + state logic
→
06QACheck the built behavior

State coverage + accessibility

A polished default screen is not enough.

The checklist below is the kind of interaction coverage I use before a flow is ready for handoff. It is a generalized portfolio artifact, not a claim about unpublished client QA results.

StateUser questionDesign responsibility
LoadingIs something happening?Preserve orientation and progress.
EmptyWhy is there nothing here?Explain the state and provide a next move.
SelectedWhat did I choose?Keep commitment visible across inspection.
ChangedWhat just updated?Change the requested element without resetting the page.
ErrorCan I recover?Keep the decision intact when possible.
SuccessDid it work?Confirm the outcome and preserve the next route.
Tab
Keyboard pathLogical focus order across tabs, cards, modal content, and primary action.
◉
Visible focusControls remain identifiable without relying on hover or color alone.
Aa
Readable hierarchyContrast, type size, labels, and selected states carry meaning clearly.
↕
Modal behaviorFocus enters, stays contained, and returns to the trigger when detail closes.
44
Target sizeImportant actions remain usable for mouse, touch, and low-precision input.
≋
Reduced motionFeedback does not depend on animation to communicate state.

Design outcomes

The result is not a prettier screen. It is less work between the user and the decision.

This is active client work, so I am not publishing adoption, conversion, internal performance, or proprietary product metrics. The outcomes I can show are the design changes themselves and the system they created for the work that follows.

01

Clearer entry points

The user can distinguish a recommended starting point from broader exploration without learning a new product model.

Intent before controls
02

Stronger state memory

Selection, detail, refresh, cancellation, and confirmation work as a connected sequence instead of isolated interface moments.

Lower cognitive load
03

More reusable patterns

Approved changes move into shared components and states, giving the next screen a stronger starting point than another one-off design.

System over screenshot
04

Better handoff clarity

Engineering receives interaction intent, component behavior, and state logic instead of being asked to infer the experience from a static frame.

Design that survives implementation

What I would measure after release

The next question is whether the clearer design actually reduces decision work.

I cannot publish internal Korn Ferry metrics. A responsible measurement plan would look for evidence that people can reach a confident selection with less backtracking, fewer recoverable errors, and a clearer relationship between recommendation, inspection, comparison, and commitment.

↗
The case study will keep changing because the product work is still changing.

I am deliberately treating this as a living case study. As more work moves forward and more of the story can be shared safely, I will add the next problem, the next decision, and the next design evolution without exposing confidential product details.

Reflection

Enterprise design is mostly deciding what the user should not have to remember.

This work reinforced something I have learned across very different products: complexity is not the enemy. Unmanaged complexity is. A mature system can stay powerful while the interface takes more responsibility for order, memory, context, and timing.

The AI layer makes that even more important. Surfacing a recommendation is easy compared with designing the trust around it. The user still needs to understand where to start, how to inspect the answer, how to disagree, and what happens when they commit.

That is the part of enterprise product design I like most. The problem is rarely one screen. It is the relationship between the screen, the rules, the people who already know the product, the engineering reality, and the next decision.

Active engagement This story is still being written.

The work is expanding into adjacent enterprise workflows. I will keep this page intentionally high level and update it only with material that can be shown without exposing client screens, data, internal logic, or confidential implementation details.

More selected work

Different products. Same responsibility.

The context changes, but the work stays familiar: find the decision that matters, make the path clearer, and stay close enough to implementation that the idea survives.

I like the part of product design where the problem is still messy.

If you are hiring for a senior product design role that needs strong interaction thinking, enterprise UX, systems work, and somebody comfortable staying close to engineering, that is the work I want to keep doing.

Talk about a full-time role View résumé