Linear application practice

Start with the user expectation. The person wants to capture a thought quickly and continue working. A slow confirmation can interrupt that flow, but a misleading success state creates uncertainty and duplicates. State the tradeoff before selecting an implementation.

Define the relevant states: drafting, submitting, confirmed, failed, and possibly pending retry. Decide what information remains available in each state. If the request fails, the user's text should not disappear merely because the interface optimistically displayed the issue. Explain what happens when the user closes the dialog or reloads the page.

Design a small recovery path. The user should understand whether retrying is safe and whether the original request might already have succeeded. In a prototype, use a stable request identifier or another explicit mechanism to manage repeated submissions. Do not claim a front-end flag alone guarantees exactly-once behavior across every failure boundary.

Test keyboard flow, focus placement, and status announcements as part of usability rather than as cosmetic polish. A notification that appears briefly in a corner may be insufficient for someone who cannot see it or is working without a pointer. Ask a reviewer to complete the task using only the keyboard and describe where they lose context.

Introduce difficult cases: a slow response, an interrupted connection, a duplicate click, a successful server operation followed by a lost response, and a retry after the title has changed. Record the behavior you intend in each case. You do not need to solve every distributed-systems problem, but you should be honest about the guarantees of your small design.

Keep scope narrow. Do not add a new notification center, an AI issue writer, and a workflow editor to demonstrate ambition. A focused fix with clear behavior is a stronger case than a large prototype whose core interaction remains unreliable.

For engineering, implement a testable state model and explain server/client responsibilities. For design, show the interaction sequence, recovery, and accessibility considerations. For product, explain priority and the evidence that this problem deserves attention. For support, write a diagnostic report and a customer explanation that does not promise a fix before it exists.

Measure successful capture, unintended duplicates, recoverability, and time to understand the current state. Distinguish simulated test results from production impact. A small usability session can reveal confusion, but it cannot establish a broad retention improvement.

Finish with a short decision record: what you chose, what you rejected, what remains uncertain, and what would justify revisiting the design. This demonstrates focus and craftsmanship without copying another product's visual language.

Second-stage test: recover an issue draft without creating a duplicate

Extend the offline issue-capture case so a user retries after receiving an ambiguous synchronization message. Distinguish a saved local draft, an attempted submission and a confirmed server record.

Now let two devices edit the same draft. Explain the conflict behavior and how the interface avoids silently losing a meaningful edit. Resist adding a complex collaboration system unless the defined user need requires it.

Deliver a small state diagram and a focused test matrix. A strong result makes the difficult state understandable while keeping the common path simple; visual similarity to Linear's interface is not the evaluation criterion.