Human QA sample report.
A practical fix plan.
Atlas Workspace · Example release 0.9.0-rc2
September 10, 2026 · 17-page sample report · 12 prioritized records
01. Executive decision
Fix signup and invitations. Keep billing on hold.
The scenario’s core workflow has a useful foundation. Resolve the two High functional defects, verify the affected journeys and make interrupted work recoverable. A paid launch requires evidence for purchase, access, cancellation and downgrade.
12 records: 3 High, 6 Medium and 3 Low. The third High record is an untested paid-readiness gate. Readability and returning-user value require measurement or research. No numerical product score or conversion-loss estimate is implied.
02. Scope and coverage
The full PDF covers onboarding, first-project setup, task creation, invitations, browser history, offline recovery, keyboard use, responsive readability, exports and paid-offer readiness. It includes a journey matrix, strengths to preserve, detailed findings, four labeled evidence schematics, role ownership and retest acceptance.
Strengths to preserve: the modeled first-task flow, retained drafts during failure, core export content, a useful free path and clear billing-off messaging.
03. Prioritized findings
An invalid email clears the entire signup form
- Owner: Frontend engineering
- Where: /signup · desktop and mobile
- Status: Open in scenario
Reproduce
Enter a name, company and password. Enter an email without a domain. Select Create account. Correct the email and attempt to continue.
Why it matters
Account creation becomes repeat work at the first commitment point. Abandonment is a plausible consequence; this sample assigns no conversion-loss estimate.
Observed in scenario
The form returns to an empty state with a general error. Valid name and company values are lost along with the invalid email.
Recommended change
Preserve form state through validation failure. Attach the error to the field, move focus appropriately and keep the submit action available after correction.
Expected
Keep appropriate non-sensitive values, identify the email error beside its field and let the person correct it. Apply the product’s password-handling policy.
Retest acceptance
Invalid email produces a field-specific error. Name and company remain unchanged. Correcting the email creates one account; keyboard and narrow-screen paths also succeed.
Evidence: E-01 · schematic on page 12
Repeated invitation clicks create duplicate pending invites
- Owner: Frontend + backend engineering
- Where: /workspace/setup · Invite teammates
- Status: Open in scenario
Reproduce
Enter one teammate email. On a slow connection, select Send invite twice before the first response. Open the pending-invitations list.
Why it matters
An uncertain action becomes an untidy team record and creates avoidable cleanup. Potential duplicate emails require a separate delivery check.
Observed in scenario
Recommended change
Add visible pending/success/failure states and protect the write against retries. Provide a deliberate resend action for an existing invitation.
Expected
A pending state appears immediately. One deliberate action creates one invitation. Repeated requests cannot create duplicate active invitations.
Retest acceptance
Double-click, keyboard repeat and retry after a delayed response each leave one pending invitation. A failed request can be retried. Resend does not create a second member record.
Evidence: E-02 · schematic on page 12
The paid account lifecycle has no acceptance evidence
- Owner: Product + billing engineering
- Where: /settings/billing · Pro preview
- Status: Untested in scenario
Reproduce
Open the Pro offer from a free workspace. Inspect upgrade, account management and the stated access rules. Review the proposed purchase-to-cancellation test plan.
Why it matters
Paid readiness cannot be established. The informational preview may remain available; the gap is a launch requirement, not evidence of an incorrect charge.
Observed in scenario
The scenario includes an informational offer with billing off. Purchase, entitlement activation, renewal, recovery, cancellation and downgrade have no execution record.
Recommended change
Define plan limits and cancellation behavior. Complete authorized sandbox lifecycle tests, including provider events and access readback, before a limited paid pilot.
Expected
Before billing opens, the service, checkout terms and account lifecycle work together and have a traceable acceptance record.
Retest acceptance
Purchase grants the correct access once; retries do not duplicate it. Cancel stops renewal. The access-end date is clear, and downgrade preserves the agreed read/export path.
Evidence: No transaction or provider receipt supplied
Browser Back exits workspace setup
- Owner: Frontend engineering
- Where: /workspace/setup · step 3 of 4
- Status: Open in scenario
Reproduce
Advance from workspace details to teammate invitations and then the first project. Wait for the saved indicator. Press browser Back, then Forward.
Why it matters
A person trying to correct an earlier answer leaves setup unexpectedly. The product asks them to reconstruct where they were.
Observed in scenario
Back returns to the dashboard rather than the previous setup step. Forward restores the third step. The scenario does not establish loss of settled saved data.
Recommended change
Represent setup steps in navigation state and restore both the step and its saved values when history changes.
Expected
Browser navigation follows the visible step sequence and retains completed values. The in-app Back control and browser history have consistent meaning.
Retest acceptance
Steps 1 → 2 → 3 reverse to 2 → 1 and move forward again with values retained. Repeat after reload. Dashboard history still behaves correctly.
Evidence: Required: before/after route and retained-state record
A failed save exposes an error with no recovery guidance
- Owner: Frontend engineering + UX writing
- Where: /projects/launch · task editor
- Status: Open in scenario
Reproduce
Open a task and change its description. Make the browser offline. Select Save changes. Restore the connection, retry, wait for success and reload.
Why it matters
The person cannot tell whether it is safe to close the editor. The defect is unclear recovery; the retained draft should be preserved.
Observed in scenario
The editor shows “Failed to fetch.” The draft remains in the open form. A settled retry retains the change in the modeled recovery path.
Recommended change
Use: “We couldn’t save your changes. They’re still in this open window. Reconnect, then try again.” Offer Retry and keep the editor open on failure.
Expected
Explain that saving failed, where the draft remains and how to retry. Show saved confirmation only after the write completes.
Retest acceptance
Offline save has no success state. Draft text remains exact. Reconnect and Retry complete one update; reload shows the same text. Closing an unsaved draft asks for confirmation.
Evidence: E-03 · schematic on page 13
The task dialog loses the keyboard’s place
- Owner: Frontend engineering + accessibility QA
- Where: /projects/launch · Edit task dialog
- Status: Open in scenario
Reproduce
Use Tab to focus Edit task and press Enter. Continue tabbing through the dialog. Press Escape and attempt to continue from the task card.
Why it matters
The visible task and keyboard location disagree. A keyboard user may interact with the wrong controls or lose the path back to their work.
Observed in scenario
Focus remains on the page behind the open dialog. Tabbing reaches background controls. Closing the dialog does not return focus to Edit task.
Recommended change
Use a named dialog with deliberate initial focus, contained tab order and focus restoration. Keep unsaved-change confirmation in the same interaction sequence.
Expected
Opening the dialog moves focus into it. Keyboard movement stays within the active modal. Closing returns focus to its initiating control.
Retest acceptance
Open, edit, save, cancel and Escape work with keyboard alone. Focus stays visible, never reaches the background while modal, and returns to the correct task control.
Evidence: E-04 · schematic on page 13
Secondary labels are hard to distinguish at narrow widths
- Owner: Product design + accessibility QA
- Where: /projects · mobile navigation and metadata
- Status: Needs measurement in scenario
Reproduce
Open Projects at a narrow viewport. Inspect inactive navigation, task due dates and help links against their backgrounds. Repeat with larger text and reduced brightness.
Why it matters
People may miss a due date or navigation option. Confirm the concern with measurements and assistive-technology testing before assigning a standards failure.
Observed in scenario
The scenario uses small, muted secondary labels that lose visual prominence. No measured contrast ratio or automated accessibility result is supplied.
Recommended change
Measure the actual combinations, adjust text tokens and review type size. Verify across light/dark states if both are offered.
Expected
Navigation and task context remain readable, including secondary states. Active and inactive controls remain distinct without relying on faint text.
Retest acceptance
Record before/after measurements against the agreed accessibility target. At larger text, labels remain readable and controls do not overlap. Keep measured results with the retest.
Evidence: Required: exact text/background pairs and font sizes
An empty project gives the owner no next action
- Owner: Product design + frontend engineering
- Where: /projects/new · zero-task state
- Status: Open in scenario
Reproduce
Create a workspace and its first project. Skip teammate invitations. Open the project before adding any tasks.
Why it matters
A new owner has finished setup but still needs to work out how to use the product. The screen leaves the first useful task to discovery.
Observed in scenario
A blank board shows “No data.” The primary Add task action is available only in a compact toolbar, with no explanation of how to start.
Recommended change
Add “Start with one task” and a visible Create task action. Offer an optional example without filling the workspace with unexplained sample data.
Expected
The empty state explains what belongs here and offers a clear action that produces the first useful result.
Retest acceptance
An owner can create and reopen the first task from the empty state. The message changes after creation; search-empty and permission-empty states use separate explanations.
Evidence: Required: first-project empty-state capture
Returning owners get activity, but no clear priority
- Owner: Product design + research
- Where: Product design + research
- Status: Hypothesis in scenario
Reproduce
Create a project, assign tasks and leave one invitation pending. Return to the dashboard the next day or use seeded equivalent state for interface review.
Why it matters
The return visit may feel like starting from scratch. This is a design hypothesis; seeded or simulated days cannot establish actual retention.
Observed in scenario
Activity, workspace settings and project cards have equal weight. Nothing summarizes overdue work, pending invitations or the next useful action.
Recommended change
Prioritize a small, factual “Needs your attention” group. Use real task and invitation states; let users dismiss items that are irrelevant.
Expected
The dashboard helps the owner understand what changed and choose a relevant next step, while preserving access to the full project list.
Retest acceptance
In formative research, returning owners can explain what needs attention and complete a chosen next action. Observe real repeat use before attributing a retention benefit.
Evidence: Required: target-user return-session observation
The saved toast briefly covers project navigation
- Owner: Frontend engineering
- Where: /projects/launch · after task save
- Status: Open in scenario
Reproduce
Save a task, then immediately select the neighboring project-navigation link while the success toast is visible.
Why it matters
A successful action is followed by a brief dead end. The scenario shows interruption rather than lost work.
Observed in scenario
The toast sits over the navigation target and receives the click. Once it disappears, navigation works normally.
Recommended change
Move confirmation into a reserved message area or a location that does not overlap controls. Avoid a focus change for passive success feedback.
Expected
Confirmation remains visible without covering the next likely action or preventing pointer and keyboard navigation.
Retest acceptance
After save, the same navigation target works immediately with pointer and keyboard. The message remains available long enough to read and does not cover mobile controls.
Evidence: Required: overlap capture and pointer-target check
CSV headers obscure otherwise usable task data
- Owner: Backend engineering + product
- Where: /projects/launch/export · CSV
- Status: Open in scenario
Reproduce
Create a task with an owner and due date, then export the project. Open the downloaded CSV and compare it with the visible task.
Why it matters
Someone reviewing or handing off the file needs additional interpretation. This is an export-semantic issue, not a broken download.
Observed in scenario
The modeled export retains task content but labels fields with internal keys such as assignee_id and due_at, without a human-readable owner or timezone context.
Recommended change
Add readable column names and owner display values alongside identifiers. Define date formatting and timezone behavior in the export contract.
Expected
Exported records remain useful outside the app. Names, stable identifiers and date/time meaning are clear.
Retest acceptance
Compare Unicode text, commas, line breaks, unassigned tasks and due dates against source records. Content remains exact; spreadsheet opening does not change intended values.
Evidence: Required: actual downloaded CSV and source record comparison
Task and item labels describe the same object
- Owner: UX writing + frontend engineering
- Where: Project board, creation dialog and confirmation
- Status: Open in scenario
Reproduce
Open the board, create a task, save it and inspect its confirmation and empty-state messages.
Why it matters
A small terminology mismatch adds avoidable interpretation during onboarding and makes help documentation harder to follow.
Observed in scenario
The board says Add task, the dialog says New item, and confirmation says Record created. Each refers to the same project task.
Recommended change
Use task consistently: Create task, Task details and Task created. Apply the same vocabulary to validation, search and export help.
Expected
The same object keeps the same name throughout the journey. Confirmation describes the result in the user’s vocabulary.
Retest acceptance
Review the complete create/edit/delete journey and associated help. Task is used consistently, while project and workspace retain their distinct meanings.
Evidence: Required: label inventory across the task journey
04. Delivery sequence
Start with signup state and duplicate invitations. Then address navigation, recovery and keyboard access, followed by readability, empty states, exports and terminology. Product and research own the return-experience hypothesis. Keep the paid lifecycle on a separate pre-billing acceptance track.
05. Retest and release
Record the candidate build, environment, exact reproduction and outcome for each finding. Test the failed path and its adjacent valid path. Use Pass, Fail, Blocked or Not retested; record accepted risks separately. The release owner makes the launch decision with remaining limits visible.
Your engineers can use these records directly. Odesa implementation support can be scoped separately against the same acceptance criteria.