Start a login redesign with two explicit agreements: which parts of the interface may change, and which authentication behaviors must remain fixed. Give the reviewer a way to check both. A clearer layout still needs evidence that the login contract survives the patch.
Suppose the assignment is to improve labels, focus visibility, keyboard navigation, and validation messages. Keep that objective specific. Changes to session settings, token parsing, redirect rules, or authentication error codes require a separate decision, even when they appear convenient during the redesign.
Name the behavior that must stay fixed
Replace “keep authentication secure” with a list of preserved contracts. Identify token handling, session lifetime, cookie settings, redirect validation, and error responses. Point to the code, configuration, and existing tests that establish the current behavior.
For each item, record what the UI is allowed to display and what it must continue sending or receiving. An error message can become easier to understand while the underlying error code stays unchanged. A component can be reorganized while preserving the request fields expected by the login endpoint.
Resolve ambiguity before editing. If the brief asks for a different session duration or a new redirect destination, that is an additional behavioral requirement. Assign it an owner and review plan rather than absorbing it into the visual work.
Draw a boundary around the editable surface
List the login components and styles that may change. List supporting modules that may be read to understand the flow. Identify protected authentication code and configuration that the task does not authorize anyone to modify.
A compact review map can look like this:
| Area | Treatment for this assignment |
|---|---|
| Login component structure and layout | Editable within the agreed behavior |
| Labels, focus styles, and validation display | Editable with interaction checks |
| Authentication client and response contract | Reference material; preserve behavior |
| Token parsing and session configuration | Protected from modification |
| Redirect validation and authentication error codes | Protected from modification |
Replace these categories with the repository's actual paths. A folder name alone may hide shared behavior, so inspect imports and configuration dependencies before declaring the boundary complete.
Include tests in the map. Permit focused interface checks while preserving the existing authentication suite and its expected outcomes. A failing baseline check needs an explanation; weakening its assertion changes the evidence available to the reviewer.
Restrict access before work begins
Make the environment support the written boundary. Limit write access to the permitted login surface where practical. Restrict tools, credentials, and network access to what the assignment requires. Use a disposable environment and non-production credentials for any execution.
Read access and write access serve different purposes. The agent may need to inspect a response type without gaining permission to rewrite the authentication client. If the environment cannot enforce the intended separation fully, document that limitation and define how protected changes will be detected.
A changed-files check can help identify an unexpected edit, but it does not prove that behavior stayed fixed. A permitted component can still construct a different request or choose a different redirect target. Combine access limits, diff review, and behavior checks.
Review the interaction as well as the appearance
Define the intended keyboard path through the page. Check that each input has an understandable label, focus remains visible, and controls can be reached and activated in the expected order. Inspect how validation feedback relates to the affected field.
Choose states that expose the redesigned behavior: an untouched form, an invalid submission, a rejected login, a pending request, and the successful path where the test environment supports it. Use the application's established contracts to decide the expected response in each state.
For example, moving an error summary should preserve the association between a field and its message. Reordering components should preserve the intended focus sequence. Changing button styling should preserve the control's submission behavior.
Include narrow layouts and longer labels when the design must support them. A screenshot can show clipping or overlap; interaction checks are needed to establish whether users can reach the control and understand its state.
Trace the authentication boundary through the diff
Read the request-building path even when the patch stays within permitted files. Compare field names, submission conditions, response handling, and redirect selection with the original contract. Check whether a new shared helper or dependency reaches protected behavior indirectly.
Inspect the complete changed-files list, including test expectations and configuration. Ask why each edit belongs in the login redesign. A token or session file change should trigger the agreed rejection or escalation rule.
Require the existing authentication checks to retain their meaning. Record which tests were selected and what remains outside their coverage. Passing checks provide evidence about those cases; they do not establish that every authentication behavior is unchanged.
Stop when the UI task needs a protocol decision
Define the escalation before it is needed. If the proposed improvement requires different error codes, token handling, session lifetime, or redirect validation, pause that part of the work and describe the dependency.
The report should name the intended user benefit, the protected behavior involved, and the decision required. Offer an interface-only alternative when one preserves the contract. The owner can then keep the original boundary or authorize a separate change with appropriate checks.
Avoid making a small protected edit first and requesting approval afterward. That leaves the reviewer assessing a different task from the one originally assigned.
Finish with a reviewable acceptance note
Return the changed files, preserved contracts, interface checks, authentication evidence, and remaining gaps. Distinguish proposed checks from observed results. If keyboard behavior or an authentication route remains unverified, name the missing evidence and its next owner.
The approving reviewer owns confirming that protected files and behaviors received the agreed scrutiny. Release decisions should also identify who responds to an unexpected login failure and what stop or recovery action applies.
Accept the redesign when the accessibility improvement is clear, the authentication boundary has been checked, and unresolved risks have an accountable next step.
The Agentic Developer Interview includes practice cards on preserving authentication behavior during a login redesign, defining module boundaries, and escalating changes outside the authorized scope.