Nitya Venkataraman · Product Designer

EPAM · 2026 · Internal R&D

The UX Pipeline

A design process that can run itself will decide anything you let it decide. The interesting work was never the generating — that is close to free — but deciding what the machine may not decide, and building the stop that enforces it. Six stages from raw research to developer-ready stories, everything checkable checked before a person sees anything.

6
Stages, from raw research to an evaluation plan
3
Choices at the fork a person makes, not the pipeline
50
Test fixtures; a rule without one gets reverted
17
Developer-ready stories from the worked run
Role
Product Designer — method, rules, validators
Context
EPAM, internal R&D
Timeframe
2026
Scope
Stage design, rule contracts, rubrics, Figma output
  1. 01

    Discovery

    Transcripts, tickets and briefs become themes, each carrying verbatim quotes and declared gaps.

    → themes, quotes, corpus
  2. 02

    Strategy

    Themes become personas and a current-state journey; the problem becomes How-Might-We statements.

    → personas, journey, HMWs
  3. 03

    Ideation

    Each HMW gets features scored on reach, impact, confidence and effort, plus two or three directions.

    → scored backlog, directions
The fork

The pipeline proposes directions and is forbidden from choosing one. Direction, platform and design system are all picked by a person, and the choice is recorded on the run.

  1. 04

    Wireframe & IA

    The chosen direction becomes a sitemap and page specs — every state, every breakpoint, accessibility.

    → page specs, Figma prototype
  2. 05

    Delivery

    Pages become stories a developer can pick up: Given/When/Then, accessibility, analytics, microcopy.

    → stories, microcopy
  3. 06

    Evaluation

    The claims the first five stages made become a test plan and a measurement plan.

    → test plan, metrics
The six stages. Each one reads what the stages before it produced, and nothing from outside the run. There is a human approval after every stage; the dashed band is the one place the pipeline stops for a decision rather than an approval.

Three judgments I kept for a person

And what it takes to make a refusal stick

Naming the exceptions is easy and worth little. The work is building a system where the exception cannot quietly be skipped the first time it is inconvenient.

  • The bet

    Stage 3 produces two or three whole directions and is forbidden from picking one. Direction, platform and design system are chosen by a person, and the choice is written into the run.

    Recorded, not buried in a prompt

  • Yes, or revise

    Every stage ends at a human approval. Approve and the artifact is persisted; ask for a revision and the feedback becomes that stage's next input.

    The only gate that can change the brief

  • Overriding a rule

    A reviewer can overrule a validator. What they cannot do is edit it to make the complaint disappear — the override is recorded on the run, errors intact.

    Override and weaken are different acts

The fork mattered most. A direction is a bet about how to solve the problem, not a visual theme, so it is a real stop rather than a default with an opt-out — and part of the cache key, so re-entering an unchanged stage returns what the reviewer approved rather than a generation that has quietly drifted.

When the reviewer was right and the rule was wrong

The Stage-2 contract permitted exactly two personas; the run below carries three, because all three users were interviewed directly. The validator was not modified — it still reports both errors, recorded as an authorised override. Loosen it in the moment and the record would show a clean run, with no trace that a judgment had been made.

DecisionWhat a person choseThe cost, recorded
personas Three, where the contract permits two — all three users were interviewed directly The validator still reports both persona-count errors, held as an authorised override on the run
direction A, B and C as a composite, rather than one of the three put forward Two page trees joined at a single link (08 → 04), which is what held ia_coherence to 0.85
platform Web only — chosen as web and iOS, then revised after Stage 4 had already gated A native iOS family was specified and passed, then deliberately cut: no participant described phone use
design system Material 3 as a baseline, because none was supplied Every value is a token name, so re-running against a real library remaps names and changes nothing structural
The run’s own decision register. The board this came from opens on this frame, not on the deliverables — “everything above is the output; this frame is the agenda.” Each row is a judgment the pipeline was forbidden to make, with what it cost written next to it. The platform row is the one I find most useful: a decision reversed after the stage had already passed, with the superseded screens left in the record rather than deleted.

The evidence spine

The one rule the rest hangs off

Nothing downstream may reference something the upstream stage did not produce. Applied at every boundary, that single constraint is what the pipeline is — and each link below is a check that runs before any human sees the artifact, not guidance in a prompt.

  1. A verbatim quote An exact substring of the research corpus — not a paraphrase, not a tidy-up.
  2. A theme Carries its quotes, and its frequency cannot exceed the number of sources the corpus has.
  3. A persona Names the theme it is grounded_in, and that theme has to be one Stage 1 produced.
  4. A How-Might-We Reframes exactly one theme. Every feature in the backlog answers exactly one HMW.
  5. A page Appears in the sitemap, and its primary journey has to be reachable by walking the prototype as a graph.
  6. A story Resolves to a real persona and a real page; every page is covered by a story carrying accessibility criteria.
  7. A metric Declared at ideation, planned exactly once in the evaluation plan. Declared and never planned for is never declared.

This is what makes the output arguable. Disagree with a theme and you can follow it back to the sentence someone actually said, so the disagreement is about evidence rather than taste.

ThemeSeverity · prevalenceThe quote it rests on
01 sourcing crowds out analysisHigh · 2 of 3“It’s probably 70% finding and formatting, and 30% actual analysis. I feel like a glorified data entry clerk for the first two days.” — P01
02 firm memory hunted manuallyHigh · 2 of 3“We lose massive leverage by not knowing what the firm already knows.” — P03
03 terms trapped in documentsHigh · 2 of 3“I want to be able to click on a leverage ratio metric and see a pop-up showing the exact sentence in the source credit agreement it came from.” — P02
04 one error voids the profileHigh · 2 of 3“If I catch an error like that, I lose trust in the whole profile.” — P02
05 email round-trips burn the deadlineMedium · 2 of 3“If they take 24 hours to reply, my clock is still ticking, but I can’t finish the model.” — P01
06 late, undifferentiated risk signalsHigh · 1 of 3“I don’t need another messy dashboard with 50 flashing lights.” — P03
Stage 1 output, with the spine visible. Every quote is machine-verified as an exact substring of the transcripts, and every participant is an identifier rather than a name. The judge scored this stage 0.88 against a 0.75 threshold and marked theme_distinctness its weakest dimension at 0.80 — themes 1 and 3 are adjacent, and a reviewer could fairly merge them. That criticism is part of the artifact, not something recovered afterwards.

Two gates a machine can run, and one it can’t

Structure, then honesty, then judgment

Every stage passes the same three checks. The split between them is the part I spent longest getting right.

  • Tier 1 — structural

    Deterministic Python. Schema, ranges, the verbatim-substring check, every link in the spine. It recomputes the scoring arithmetic rather than trusting the number it was handed.

    Cannot be argued with

  • Tier 2 — rubric

    Three to six weighted dimensions per stage, scored by a model told to read the artifact as if someone else wrote it. Every score cites evidence: a quote, a named field, or a named absence.

    Catches what parses but isn't honest

  • Then a person

    Reached only once the first two pass, so human attention is never spent on a stage that failed arithmetic. What they read is Markdown, written to be read.

    The gate the other two exist to protect

Structure goes to Tier 1, honesty goes to the judge. A validator can prove a quote is real; it cannot tell you whether six themes are six themes or one theme written six ways. A judge can, and cannot be trusted to count. Asking either to do the other's job is where this kind of system quietly rots.

A failure is not a dead end: the error list becomes the next attempt's input. A stage gets two attempts, and a third failure escalates to a person rather than retrying.

What each stage enforces, and what it judges

StageEnforced deterministicallyLeft to the judge
01 discovery Quotes are exact substrings; every source opens with a participant identifier; a corpus block names method and participant count Whether the declared bias is a real bias, and whether severity tracks consequence
02 strategy Two or three personas, exactly one primary; each grounded in a real theme; a four-to-seven-stage journey Whether a third persona is supported by the research, or padding
03 ideation Every feature answers one real HMW and carries a success metric with a name and a target; the scoring arithmetic is recomputed Whether the metric measures the outcome or just feature usage
04 wireframe Contrast cites a ratio or two named tokens; touch targets cite a measurement; no two pages share an accessibility block; all ten heuristics reviewed Whether the heuristic findings are about this design or would fit any product
05 delivery Every page covered by a story with accessibility criteria; stories that write data carry analytics events Whether the criteria came from that page's own spec or from a generic checklist
06 evaluation Tasks resolve to real journey stages and pages; every metric planned exactly once; unknown baselines declared Whether the tasks are goals or interface scripts — and whether the plan can fail

Every rule in that table is pinned by at least one fixture — a deliberately broken artifact that must fail, with the right diagnostic. Fifty run on every push. A rule that lives only in prose gets dropped the first time it is inconvenient.

A run end to end

NexusIntel · 3 interviews · 6 stages

NexusIntel is a sourcing and portfolio-analytics tool for a private-credit desk. Three people were interviewed: a screening associate, a credit risk reviewer and a managing director. The associate described spending the first two days of a deal window on data logistics — roughly seventy per cent finding and formatting, thirty analysis.

That corpus went in one end. What came out:

  • 6 themes carrying 18 quotes machine-verified as exact substrings, and 8 declared gaps
  • 3 personas, a 7-stage journey with five consecutive high-drop-off stages, and 5 How-Might-We statements
  • 11 scored features and 3 whole design directions
  • 8 page specs, 11 prototype flows, 17 developer-ready stories, and a test plan whose 11 metrics include 7 baselined unknown
  1. Stage 1 P01 · Screening Associate

    Assignment and orientation

    Receives an entity name, checks whether the company is public or private, and scopes how much of the structure will have to be built by hand.

    Apprehension — the size of the build is clear before any of it is possible Low drop-off
  2. Stage 2 P01 · Screening Associate

    Hunting internal precedent

    Searches the CRM, Salesforce and the credit document repository for prior firm contact, and asks colleagues where older coverage might sit.

    Low-grade doubt — he cannot tell the difference between no history and history he failed to find High drop-off
  3. Stage 3 P01 · Screening Associate

    Extracting terms from source documents

    Parses hundreds of pages of PDF agreements, draws the org chart in PowerPoint, copies financials into the Excel template.

    Grinding — the work is legible as effort and illegible as judgment High drop-off
  4. Stage 4 P01 · Screening Associate

    Modelling and thesis under a live clock

    Calculates leverage metrics, writes the investment thesis, emails the deal team for a missing cash flow statement — and waits.

    Pressure — the analysis he was hired for begins on the second night High drop-off
  5. Stage 5 P02 · Credit Risk Reviewer

    Risk review and verification

    Reads total leverage, interrogates the EBITDA add-backs, checks liquidity runway and the guarantee package, skims past the overview entirely.

    Guarded — reading for the one thing that will invalidate the rest High drop-off
  6. Stage 6 P02 + P01 · Both

    Defect return and rework loop

    She fixes minor issues herself to avoid a round of email, returns the file when the leverage math is wrong, and he reworks against a partly elapsed deadline.

    Strain on both sides — she is spending her time on his work, he is redoing work he thought was finished High drop-off
  7. Stage 7 P03 · Managing Director

    Post-close portfolio monitoring

    Receives borrower-submitted covenant figures quarterly, has them keyed into spreadsheets, and scans monitoring dashboards.

    Reactive — informed of conditions that have already settled Medium drop-off

Five consecutive high drop-off stages — the run’s central finding

The journey, current state over future state. The upper half of each column is the as-is stage Stage 2 built from the three interviews, with the emotion recorded against it and its drop-off risk. The lower half is the Stage 4 step that answers it, naming the screen that serves it and the Stage 3 feature that makes it possible. Read a column top to bottom and you get a friction point and the design’s response to it; read the top tier across and you get the finding the whole run turned on.
  • 01 Screening Queue /screening P01

    The family entry — every page is reachable from here.

    • 02 Precedent Search /precedent P01

      What the firm already knows about this entity. The RBAC wall between Private Equity and Liquid Strategies is load-bearing on this page.

    • 03 Document Extraction /profile/:id/extraction P01

      Reconcile each extracted term against its source passage, then commit.

    • 04 Borrower Profile /profile/:id P01

      The model, populated from committed terms.

      • 05 Corporate Structure /profile/:id/structure P02

        Ultimate parent, co-issuers, guarantors — which entities are on the hook.

      • 06 Risk Review /profile/:id/review P02

        Opens on leverage, then liquidity runway, then structure. Sign-off is individual, non-delegable and audited.

  • 07 Portfolio Watch /portfolio P03

    The attention band, capped at five items. Reached from the queue’s sidebar.

    • 08 Position Detail /portfolio/:positionId P03

      Covenant headroom against the threshold extracted at underwriting.

Stage 4 output: the information architecture. Eight pages, indented by hierarchy, the entry page shaded. Every page is reachable from the queue, and the profile is where four of the flows converge. The composite direction the reviewer chose is what pushed ia_coherence to 0.85 — the weakest dimension in a stage that scored 0.89 against a 0.80 threshold, and the information-architecture cost named in the register above. The eleven flows that wire these pages together are tabled further down.
The Risk Review page spec. A First Read row shows total leverage ratio 4.20x, liquidity runway 11 months, an incomplete guarantee package and zero unverifiable figures. Below it, two open threads — one marked blocking, questioning a 5.0m add-back that recurs in earlier years — and a Sign off control greyed out, labelled: disabled, 1 blocking thread.
Stage 4 output: the Risk Review page spec. Generated by the pipeline from the three interviews and approved at the stage gate, not drawn by hand afterwards. Every figure in the first read carries its source, and sign-off is held shut while a thread is blocking — which is the fix for the first heuristic finding further down this page.
  • The Screening Queue while loading: the three summary tiles show em-dashes instead of counts, with the message 'Please wait — this might take a few minutes' above a placeholder bar.
  • The Screening Queue when empty: 'No profiles assigned to you — profiles assigned to you will appear here, ordered by tightest remaining window', above a Start new profile button.
  • The Screening Queue after a failure: 'Your queue could not load — your active filter is kept. Retry to load the queue again', above a Retry button.
  • The Screening Queue populated: tiles reading 7 in flight, 3 blocked, 2 due within 24 hours, above four assigned profiles each showing its stage, hours remaining and blocker status.
  • The Screening Queue with a disabled action: the Chase control on the first profile shows a tooltip reading 'Re-sent 2h ago, chase again after 16:32'.
One page, five states. Left to right: loading, empty, error, populated, and a disabled action. Stage 4 cannot pass without them, which is the state_and_responsive dimension being checked rather than asserted. The last one is the reason the rule exists — a disabled control that says why it is disabled and when it comes back is a different design from one that is simply grey.

The reviewer took all three directions rather than one, which is why the design covers every HMW and all eleven features — at the information-architecture cost recorded in the register above.

FromTriggerTo
01 screening queueSelecting an assigned profile row04 borrower profile
01 screening queueSubmitting an entity name in the global search02 precedent search
01 screening queueSelecting Portfolio Watch in the primary sidebar07 portfolio watch
02 precedent searchAttaching the selected precedent set03 document extraction
03 document extractionCommitting accepted terms04 borrower profile
04 borrower profileSelecting View corporate structure05 corporate structure
04 borrower profileSubmitting for review06 risk review
05 corporate structureConfirming structure or selecting back04 borrower profile
06 risk reviewRecording sign-off01 screening queue
07 portfolio watchSelecting an attention item or position row08 position detail
08 position detailSelecting View underwriting profile04 borrower profile
The eleven prototype flows, as the validator reads them. Each one is a named trigger on a real page, which is what lets the reachability rule be a check rather than a metaphor: all eight pages are walkable from the entry point, four of them converge on the borrower profile, and the single cycle closes at sign-off. A page nobody can reach fails the stage.
The number the run argued with itself about

Stage 1 declares eight gaps against itself. The fourth reads: “No participant gave a volume figure — deals screened, profiles built, positions monitored. Any reach estimate downstream is an assumption.” Reach is what sets the ordering of the backlog, so the run carries that admission forward and scores itself down for it. The second gap is sharper still: the brief’s predictive deal-sourcing feature has no user evidence anywhere in the corpus, and the run says so rather than designing it anyway.

That is the behaviour I was trying to build. A backlog that announces which of its own numbers are invented is more useful than one that reads cleanly.

Then I reviewed it against my own practice

What the second contract changed

Once it was producing complete runs, I reviewed it the way I would review someone else's process. The spine held up. Three gaps were structural.

Accessibility was asserted and never verified. A page needed five non-empty accessibility strings, so “Meets WCAG AA” passed — and the rubric weighted it lowest of five dimensions while design-system fidelity carried the most. Across both completed runs, zero acceptance criteria mentioned accessibility.

Nothing said how you would know it worked. An impact score claims something moves; no stage named what. Features gained a success metric, and stories that write data gained analytics events.

The pipeline only ever generated. Research, strategy, ideation, wireframes, handoff, stop. No critique pass, no test plan, no loop back from evidence of use. A process that only generates cannot be wrong, which is not the same as being right. Stage 4 now self-critiques against the ten heuristics, and Stage 6 exists at all.

The reweighting

Stage 4 is the strictest gate in the system, and accessibility carried the least weight in it. That ordering said something out loud I would not have said.

ds_compliance 0.20
accessibility_rigor 0.20
ia_coherence 0.15
state_and_responsive 0.15
requirements 0.15
heuristic_rigor 0.15

Solid bar: weight now. Dashed marker: weight before. ▲ marks the two dimensions that also carry a hard pass threshold.

Accessibility went from lowest weight to joint-highest and gained a threshold it must clear on its own, so a stage can no longer average its way past it. Not a claim that it is worth exactly a fifth of the score — a correction of what the old ordering said.

The heuristic pass was the sharpest thing to come out of it. Run against a spec that had already cleared the old gate, it found six real problems:

Heuristic pass, against a spec that had already passed 
high   User control and freedom · 06 - Risk Review
        Sign off was irreversible and unconfirmed. A mis-click ended a
        twenty-minute review; recovery was administrative.
medium Error prevention · 06 - Risk Review
        Concurrent review was reported at sign-off, not prevented.
medium Consistency and standards · 08 - Position Detail
        Two controls named alike, one portfolio-wide and one position-only.

6 findings · all 6 fixed in the spec · 4 heuristics clean with reasons
The Position Detail page spec. A What Changed panel explains a 14% rise in transit times on lanes carrying 61% of group volume. Below, a covenant headroom meter reads 'at threshold, +0.05x headroom' with the credit agreement clause it derives from quoted underneath, direct exposure totalling 240m, and three contributing signals labelled primary driver, contributing and noise.
Position Detail, after the fix. The third finding was two controls named alike, one portfolio-wide and one position-only. Worth noting what survived the fix: the covenant threshold still quotes the clause it was extracted from at underwriting, so the number a reviewer acts on can be walked back to the sentence in the agreement. That is the evidence spine reaching the last page of the run.

Two more turned up for a duller reason: no tests, no CI. Two committed artifacts had drifted out of conformance with their own validators and nothing said so — I found them by running the validators, not by reading. Earlier runs were left alone: back-filling today's fields would mean inventing the kind of data this pipeline exists not to invent.

Reflection

Getting a model to produce a persona, a journey map or a page spec is close to free. Getting output you would be willing to hand a developer is entirely a question of what you refuse to accept. One caveat worth keeping: runs are driven through the skills conversationally, and the orchestration graph, though tested, does not yet execute end to end.

What it reinforced for me:

  • Decide early which judgments are not the machine's to make, then build the stop that enforces it. A process that never pauses for a person is not faster — it has moved the decision somewhere nobody signed for it.
  • Put the rule where it can be enforced. Anything that lives only in prose will be dropped the first time it is inconvenient, and nobody will notice.
  • Traceability is worth more than quality. An artifact you can argue with beats a better-written one you cannot check.