Netflix Junior UX Designer Interview Preparation Guide

Direct answer

Pick a project that genuinely needed more than one function, and be specific about two things: what YOU owned (not what 'the team' did), and the one concrete mechanism that determined whether the collaboration worked, such as a shared definition of done, a clear handoff point, or clarity on who decided what when opinions differed. Vague answers ('we communicated well') sound rehearsed; specific answers sound lived-in.

What the story needs to show

Your specific contribution. Interviewers are listening for what you personally decided or built, distinct from what your collaborators did. If every sentence is 'we', the interviewer cannot tell what you'd do differently on the next team.

A mechanism-level explanation. Organize the story around one of three lenses:

• Shared goal: did every function agree on what 'done' looked like and how success would be measured, or was each function quietly optimizing for its own definition?
• Interface or handoff: was there a clear point where work crossed from one function to another, and was that point actually defined, or did people guess?
• Decision rights: when functions disagreed, was it clear whose call it was, or did disagreement just stall until someone got tired of arguing?

Honesty if it's a struggle story. The question explicitly allows 'succeed or struggle'. A good struggle story ends on what you changed about the collaboration, not on who was at fault.

Worked example

Situation: [your team] needed to deliver [a feature or initiative] that required real work from [Team A, for example a design or research function] and [Team B, for example a data or infra function], against a fixed external date.
Task: your role was the one connecting the three groups, for example owning the shape of the interface between design and engineering, or owning how data requirements got translated into a schema.
Action: early on, each function had a different idea of what 'done' meant for their piece, which caused rework when the pieces met. You wrote a short one-page agreement naming the shared definition of done and who would sign off on each handoff, and used it to resolve the next two disagreements without a meeting.
Result: the project shipped on the revised date, and the agreement itself became something the group reused on the next cross-functional piece of work, which is the real marker of a story about redesigning the collaboration rather than just pushing through it.

To make that skeleton concrete rather than a fill-in-the-blank: picture a checkout redesign that needed real work from the design function and the payments engineering function, against a fixed external date tied to a promotional campaign launch. The specific disagreement was about what 'done' meant for the new payment-method selector: design considered the screen done once every state (loading, error, empty) matched the approved mockups pixel-for-pixel, while payments engineering considered it done once the integration correctly handled every payment-provider response code, even ones with no mockup drawn yet. That mismatch caused two rounds of rework when a payment-provider error state shipped without a design pass. The one-page agreement that resolved it included this line: 'A screen is done when it matches an approved mockup for every state the payments API can return, and any new state discovered after mockups are drawn triggers a joint 15-minute review before either side builds it.' That single sentence is what let the two functions stop re-litigating 'done' every time a new edge case appeared, and both sides signed off on it before the next round of work began.

Trade-offs and pitfalls

• A generic 'we all communicated well' answer with no mechanism is the single most common weak version of this story, avoid it.
• Over-crediting the team at the expense of your own specific contribution leaves the interviewer unable to evaluate you.
• If you pick a struggle story, resist framing it as the other function's fault. The senior version of this answer explains what you changed about how the groups worked together, not who dropped the ball.
• The strongest answers show you redesigning a structure (a handoff, a shared definition, a decision rule), not just working harder inside a broken one.

Direct answer

Progressive disclosure means showing the minimum someone needs to make their next decision first, then letting them opt into more detail only if they need it, rather than presenting every layer of a decision at once. For technical documentation, that means separating what we decided and why it matters from how it's actually implemented, and only showing the second layer to someone who asks for it.

Structured elaboration

Two concrete ways to build this into documentation:

1. A "decision, then detail" page structure. The top of the page states the decision and its business-relevant effect in one or two sentences. Directly below, an expandable or clearly linked section holds the reasoning (why this option over the alternatives, what constraint drove it), and a separate section holds the implementation (exact commands, config, code). A reader making a go/no-go call never has to scroll past architecture detail to find the decision.
2. Collapsed detail blocks inside a page that stays otherwise readable. Long code blocks, diagrams, or benchmark tables default to collapsed, with a label that tells the reader what's inside before they open it, not just "details." This keeps the page skimmable top to bottom for someone doing a first pass, while an engineer implementing the change can expand everything in order.
   Both work because they let the reader choose their own depth instead of the writer choosing it for them, and because the label on each layer, decision, why, how, tells the reader which layer they're in before they commit to reading it.

Worked example

A raw engineering note might read: "Switched to regional read replicas with async replication and connection pooling via PgBouncer to cut p95 read latency." Applied with progressive disclosure, the page becomes:
Top line (decision layer): "We added copies of the database closer to users in each region so read requests don't have to cross the country, which is what was making some pages feel slow for customers far from our main data center."
Expandable "why" layer: explains the latency problem was concentrated in specific regions and why a cache alone wasn't sufficient, still in plain language.
Expandable "implementation" layer, collapsed by default: regional read replicas (copies of the database kept near each user region), updated by async replication (the copy is written a short delay after the original, not instantly), and connection pooling via PgBouncer (a tool that reuses open database connections instead of opening a new one per request), plus config snippets and the failover procedure.
A reader deciding whether to approve the change never has to parse "PgBouncer" or "async replication" to get the decision; an engineer implementing it clicks straight through to exactly that.

Trade-offs and pitfalls

Progressive disclosure can misfire if the top layer is vague instead of just simple: "we improved performance" tells the reader nothing they can act on, while "reads are faster for users far from our main region" does. It also fails if the label on a collapsed section doesn't say what's inside; readers won't expand something called "details," so label it with what they'll actually get, for example "config and rollback steps." And it isn't free: every layer you maintain is another thing that can drift out of sync with the code, so it's worth it for docs people repeatedly return to, not a one-off internal note nobody will reread.

Direct answer

Good Gherkin (the plain-language, keyword-based syntax using Given, When, and Then, used to write Behavior-Driven Development scenarios so both non-engineers and test automation can read them) acceptance criteria describe observable behavior, not implementation, and cover the normal path, how filters combine, and the edge cases as separate, independently runnable scenarios rather than one long branching scenario, because each scenario should map to exactly one automated test.

Approach

Write one feature file for the search-filtering capability, break it into small scenarios (one behavior per scenario), use a Scenario Outline with an Examples table for input variations instead of duplicating near-identical scenarios by hand, and use a Background block for setup shared by every scenario.

Gherkin

Feature: Filtering search results by price range and minimum rating

  Background:
    Given the user is on the search results page
    And the results list contains items with a range of prices and ratings

  Scenario: Filter results by a single price range
    When the user selects the price range "$25-$50"
    Then only results priced between $25 and $50 are shown
    And the result count updates to reflect the filtered set

  Scenario: Selecting a second price range widens the results instead of narrowing them
    Given the price range "$25-$50" is selected
    When the user also selects the price range "$100-$200"
    Then results priced between $25 and $50 are shown
    And results priced between $100 and $200 are shown
    And a result priced $75 is not shown
    And the result count equals the number of items in either selected range

  Scenario: Deselecting one of two selected price ranges
    Given the price ranges "$25-$50" and "$100-$200" are both selected
    When the user deselects "$100-$200"
    Then only results priced between $25 and $50 are shown

  Scenario Outline: Filter results by minimum rating
    When the user sets the minimum rating filter to "<rating>"
    Then only results with a rating of "<rating>" stars or higher are shown

    Examples:
      | rating |
      | 3      |
      | 4      |
      | 5      |

  Scenario: Combine price range and minimum rating filters
    When the user selects the price range "$25-$50"
    And the user sets the minimum rating filter to "4"
    Then only results priced between $25 and $50 with a rating of 4 stars or higher are shown

  Scenario: Combine two price ranges with a minimum rating
    Given the price ranges "$25-$50" and "$100-$200" are both selected
    When the user sets the minimum rating filter to "4"
    Then only results in either selected price range with a rating of 4 stars or higher are shown
    And a result priced $30 with a rating of 3 stars is not shown
    And a result priced $150 with a rating of 5 stars is shown

  Scenario: No results match the combined filters
    Given no item in the catalog priced between $0 and $10 has a rating of 5 stars
    When the user selects the price range "$0-$10"
    And the user sets the minimum rating filter to "5"
    Then the results list shows an empty state with the message "No results match your filters"
    And the empty state includes a control to clear the active filters

  Scenario: Invalid custom price range is rejected
    When the user enters a custom minimum price of "50" and a custom maximum price of "10"
    Then an inline validation error is shown stating the minimum must be less than the maximum
    And the filter is not applied until the range is corrected

  Scenario: Mobile filter behavior uses a bottom sheet
    Given the viewport width is 375 pixels
    When the user taps "Filters"
    Then the price range and rating controls open in a full-height bottom sheet
    And applying the filters closes the sheet and scrolls the results list to the top

Key points

One scenario covers one behavior: the "combine filters" scenario exists separately from the two single-filter scenarios specifically to test the combined logic, not to re-test each filter individually. The Scenario Outline with Examples avoids writing three near-duplicate rating scenarios by hand and makes adding a new rating threshold trivial later. The empty-results scenario specifies the actual message and a recovery action, since "show an empty state" alone leaves the copy and the recovery path to be invented mid-build. The invalid-input scenario specifies when validation fires, before the filter applies, which is exactly the kind of detail that becomes a bug report later if left unstated. The mobile scenario is not "the same as desktop but smaller," it specifies a different interaction pattern (a bottom sheet) explicitly, since responsive behavior that changes the interaction model, not just the layout, is where handoff ambiguity usually lives. The two multi-range scenarios carry the single most important rule in the file, because "filter by multiple price ranges" is ambiguous by default and the two readings produce opposite products: selections within one filter combine with OR (a result in either band qualifies, so ticking a second band returns more results, not fewer), while different filters combine with AND (a result must sit in a selected band and meet the minimum rating). An engineer who reads the multi-select as AND ships a control that empties the list the moment a second band is ticked, which is a plausible enough reading that it happens regularly. Writing the union out as its own scenario, including an assertion about a price that falls in the gap between the two bands and a deselection scenario that proves the filter unwinds correctly, is what turns that rule from a sentence in a document into something QA can fail a build on. Complexity in the algorithmic sense does not apply to a specification document; the relevant cost is scenario-maintenance overhead as scenarios multiply, addressed below.

Edge cases

Covered here: no results after combining filters, an invalid manually entered range, and the mobile-specific interaction pattern. Not covered by this feature file but worth naming for a real handoff: filter persistence across a page reload or back-navigation, how an active filter interacts with pagination (does changing a filter reset the results to page one), and the band boundaries themselves, since adjacent options like "$25-$50" and "$50-$100" leave an item priced exactly $50.00 belonging to both, one, or neither depending on an inclusivity choice nobody has written down, and the answer also decides whether the two bands in the union scenario above can overlap at all. Those belong in additional scenarios, not left implicit, if the feature actually has them.

Trade-offs and pitfalls

Gherkin describes what should happen, never how; a scenario that reads like "click the button with this class name" has leaked implementation and will break the moment the implementation changes even when the intended behavior has not. Writing exhaustive scenarios for every price range times every rating becomes noise; use a Scenario Outline for genuine equivalence classes and hand-write only the combinations that test genuinely distinct behavior, like the combined-filter logic once, not exhaustively. And Gherkin is a specification, not a substitute for exploratory testing; it will not catch what nobody thought to write a scenario for, so pair it with real usability and QA testing rather than treating it as complete coverage.

Direct answer

Treat the prototype and the missing instrumentation as deliverables with their own owner, acceptance criteria, and a hard freeze date, not just line items in your timeline, and build in a dry run before real recruiting opens so gaps surface while there's still time to fix them, not mid-fieldwork.

Structured elaboration

1. Early scoping with design and engineering: agree on a fidelity matrix, meaning a shared list of which screens or flows need to be a real interactive prototype and which can stay a static mock, because insisting on full fidelity everywhere is usually the actual schedule risk.
2. Instrumentation spec: write down the exact user behaviors you need logged (which taps, which states, which drop-off points), and get engineering to confirm which of those are realistic to build by the freeze date. If something genuinely can't be instrumented in time, plan a manual fallback (an observer tally, screen recording) rather than quietly losing that data.
3. A hard prototype freeze date, set backwards from your recruiting start date, because you can't safely recruit for a study that might slip.
4. A dry run after the freeze but before real fieldwork: a handful of internal or friendly-user sessions whose only purpose is to catch prototype bugs and instrumentation gaps while you can still patch them.
5. A go or no-go checkpoint before you open full recruiting, so a broken dry run stops the study from launching on a date you already promised, rather than discovering the problem live.

Worked example

Say the study needs to run in six weeks. Week 1: the fidelity matrix and instrumentation spec get agreed between research, design, and engineering. Weeks 2 to 3: engineering builds. Week 4: freeze plus a dry run of five internal sessions; the dry run finds that a "save draft" action isn't logging an event at all. Engineering patches it in two days because it was caught early, not on day one of fieldwork. Week 5: a small pilot with three real users confirms the fix and the flow. Week 6: full fieldwork runs on schedule because the risky pieces were tested while there was still slack to fix them.

Trade-offs and pitfalls

Skipping the dry run is the most common shortcut under time pressure, and it's the one most likely to blow up the promised date, because instrumentation gaps or prototype bugs then surface mid-fieldwork when you can no longer recreate the missing data. A fidelity matrix that quietly defaults to "everything full-fidelity" recreates the same schedule risk you were trying to avoid. And if the researcher owns the timeline without engineering having agreed concrete acceptance criteria to build against, the target keeps moving and "the date you promised" stops being a real commitment.

Decompose by identifying the repeating visual groups in the mockup first, header row (avatar, title, overflow), tag row, and footer (actions, chart), then map each group to a component with a narrow API, and let a thin CardWrapper own only layout and selection state, not the content components' internals.

Component breakdown

flowchart TD
  C[DashboardCard] --> AV[Avatar]
  C --> TB[TitleBlock]
  C --> MT[MetadataTags]
  C --> AG[ActionGroup]
  C --> SP[Sparkline]
  AG --> A1[3 action buttons]

Worked example: the decomposition process

Reading the mockup top to bottom: the avatar, title, and an overflow affordance sit on one row (that's Avatar + TitleBlock, with the card itself deciding layout, not a new component). Tags form a second, clearly repeating row across cards, a natural MetadataTags unit. Three action buttons and the sparkline share the footer but are functionally unrelated, actions trigger commands, the chart displays data, so they become two separate components (ActionGroup, Sparkline) composed side by side by DashboardCard, rather than one "CardFooter" component that would force unrelated concerns to share a single API. Keeping Sparkline as its own component with a plain data: number[] prop (no data-fetching of its own) is what lets it be reused later in a non-card context, like a table row or a detail page, without the card's layout assumptions coming along for the ride.

Trade-offs and pitfalls

Giving Sparkline its own data-fetching hook tied to this dashboard's specific API endpoint, instead of a plain data prop, is a common shortcut that saves a few lines here and makes the component unusable anywhere the data doesn't arrive the same way. Hardcoding ActionGroup to exactly three buttons (matching today's mockup) instead of accepting an actions array breaks the first time a product needs a fourth action or wants to collapse extras into an overflow menu, forcing an API change that a slightly more general design would have avoided for free. And merging the footer into one component because "it's visually one row" optimizes for the current layout at the cost of reusing actions or the chart independently later.

Direct answer. Roughly 1 in 12 men and 1 in 200 women have some form of color vision deficiency (the most common being red-green: protanopia and deuteranopia), so any UI that encodes meaning through color alone, a red versus green status dot, a red line versus a green line on a chart, is invisible or ambiguous to a meaningful share of users. The fix is redundant encoding: pair every color-coded meaning with a non-color cue.

Redundant encoding strategies.

• Icons: a checkmark for success, a warning triangle for caution, an X for error, alongside (not instead of) the color.
• Labels/text: a visible "Active" or "Failed" label next to a status badge, so the meaning doesn't depend on correctly perceiving the color at all.
• Patterns/textures: for charts specifically, dashed versus solid versus dotted line styles, or hatching patterns on bar fills, distinguish series independent of hue.
• Position/shape: in a status list, consistent left-to-right ordering (worst to best) or distinct shapes (square vs. circle vs. triangle markers) give a third independent cue.

Testing tools and simulators. Chrome DevTools' Rendering panel has a built-in vision-deficiency emulator (Protanopia, Deuteranopia, Tritanopia, Achromatopsia) that simulates the page live; Sim Daltonism (macOS) and Color Oracle (cross-platform) do the same at the OS level for any application, not just a browser tab. Stark and axe DevTools both include a color-blindness simulation view alongside contrast checking.

Worked example. A dashboard status badge system using only red/green dots: under deuteranopia simulation, both colors desaturate toward a similar brownish-yellow, making "all systems operational" and "critical outage" visually indistinguishable at a glance. Adding a checkmark icon to the green state and a triangle-with-exclamation icon to the red state (plus the text label "Operational"/"Down") restores the distinction without removing the color entirely, since color still helps users without a color-vision deficiency scan faster.

Trade-offs and pitfalls. A common half-fix is choosing a "colorblind-safe" palette (e.g. blue/orange instead of red/green) without adding any non-color cue at all: that helps red-green deficiency specifically but still fails for low-vision users who may not distinguish any two similar-luminance hues, and it doesn't help at all if the page is later viewed in grayscale (some print/PDF export paths) or under bright glare where hue discrimination degrades for everyone.

Overview & goal
Test how users with motor impairments (e.g., tremor, limited dexterity, one-handed use) perform fine-touch gestures and identify failure modes to produce concrete design + engineering fixes.

Recruitment & channels

• Criteria: ages 18+, self-reported motor impairment affecting touch, a range of severity (mild/moderate/severe), including assistive-device users, cognitive ability to consent, smartphone familiarity.
• Channels: disability orgs (e.g., United Spinal, Cerebral Palsy alliances), clinics and occupational therapists (OTs, clinicians who work directly with patients on fine-motor and daily-living skills), accessibility mailing lists, social media groups, panels from previous research.
• Target n = 12-20 for qualitative depth across severity strata.

Consent & accommodations

• Plain-language consent; offer large-print + audio read-aloud.
• Pre-screen for fatigue, pain; schedule short sessions (30-45 min) with breaks.
• Pay participants and allow caregiver presence; offer remote or in-person based on preference and mobility.

Task design & alternative interactions

• Tasks: common fine-touch flows (pinch-to-zoom, drag-and-drop, small target tap, swipe with angle precision, multi-finger gestures).
• Scenarios: realistic tasks (selecting a small UI control, repositioning an item, confirming a modal).
• Provide alternative interactions: single-tap alternatives, long-press, voice commands, hardware-button shortcuts, configurable target sizes.
• Counterbalanced order; start with the baseline (current gestures), then alternatives.

Instrumentation & metrics

• Quantitative: success rate, time-on-task, error counts (mis-taps, aborted gestures), touch precision (distance from target centroid), gesture completion rate, number/force of correction attempts, number of retries, unintended activations.
• Sensors/logging: raw touch events with timestamps, pressure/size where available, heatmaps of touch points, accelerometer data if tremor analysis is desired.
• Qualitative: think-aloud, post-task SUS (System Usability Scale, a 10-question survey producing a 0-100 usability score) plus custom accessibility Likert questions, contextual interviews on fatigue and cognitive load.

Analysis & dev-facing recommendations

• Present issues as reproducible bug stories: "When required to perform a 2-finger pinch on targets under 24px, users with tremor failed 78% of the time, with reproduction steps and logs attached."
• Prioritize fixes by severity and impact: quick wins (increase touch target to 44-48px, add single-tap alternatives), medium (gesture fallbacks, adjustable dwell time), longer-term (gesture recognition tolerant to jitter, machine-learning smoothing).
• Provide implementation notes: use platform hit-area APIs, increase touch slop, debounce timing, expose settings (target size, gesture sensitivity), add telemetry events for rollout monitoring.
• Deliverables: annotated session clips, touch heatmaps, metric dashboards, accessibility acceptance criteria, and design tokens for the design system.

Outcome & next steps
Run iterative A/B tests with telemetry, validate improvements with the same cohort, and bake settings into the product's accessibility panel.

Direct answer

I'd take that feedback in without minimizing it or defaulting to "this style works for everyone else," since "effective for me" and "effective for someone from a different background" are genuinely different claims. I'd gather concrete perspective, from the mentee directly if the relationship allows it, and from someone who shares their background otherwise, then adapt specific mentoring behaviors rather than a vague resolution to "be more inclusive."

Structured elaboration

Take it in. Resist the instinct to explain that the same approach has worked for other mentees; that's true and irrelevant to whether it's working for this one. Treat the feedback as information about a real gap, not as an unfair standard.

Gather more perspective. Ask the mentee directly, in private, how they'd prefer to receive correction and how comfortable they feel pushing back, if the relationship supports that ask without putting them on the spot. Separately, talk to a colleague or mentor from a similar cultural background about norms you might be missing: directness versus indirectness in giving pushback, comfort raising disagreement with someone more senior, preference for private over public correction.

Adapt concretely. Check assumptions explicitly instead of relying on implicit norms you were mentored under yourself. State your intentions out loud rather than assuming they're obvious ("I want you to push back if you disagree, even if it doesn't feel natural"). Follow up later to check whether the adjustment actually landed, rather than assuming one conversation fixed it.

Worked example

I mentored a junior architect on a distributed team, based in a region where, I later confirmed, directly disagreeing with someone senior in a group setting is culturally uncomfortable. My default mentoring style was blunt, on-the-spot correction, the way I'd been mentored myself. Feedback came back to me, through their manager, that my style landed as intimidating rather than helpful, and that they were reluctant to ask clarifying questions or push back with me.

I didn't dismiss it as "everyone needs thicker skin," since their project outcomes, not my comfort, were what was actually at risk. I talked to another architect from a similar background about norms I might be missing, and asked my mentee directly, in a private 1:1, how they preferred to receive correction. Concretely I changed: gave feedback privately first even for small things, asked open questions instead of stating conclusions, and explicitly told them I wanted pushback even if it didn't feel natural rather than assuming that invitation was obvious. I checked in about a month later to ask whether it felt different. It did: the next design doc they brought me pushed back on my proposed API directly in the comments instead of silently implementing it as written, and that kind of pushback kept showing up over the following months, which is the outcome that actually mattered.

Trade-offs and pitfalls

Treating this as "just be nicer" instead of naming a specific behavioral gap means the change won't survive the next stressful review. Assuming a single cultural background applies uniformly to everyone from it just swaps one stereotype for another, so keep checking with the actual person rather than a generic rule about their background. Over-correcting into never giving direct feedback to anyone replaces one mismatch with a different one, for mentees who genuinely do want directness.

Direct answer
Bring a low-fidelity wireframe when the decision on the table is about flow, scope, or priority, since it is cheap to redo and does not tempt anyone into debating colors instead of the actual open question. Bring a high-fidelity mock when the decision is about how something looks or feels, or when you need a sign-off, legal, brand, an executive, that requires seeing something close to real. The risk runs in both directions: a rough sketch can get mistaken for "good enough, ship it," and a polished mock can get mistaken for "basically done already," so how you frame and present each one matters as much as which one you bring.

Structured elaboration

What each stakeholder should be giving you feedback on

Bring low-fidelity into a working session, not a readout
The engineer-feedback row above only happens if engineers see the low-fidelity work while it is still genuinely cheap to change, in a collaborative session where they can point out a technical constraint on the spot, not in a one-way presentation of a finished idea where raising a concern feels like derailing the meeting. A readout invites reactions to what is already decided; a working session invites input while decisions are still open.

Structure a multi-approach alignment meeting instead of single-artifact feedback
Bringing one low-fidelity option and asking "thoughts?" tends to produce either polite agreement or feedback anchored entirely on that one option's specific choices. Bringing 2 to 3 genuinely different low-fidelity directions side by side, explicitly framed as "these are directions, not decisions," gets people comparing trade-offs instead of nitpicking the only thing in front of them, which is what turns the session into actionable input rather than a scattered set of opinions.

Preventing the two mistaken-identity problems

• Rough sketch mistaken for final: keep low-fidelity work visually unambiguous as unfinished, hand-drawn style or greyscale-only, no real copy or brand colors, and say explicitly at the start of the meeting what kind of feedback you are and are not asking for.
• Polished mock mistaken for nearly done: pair a high-fidelity mock with a visible list of open engineering questions or a rough effort estimate, so people do not assume "it looks finished" means "it is nearly built."

Worked example
In a 30-minute session with 8 stakeholders, present 3 low-fidelity directions side by side for a checkout redesign, Option A tabs, Option B a collapsible filter drawer, Option C inline expandable rows, explicitly labeled as directions rather than decisions. Give each stakeholder 3 dot-votes to distribute across the 3 options however they like, up to 24 total votes across 8 people. Option B collects 14 of those 24 votes, clearly ahead of A's 6 and C's 4, a strong enough signal to converge on B for the next, higher-fidelity round, without a stakeholder feeling like their preferred option was dismissed by a single opinion rather than a group signal.

Trade-offs & pitfalls

• Showing only one option, at either fidelity, invites yes-or-no reactions instead of the comparative trade-off discussion that actually produces good decisions.
• A visually polished mock that has not been reviewed by engineering yet risks the room approving something that turns out to be significantly harder to build than it looks; pair it with at least a rough estimate.
• Framing low-fidelity work as "just a sketch, don't worry about it" too casually can backfire the other way, since some stakeholders will still treat whatever they saw first as the anchor for every future conversation about the feature.

Overview & Goals
Design a visual workflow builder that empowers non-technical users to compose conditional logic, nested steps, and approvals with clear affordances for testing, publishing, and error recovery. Prioritize discoverability, single-source-of-truth configuration, and developer-friendly diagnostics.

User flows (high-level)

1. Create

• Start: Dashboard → “New Workflow” → name/trigger modal
• Canvas opens with left palette (actions, conditions, approvals), central canvas, right configuration panel
• Drag node → inline tips guide building (smart defaults, required fields highlighted)

2. Test (Run in sandbox)

• Click “Run/Test” → run modal: choose test data or sample, step-through toggle, live logs
• Visual highlights current node, expanded config, variable inspector

3. Publish

• Click “Validate & Publish” → pre-publish validator lists warnings/errors, impact preview, version note, Publish confirms and creates immutable version

Wireframes (text)

• Canvas: top bar (Save, Test, Validate, Publish, Version), left palette vertical icons, canvas grid with swimlanes for nested groups, nodes with badges (if/then, approval), connectors with conditional labels
• Configuration panel (right): header node name, tabs (Settings, Inputs, Outputs, Permissions), inline help, sample test values, required-missing validation shown as red field + tooltip
• Run/Test modal: left column test data, center timeline with stepper and “Play/Pause/Step” controls, right column logs + variable inspector, bottom actions (Stop, Snapshot, Create Bug Report)

Validation, Runtime Failures & Rollback

• Validation (pre-publish): inline (real-time) and summary panel. Errors block publish; warnings optional. Provide explicit remediation links (jump-to-node).
• Runtime failures (post-publish): user-facing: notifications with failed step, “Retry from step”, “Rollback to vX”, and readable error message + suggested fix. Developer-facing: clickable “View debug” opens structured logs (stack, payload, timestamps), request/response, and replay token.
• Rollback: version history UI with diffs (visual side-by-side), one-click “Rollback” that creates new version marked “rollback of vN”. Support partial rollback by promoting earlier subflow.

Accessibility & Usability

• Keyboard support, ARIA (labels that describe custom controls to screen readers) labels for nodes, color-blind friendly palettes, concise microcopy, onboarding walkthrough, contextual help.

Developer Handoffs

• Deliver component specs (node props, events), telemetry contract (events for validation, runtime failures, rollbacks), and sample API payloads for replay.