Rapid prototyping workflow for design sprints inspired by the thoughtbot methodology. Gathers context from Confluence PRDs and user research, defines prototype scope, generates functional HTML/Tailwind wireframes with visual design, populates realistic clinical trial sample data, and wires up clickable navigation. Outputs a complete prototype ready for usability testing with clinical site users, CRAs, and data managers.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Rapid prototyping workflow for design sprints inspired by the thoughtbot methodology. Gathers context from Confluence PRDs and user research, defines prototype scope, generates functional HTML/Tailwind wireframes with visual design, populates realistic clinical trial sample data, and wires up clickable navigation. Outputs a complete prototype ready for usability testing with clinical site users, CRAs, and data managers.
allowed-tools
Read, Grep, Glob, Bash, Write, Edit
argument-hint
[feature-name-or-prd-link]
Design Sprint Prototype
Purpose
Build a high-fidelity, clickable prototype in a single focused session for use in design sprint testing. The prototype must be realistic enough that clinical site staff, CRAs, and data managers can interact with it naturally and provide meaningful usability feedback. Speed is prioritized over perfection -- the goal is to test ideas, not ship production code.
Design Sprint Context
This skill follows a compressed version of the design sprint methodology:
Understand - Gather all context about the problem and users.
Scope - Define exactly what to prototype and what to fake.
Build - Generate the functional prototype rapidly.
Polish - Apply visual design and realistic data.
Connect - Wire everything together into a seamless experience.
Prepare - Create testing materials for usability sessions.
Workflow
Step 1: Gather Context
From Confluence (PRD, research, specs):
Use mcp__claude_ai_Atlassian__searchConfluenceUsingCql to find relevant pages:
text ~ "feature name" AND space = "PRODUCT" ORDER BY lastmodified DESC
Use mcp__claude_ai_Atlassian__getConfluencePage to retrieve:
Product Requirements Document.
User research findings or persona documents.
Competitive analysis or benchmarking pages.
Design system documentation.
Use mcp__claude_ai_Atlassian__getConfluencePageDescendants if content spans sub-pages.
From Jira (stories, epics):
Use mcp__claude_ai_Atlassian__searchJiraIssuesUsingJql to find related stories:
project = TAL AND text ~ "feature name" ORDER BY rank ASC
Pull acceptance criteria and user stories from linked issues.
From the user directly:
Accept verbal or written description of the feature.
Accept sketches, screenshots, or reference URLs.
Ask clarifying questions about target users and key scenarios.
Synthesize context into a brief:
## Prototype Brief**Feature**: [Name]
**Target Users**: [Roles - e.g., Site Coordinator, CRA, Data Manager]
**Problem Statement**: [What problem are we solving]
**Key Scenarios**: [3-5 specific tasks users will attempt]
**Success Criteria**: [How we'll know the prototype works]
**Constraints**: [Technical, regulatory, timeline constraints]
Present the brief to the user for confirmation before proceeding.
Step 2: Define Scope
Determine what to build and what to simulate:
Prototype scope matrix:
Screen/Feature
Build Level
Notes
Main workflow screens
Full fidelity
All interactions work
Secondary screens
Medium fidelity
Key elements work, some static
Settings/admin screens
Low fidelity / skip
Static or placeholder
Error states
Selected critical ones
Most impactful error paths
Edge cases
Skip
Out of scope for sprint test
What to build:
Every screen in the primary user flow being tested.
All navigation between those screens.
Form interactions (input, select, submit) on key screens.
State changes (loading, success, error) for primary actions.
Realistic data in all visible tables and lists.
What to fake:
Backend persistence (use local state or static data).
Authentication (assume logged in).
Long-running processes (simulate with timeouts).
Secondary workflows not being tested.
Deep links to other parts of the application.
Present the scope to the user for approval.
Step 3: Generate Rapid Wireframes
Build the prototype as a single-page application using HTML + Tailwind CSS + vanilla JavaScript (for maximum portability) or React if the user prefers.
File structure:
sprint-prototype/
index.html # Entry point with routing
css/
tailwind.css # Tailwind via CDN or compiled
tokens.css # Talosix design tokens
animations.css # Transition and animation styles
js/
app.js # Navigation and state management
data.js # Sample data
interactions.js # UI interaction handlers
screens/ # Each screen as a module/partial
dashboard.js
subject-list.js
crf-entry.js
query-list.js
...
For React variant:
sprint-prototype/
package.json
vite.config.ts
index.html
src/
main.tsx
App.tsx
router.tsx
screens/
Dashboard.tsx
SubjectList.tsx
CrfEntry.tsx
...
components/
Shell.tsx # App shell with sidebar and header
DataTable.tsx
FormField.tsx
StatusBadge.tsx
Modal.tsx
...
data/
sampleData.ts
hooks/
usePrototypeState.ts # Simple state management for prototype
Speed techniques:
Use Tailwind CDN for instant setup (no build step for HTML version).
Use Vite for React version (fast startup).
Inline SVG icons from Heroicons or Lucide.
Use CSS transitions instead of a JS animation library.
Copy patterns from existing components in the codebase when available.
Step 4: Apply Visual Design
Apply the Talosix design system tokens for a polished look:
E-signature dialog accepts input and shows signed state.
Query response textarea accepts text and shows submitted state.
Step 7: Output the Prototype
Write all files to a sprint-prototype/ directory (or user-specified path).
Include setup instructions:
For HTML version:
Open sprint-prototype/index.html in your browser.
No build step required.
For React version:
cd sprint-prototype
npm install
npm run dev
Open http://localhost:5173 in your browser.
Create a PROTOTYPE-GUIDE.md with:
List of all screens and their URLs/routes.
Which interactions are functional vs simulated.
Known limitations and workarounds.
How to reset the prototype state (refresh the page).
Step 8: Create Usability Testing Materials
Generate materials for the testing sessions:
Test Script (TEST-SCRIPT.md):
# Usability Test Script: [Feature Name]## Setup- Duration: 30-45 minutes per session
- Participants: [Target user roles]
- Environment: [Browser, screen share tool]
- Prototype URL: [Local or deployed URL]
## Introduction (2 min)
"Thank you for joining. We are testing a new feature for [description].
There are no right or wrong answers. We want to understand how you would
naturally use this. Please think aloud as you work through the tasks."
## Warm-up (3 min)- "Tell me about your current role and how you interact with [system area]."
- "How often do you [relevant action]?"
## Task 1: [Primary task] (8-10 min)**Scenario**: "You have just received a notification that [context].
You need to [specific goal]."
**Observation points**:
- Does the user find the starting point?
- What navigation path do they take?
- Do they understand the form labels?
- How do they react to validation messages?
- Do they complete the task without help?
**Follow-up questions**:
- "What did you expect to happen when you clicked [element]?"
- "Was anything confusing or unexpected?"
- "How does this compare to your current process?"
## Task 2: [Secondary task] (8-10 min)
...
## Task 3: [Error recovery task] (5-8 min)
...
## Debrief (5 min)- "Overall, how would you rate this experience on a scale of 1-5?"
- "What worked well?"
- "What would you change?"
- "Is there anything missing that you would need?"
## Observer Notes Template
| Participant | Task | Completed? | Time | Errors | Comments |
|-------------|------|-----------|------|--------|----------|
| P1 | Task 1 | Yes/No | Xm Xs | N | ... |
Observation Worksheet (OBSERVATION-SHEET.md):
Pre-filled grid for each task and participant.
Checkboxes for common usability issues.
Space for verbatim quotes.
Rating scales for task difficulty.
Speed Guidelines
This is a sprint prototype. Prioritize:
Coverage over polish -- Get all screens in place before perfecting any one screen.
Real data over lorem ipsum -- Clinical users will reject unrealistic data immediately.
Working navigation over animations -- Users must be able to complete tasks end-to-end.
Key interactions over edge cases -- Build the happy path first, then add critical error states.
Consistent patterns over unique layouts -- Reuse the same card, table, and form patterns across screens.
Target timeline: A complete prototype should be achievable in 2-4 hours.
Quality Checklist
All screens in the test script are built and navigable.
Navigation between all connected screens works.
Sample data is realistic and internally consistent.
Form inputs accept user input on key screens.
Status indicators use consistent color coding.
The app shell (sidebar, header, breadcrumbs) is present on all screens.
The prototype works in Chrome and Safari.
The test script covers all scenarios to be validated.
PROTOTYPE-GUIDE.md documents all limitations.
No placeholder text (lorem ipsum, "TODO", "TBD") is visible in the prototype.
