Skip to content

Study Management — Claude Design Iteration Handoff

Mandatory workflow

Claude Code owns repository inspection, evidence capture, planning-file updates, and eventual implementation. The visual and interaction iteration in this handoff must be performed with Claude Design specifically. Do not substitute a general-purpose coding agent, generate production Angular code as a mockup, or treat the current PR #2990 preview as the selected design.

The sequence is:

Claude Code: verify baseline and capture authenticated current screens
Claude Design: low-fidelity alternatives across all three routes
User review: select/recombine a direction
Claude Design: high-fidelity responsive and state-complete iteration
Claude Code: accessibility/technical feasibility review and decision record
User approval
Claude Code: phased implementation PRs from the approved artefacts

No production implementation begins before the user approves the final Claude Design iteration.

Source material

Claude Code must give Claude Design these complete inputs:

  1. Study Management programme
  2. Current-state gap analysis and product design
  3. Phased implementation plan
  4. Material 3 migration contract
  5. Material 3 technical plan
  6. authenticated screenshots of the current Study library/All Studies, Systematic Searches, Bulk Update dialog, active Search Import, Risk of Bias history, expanded Bulk PDF detail, and adaptive project navigation
  7. environment version, SHA, flags, viewport, zoom, user role, and permissions for each capture

Claude Design should also receive the current SyRF logo, icon set, typography, and emitted Material system tokens. It must not infer a new brand or token namespace.

Settled information architecture

Do not reopen route naming unless evidence reveals a serious usability or domain error:

Navigation Page title Canonical route Ownership
Library Study library /projects/:projectId/studies Study records, filters, Bulk Update launch, current/latest update summary
Searches Systematic searches /projects/:projectId/searches Search creation/management and current/latest contextual operation state
Processing Processing activity /projects/:projectId/processing Canonical read-only history across permitted long-running operations

The navigation group is Study management. The legacy /projects/:projectId/admin/systematic-searches URL redirects to Searches during rollout.

Contextual pages show current/latest operation summaries and links to filtered Processing views. They do not duplicate complete history tables. Commands remain beside the object they affect: Bulk Update in Library; search import, Bulk PDF, and Risk of Bias commands in Searches.

Claude Design brief

Use this prompt verbatim as the starting request, followed by the supplied documents and captures:

Design and iterate the Study management area for SyRF, an Angular Material application used by
systematic-review researchers. Use Claude Design for the design work.

The information architecture is settled:
- Library / Study library — /projects/:projectId/studies
- Searches / Systematic searches — /projects/:projectId/searches
- Processing / Processing activity — /projects/:projectId/processing

Library and Searches own domain actions and show only current/latest contextual processing.
Processing is the canonical, read-only cross-type history and links back to the owning context.

First inspect the attached plans, Material 3 contract, screenshots, tokens, and realistic fixture
data. State contradictions or missing evidence without inventing fields or permissions.

Iteration 1: produce three low-fidelity systems, not three isolated Processing pages. Each system
must show:
1. the adaptive Study management navigation;
2. Library actions plus a current/latest Bulk Update summary;
3. Searches with current/latest Search Import, Bulk PDF, and Risk of Bias state;
4. Processing filters, result count, list/detail, empty/loading/error/reconnecting states; and
5. contextual links between the three routes.

Compare the systems for discoverability, scan speed, domain clarity, duplicated information,
mobile/high-zoom behaviour, accessibility, implementation complexity, and fit with SyRF's merged
Material 3 contract. Recommend a direction but wait for user selection before high fidelity.

Iteration 2: after user selection, produce an integrated high-fidelity design at 1440px, 768px,
and 320px, plus 200% and 400% zoom/reflow annotations. Include keyboard focus, screen-reader
names/live announcements, reduced motion, forced colours/high contrast, long names, large error
sets, missing timestamps/owners/totals, unknown statuses, and focused rows receiving live updates.

Use exact raw status text. Common status grouping is secondary. Never show a year-one/epoch date,
invent a percentage or person, map unknown to Running, or expose cancel/retry unless the supplied
capability matrix supports it. Use emitted --mat-sys-* roles and supported --syrf-* domain roles;
do not create new tokens, branding, fonts, private Material variables, or Bootstrap dependencies.

Return the required artefacts and a decision log. Do not generate production Angular code.

Low-fidelity alternatives to explore

Claude Design has freedom within the settled architecture, but the first iteration must test:

  1. Compact contextual summaries + operational Processing table — the baseline for fast scanning on desktop, with cards at narrow/high zoom.
  2. Inline activity strips + expandable Processing cards — prioritises continuity between owning context and history.
  3. Attention-first summaries + type-aware Processing list — prioritises active and failed work while retaining a clear Show all history path.

The result may combine strengths, but it must choose one consistent summary, status, progress, error, and detail language across all three routes.

Required fixture coverage

Use realistic examples for:

  • Search Import: Saving 8,420 / 12,000; Parse error with 26 errors; owner unavailable;
  • Bulk Update: Validating 2,104 / 5,000; completed with 1,180 changed and 40 unmatched; no-op completion with all rows parsed and zero changed; invalid/missing last-modified time;
  • Risk of Bias: Model processing 78 / 120; Timed out; Cancelled; owner unavailable;
  • Bulk PDF: Scanning indeterminate; infected archive/report; cancelled multipart upload; and
  • an unknown future status value, missing context, zero/missing total, and a 150-line error list.

Required artefacts

Claude Design must return:

  • three labelled low-fidelity systems and comparison matrix;
  • the user's selected/recombined direction recorded explicitly;
  • high-fidelity Library, Searches, and Processing designs for all required widths/zoom states;
  • component and content inventory;
  • interaction specification for filters, disclosure, focus, Back/navigation, refresh/reconnect, live-update ordering, and contextual deep links;
  • responsive rules and semantic table/card decisions;
  • accessibility annotations and announcement rules;
  • token/Material component mapping using only the merged contract;
  • complete empty/loading/row-fields-missing/aggregate-error/reconnecting/complete/unknown states;
  • assumptions, unresolved questions, and a design decision log; and
  • an implementation handoff mapping each approved element to Waves 3–5 and identifying anything that requires a backend/API decision first.

Save exportable artefacts in a task-specific design folder or attach them to the design review. Do not add generated image binaries to the repository until the user selects what should be kept.

Review gates

Gate D1 — evidence accepted

Every current screenshot records version/SHA/flags/role, and the design has read all source docs.

Gate D2 — low fidelity selected

The user selects or recombines a system. Route names remain Library, Searches, and Processing.

Gate D3 — state and accessibility complete

The selected design covers the proof matrix at 1440px, 768px, 320px, 200%, and 400%, plus keyboard, screen reader, reduced motion, forced colours, reconnect, missing row fields, aggregate load failure, and long content. ProjectDetails is loaded as one aggregate, so Claude Design must not invent a failed-family state from an empty or permission-filtered collection.

Gate D4 — implementation-ready

Claude Code confirms every visible value/action maps to a real field, permission, route, or approved follow-up. Product and accessibility reviewers approve the decision record. Only then may the first implementation wave begin.

Claude Code hand-back

After Claude Design completes, Claude Code must:

  1. add or link the approved design decision record without modifying unrelated M3/theme files;
  2. reconcile the approved components against current main and refresh active file ownership;
  3. update the Wave 3–5 file ledgers and acceptance tests;
  4. surface any design element unsupported by current APIs as a named dependency, not an invented client behaviour; and
  5. request the user's explicit design approval before creating implementation PRs.