What should change in the component?
Turn a local correction into a specific, testable handoff.
The question
Four ParcelNest screens reuse the same address field. Each uses color-only errors and hides the recovery action. One screen has a quick patch; the component still has the defect.
- Component
- AddressField has empty, editing, lookup-failed and confirmed states.
- Local patch
- Booking screen adds a text error. Returns, account settings and pickup editing still use the old behavior.
- Constraint
- The shared fix must preserve labels and input values and must be checked in all four contexts.
“What should change in the component?”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: Choose the owner of the correction
What would you do here? Open the move you’d make.
Copy the one-screen patch into three more pages.
Tempting, but it misses something. That leaves several places to maintain the same behavior.
Correct the component state and check all uses.
The strong move. The fix belongs where the repeated behavior is defined.
Rename the component without changing the behavior.
Tempting, but it misses something. A name does not repair a blocked task.
See how a strong candidate says it
“Fix the shared field's error and recovery behavior, then check its consumers.”
Why it works: The failure is repeated in the same component state.
Step 2: Describe behavior, not only pixels
What would you do here? Open the move you’d make.
Hand off a screenshot with a red border.
Tempting, but it misses something. It omits state transitions and recovery.
Write a short state-and-behavior contract.
The strong move. Engineering and design can test the same expected outcome.
Ask engineering to make it accessible.
Tempting, but it misses something. The request lacks the concrete behavior to verify.
See how a strong candidate says it
“Specify the error text, accessible relationship, recovery action and preserved value.”
Why it works: A red rectangle does not define the interaction.
Step 3: Check the composed screens
What would you do here? Open the move you’d make.
Run only the default component screenshot.
Tempting, but it misses something. It does not cover failure or composition.
Approve because the component now has an error prop.
Tempting, but it misses something. An available prop does not prove the consumer uses it.
Test the failure and recovery in all four contexts.
The strong move. This tests the user-facing behavior where it appears.
See how a strong candidate says it
“Exercise lookup failure and recovery on booking, returns, settings and editing.”
Why it works: A component check can pass while a screen hides its action or resets its value.
Step 4: Record a real exception
What would you do here? Open the move you’d make.
Force every screen into the same layout regardless of task.
Tempting, but it misses something. The same behavior may need different presentation.
Document the exception and test the equivalent route.
The strong move. The alternative stays deliberate and accountable.
Leave the old failure because one screen is unusual.
Tempting, but it misses something. A difference in context does not excuse a blocked task.
See how a strong candidate says it
“If a screen cannot use the common recovery path, name the reason and verify its alternative.”
Why it works: Consistency serves the task; it is not a reason to force a wrong interaction.
The answer, in short
- Decision
- Correct the shared failure state and verify it in each used context.
- Because
- The fix addresses the repeated behavior and the actual screens that expose it.
- What would change it
- The failures have different causes and a single component change would harm a valid use.
Common traps
- Treating a Figma component as proof of shipped behavior.
- Maintaining silent exceptions without a working alternative.
Check your answer
- What state changes and what stays preserved?
- Who owns the behavior?
- Have the real consumer screens been checked?
- Does every exception have a tested route?
Last reviewed Nov 10, 2026