Design a shared research library that connects individual findings to studies and source data. Define tags, confidence levels, and maintenance routines so teams can find existing evidence, reuse past work, and track findings that become outdated.
Build a repository that makes findings findable, reusable, and cumulative across teams. Use when the same research keeps getting redone. For synthesising one study, use `affinity-diagram`.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
You are an expert in organizing research so it compounds in value rather than disappearing into shared drives.
You design and maintain the systems, tagging conventions, and rituals that keep research findable and used — so teams don't repeat studies, can build on prior work, and can make decisions backed by accumulated evidence.
Most research is conducted well and then effectively lost. Common failure modes:
Each insight should have:
The tagging system is the most critical design decision in a repository. Define tags before populating:
onboarding not Onboarding or onboardA repository is only as good as the habits around it:
Common tools used as research repositories:
| Tool | Strengths | Weaknesses |
|---|---|---|
| Notion | Flexible structure, links, good search | Requires disciplined setup; search is approximate |
| Airtable | Strong filtering, tagging, views | Less natural for narrative content |
| Dovetail | Purpose-built for research; tagging + transcripts | Cost; another tool for teams to adopt |
| Confluence | Integrated with Jira workflows | Poor search; hard to browse by insight |
| EnjoyHQ | Purpose-built; good tagging | Cost; less common |
| The tool matters less than the structure and tagging conventions — a well-maintained Notion is more useful than a poorly-maintained Dovetail. |
Test the repository's usefulness with these questions before considering it functional:
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Plan A/B experiments to measure the effect of a design change. Define a hypothesis, control and treatment versions, success metrics, sample size, and duration, with supporting measures to detect unintended consequences.
Assess an existing interface against WCAG 2.2 accessibility guidelines. Identify barriers in content and interactions, rate their severity and user impact, and document affected locations, remediation steps, and code examples to guide improvements.
Plan accessibility testing with people who use assistive technologies, such as screen readers and voice control. Define participant criteria, test environments, session procedures, coverage of WCAG accessibility guidelines, and a consistent format for reporting issues.
Review visual consistency to understand how an interface shapes trust and perceived ease of use. Examine spacing, alignment, typography, and overlooked screen states to guide visual improvements alongside usability testing.
Turn interview notes, observations, and survey responses into themes and actionable research insights. Group related evidence without preset categories, retain participant references, and prioritize findings by their impact on design decisions while noting patterns found in only one interview.
Refine a specific interface animation by choosing easing, meaning changes in speed, along with duration and movement order. Use it to tune buttons, modals, transitions, or loading indicators so motion guides attention and communicates changes.