Design Ops
Signals database
A design-ops initiative that turned scattered customer voice into a searchable, citable signals hub inside Booksy's design OS (Machina). Built with AI-assisted ingest at scale, it gives the whole product design team one digestible place to browse through pain points, link evidence in briefs, and power project kickoff and prototyping with real customer signals.
Year :
2026
Industry :
SaaS · Beauty & wellness
Client :
Booksy
Project Duration :
2 months
Problem :
The visibility gap
Customer pain was real and loud, but it lived in the wrong places for design work. Signals piled up in Slack, call notes, squad folders, and ad hoc docs. Some teams had local habits that worked for them; everyone else kept re-discovering the same complaints weeks later.
There was no shared source of truth. Briefs and kickoffs leaned on memory, screenshots, or whoever happened to be in the channel that day. Squads could not search by feature, domain, or theme. Evidence rarely made it into project files in a form you could cite or reuse.
Volume without structure
Roughly 20-50 new signals every day kept landing in the stream. In practice, almost nobody was reading Slack for research anymore. It was constant ingestion: new data, little re-segmentation, no durable map of what mattered. We were sitting on a goldmine and still doing research on the side because the raw feed was too overwhelming to use day to day.
Scale made it worse
Thousands of topics across multiple markets, many squads, and several product domains meant manual curation would always lose. The team needed structure and clarity at browse time, without paying for another SaaS tool on top of the design OS we already prototype in.
Solution :
Design philosophy
Treat customer voice like infrastructure designers can actually use:
Digestible UI first: a browse experience that feels like a research site (this week, what we're hearing, themes and sub-themes), not a raw feed
Evidence you can cite: clustered signals with stable SIG-YYYY-NNNN IDs and links back to originals in Slack and other sources
Plugged into design OS: Research lives inside Machina, same chrome as Work, gallery-visible, so reading pain and opening prototypes stay in one flow
AI at scale (without losing the thread)
The bottleneck was not insight. It was throughput. I used AI-assisted pipelines to ingest and normalize pain from Slack at volumes a human tagger could not sustain, cluster occurrences into themes (and sub-themes) by feature, squad, and domain, and draft weekly squad digests that are conversational, prioritised, and spike-aware.
Ingest started with SSE clients talking to connectors; human judgment stays on what ships (approval gates, taxonomy, which channels enter the pool). The agent owns repetitive extraction, tagging, and refresh so designers spend time on decisions, not archaeology.
What shipped in the browse experience
The browse surface is organized the way designers look for pain.
This week: a clear window on latest ingest and squad-level "so what"
What we're hearing: filterable cards with domain, squad, search, and a side panel for detail
Themes and sub-themes: clustered pain instead of duplicate threads
Conceptual model: Signal (what you cite) → Occurrence (one piece of evidence) → Source (how it entered the system). Designers get one map of pain; every cluster still traces to where it was said.
Delivery :
Cross-functional orchestration
Framed as giving the whole design org one browse surface, not replacing how individual squads already worked.
Product design: brief, browse UI, Machina Research area, gallery entry, harness alignment
Design leadership: channel scope, taxonomy sanity, digest tone
Design OS (Machina): Research tree matching Work patterns; prototypes stay the destination after reading evidence
Agent harness: routing so kickoff and project work can query the database instead of re-scraping Slack every time
Build milestones
From the first schema to a surface the team can open inside Machina.
✅ Schema, routing, and sample records for how signals should read in UI and briefs
✅ Browse UI with filters, themes/sub-themes, and side panel detail
✅ Bulk historical fill workflow (see constraints below)
✅ Machina Research shell; standalone browser URL redirects into design OS
✅ Harness hooks so designers can ask to "check the database" for a topic during kickoff or iteration
🔄 Weekly digests rolling out with wider team share
Constraints and how we worked around them
No new paid tool. Buying another research repository or segmentation product was a non-starter on cost and adoption. Building inside the existing design OS kept access where designers already work.
Initial backfill was expensive. The first large pool of history went through MCP connectors. Token usage made bulk fill slow and costly at the scale we needed.
Workflow shift: we replaced the MCP path with a direct API for ingest and backfill. Same quality bar, but runs much faster at scale and at near-zero marginal cost. That unlock is what made "fill the goldmine" realistic instead of a one-off experiment.
Signal quality bar: automated Slack ingest focuses on actionable negative pain (blocker / high / medium) so the database stays useful, not noisy.
Success Analysis :
Design OS integration
Gallery lists Signals database. Research opens inside Machina with the same navigation patterns as Work. Reading pain and jumping into a prototype canvas stay in one environment, so evidence is not a PDF on the side.
Primary success signal: evidence in the workflow
🎯 Designers can find, understand, and cite customer pain in under a minute, from the same place they prototype.
Pilot indicators
What we can already point to.
Structured corpus: verified pain processed into citeable clusters with stable IDs; historical depth growing through the API-backed backfill workflow
One browse surface: domain and squad filters aligned to the official roster, not whatever happened to be tagged in a single batch
Citation-ready: briefs and findings can reference SIG-* IDs; occurrences keep source URLs for audit
Harness check-ins: in chat, designers can ask the agent to check the database for what we already know about a feature and get clustered evidence without a manual Slack archaeology session
What changes for the team
Before: "I think I've seen a conversation about this in the signals channel."
After: Open Research, filter to the squad or theme, read clusters and sub-themes, paste a SIG ID into kickoff or checkout work, or ask the harness to check the database while shaping a flow.
AI leverage (the meta win)
The same agent stack that prototypes UI in Machina also maintains the evidence layer at a scale manual research ops cannot hold. A concrete win: grounding no-show protection work in clustered signals and harness check-ins instead of anecdote. Fast ingest, digestible UI, and the prototype shell stay tethered: decisions in design OS reference customer reality.
Next measures
What we will watch as more of the team starts using it.
Weekly digest open and reply rates per squad
Count of project files citing SIG-* IDs per quarter
Quarterly brief used in real planning conversations
Confirmation that the system expands how teams already work rather than duplicating it
More Projects
Design Ops
Signals database
A design-ops initiative that turned scattered customer voice into a searchable, citable signals hub inside Booksy's design OS (Machina). Built with AI-assisted ingest at scale, it gives the whole product design team one digestible place to browse through pain points, link evidence in briefs, and power project kickoff and prototyping with real customer signals.
Year :
2026
Industry :
SaaS · Beauty & wellness
Client :
Booksy
Project Duration :
2 months
Problem :
The visibility gap
Customer pain was real and loud, but it lived in the wrong places for design work. Signals piled up in Slack, call notes, squad folders, and ad hoc docs. Some teams had local habits that worked for them; everyone else kept re-discovering the same complaints weeks later.
There was no shared source of truth. Briefs and kickoffs leaned on memory, screenshots, or whoever happened to be in the channel that day. Squads could not search by feature, domain, or theme. Evidence rarely made it into project files in a form you could cite or reuse.
Volume without structure
Roughly 20-50 new signals every day kept landing in the stream. In practice, almost nobody was reading Slack for research anymore. It was constant ingestion: new data, little re-segmentation, no durable map of what mattered. We were sitting on a goldmine and still doing research on the side because the raw feed was too overwhelming to use day to day.
Scale made it worse
Thousands of topics across multiple markets, many squads, and several product domains meant manual curation would always lose. The team needed structure and clarity at browse time, without paying for another SaaS tool on top of the design OS we already prototype in.
Solution :
Design philosophy
Treat customer voice like infrastructure designers can actually use:
Digestible UI first: a browse experience that feels like a research site (this week, what we're hearing, themes and sub-themes), not a raw feed
Evidence you can cite: clustered signals with stable SIG-YYYY-NNNN IDs and links back to originals in Slack and other sources
Plugged into design OS: Research lives inside Machina, same chrome as Work, gallery-visible, so reading pain and opening prototypes stay in one flow
AI at scale (without losing the thread)
The bottleneck was not insight. It was throughput. I used AI-assisted pipelines to ingest and normalize pain from Slack at volumes a human tagger could not sustain, cluster occurrences into themes (and sub-themes) by feature, squad, and domain, and draft weekly squad digests that are conversational, prioritised, and spike-aware.
Ingest started with SSE clients talking to connectors; human judgment stays on what ships (approval gates, taxonomy, which channels enter the pool). The agent owns repetitive extraction, tagging, and refresh so designers spend time on decisions, not archaeology.
What shipped in the browse experience
The browse surface is organized the way designers look for pain.
This week: a clear window on latest ingest and squad-level "so what"
What we're hearing: filterable cards with domain, squad, search, and a side panel for detail
Themes and sub-themes: clustered pain instead of duplicate threads
Conceptual model: Signal (what you cite) → Occurrence (one piece of evidence) → Source (how it entered the system). Designers get one map of pain; every cluster still traces to where it was said.
Delivery :
Cross-functional orchestration
Framed as giving the whole design org one browse surface, not replacing how individual squads already worked.
Product design: brief, browse UI, Machina Research area, gallery entry, harness alignment
Design leadership: channel scope, taxonomy sanity, digest tone
Design OS (Machina): Research tree matching Work patterns; prototypes stay the destination after reading evidence
Agent harness: routing so kickoff and project work can query the database instead of re-scraping Slack every time
Build milestones
From the first schema to a surface the team can open inside Machina.
✅ Schema, routing, and sample records for how signals should read in UI and briefs
✅ Browse UI with filters, themes/sub-themes, and side panel detail
✅ Bulk historical fill workflow (see constraints below)
✅ Machina Research shell; standalone browser URL redirects into design OS
✅ Harness hooks so designers can ask to "check the database" for a topic during kickoff or iteration
🔄 Weekly digests rolling out with wider team share
Constraints and how we worked around them
No new paid tool. Buying another research repository or segmentation product was a non-starter on cost and adoption. Building inside the existing design OS kept access where designers already work.
Initial backfill was expensive. The first large pool of history went through MCP connectors. Token usage made bulk fill slow and costly at the scale we needed.
Workflow shift: we replaced the MCP path with a direct API for ingest and backfill. Same quality bar, but runs much faster at scale and at near-zero marginal cost. That unlock is what made "fill the goldmine" realistic instead of a one-off experiment.
Signal quality bar: automated Slack ingest focuses on actionable negative pain (blocker / high / medium) so the database stays useful, not noisy.
Success Analysis :
Design OS integration
Gallery lists Signals database. Research opens inside Machina with the same navigation patterns as Work. Reading pain and jumping into a prototype canvas stay in one environment, so evidence is not a PDF on the side.
Primary success signal: evidence in the workflow
🎯 Designers can find, understand, and cite customer pain in under a minute, from the same place they prototype.
Pilot indicators
What we can already point to.
Structured corpus: verified pain processed into citeable clusters with stable IDs; historical depth growing through the API-backed backfill workflow
One browse surface: domain and squad filters aligned to the official roster, not whatever happened to be tagged in a single batch
Citation-ready: briefs and findings can reference SIG-* IDs; occurrences keep source URLs for audit
Harness check-ins: in chat, designers can ask the agent to check the database for what we already know about a feature and get clustered evidence without a manual Slack archaeology session
What changes for the team
Before: "I think I've seen a conversation about this in the signals channel."
After: Open Research, filter to the squad or theme, read clusters and sub-themes, paste a SIG ID into kickoff or checkout work, or ask the harness to check the database while shaping a flow.
AI leverage (the meta win)
The same agent stack that prototypes UI in Machina also maintains the evidence layer at a scale manual research ops cannot hold. A concrete win: grounding no-show protection work in clustered signals and harness check-ins instead of anecdote. Fast ingest, digestible UI, and the prototype shell stay tethered: decisions in design OS reference customer reality.
Next measures
What we will watch as more of the team starts using it.
Weekly digest open and reply rates per squad
Count of project files citing SIG-* IDs per quarter
Quarterly brief used in real planning conversations
Confirmation that the system expands how teams already work rather than duplicating it
More Projects
Design Ops
Signals database
A design-ops initiative that turned scattered customer voice into a searchable, citable signals hub inside Booksy's design OS (Machina). Built with AI-assisted ingest at scale, it gives the whole product design team one digestible place to browse through pain points, link evidence in briefs, and power project kickoff and prototyping with real customer signals.
Year :
2026
Industry :
SaaS · Beauty & wellness
Client :
Booksy
Project Duration :
2 months
Problem :
The visibility gap
Customer pain was real and loud, but it lived in the wrong places for design work. Signals piled up in Slack, call notes, squad folders, and ad hoc docs. Some teams had local habits that worked for them; everyone else kept re-discovering the same complaints weeks later.
There was no shared source of truth. Briefs and kickoffs leaned on memory, screenshots, or whoever happened to be in the channel that day. Squads could not search by feature, domain, or theme. Evidence rarely made it into project files in a form you could cite or reuse.
Volume without structure
Roughly 20-50 new signals every day kept landing in the stream. In practice, almost nobody was reading Slack for research anymore. It was constant ingestion: new data, little re-segmentation, no durable map of what mattered. We were sitting on a goldmine and still doing research on the side because the raw feed was too overwhelming to use day to day.
Scale made it worse
Thousands of topics across multiple markets, many squads, and several product domains meant manual curation would always lose. The team needed structure and clarity at browse time, without paying for another SaaS tool on top of the design OS we already prototype in.
Solution :
Design philosophy
Treat customer voice like infrastructure designers can actually use:
Digestible UI first: a browse experience that feels like a research site (this week, what we're hearing, themes and sub-themes), not a raw feed
Evidence you can cite: clustered signals with stable SIG-YYYY-NNNN IDs and links back to originals in Slack and other sources
Plugged into design OS: Research lives inside Machina, same chrome as Work, gallery-visible, so reading pain and opening prototypes stay in one flow
AI at scale (without losing the thread)
The bottleneck was not insight. It was throughput. I used AI-assisted pipelines to ingest and normalize pain from Slack at volumes a human tagger could not sustain, cluster occurrences into themes (and sub-themes) by feature, squad, and domain, and draft weekly squad digests that are conversational, prioritised, and spike-aware.
Ingest started with SSE clients talking to connectors; human judgment stays on what ships (approval gates, taxonomy, which channels enter the pool). The agent owns repetitive extraction, tagging, and refresh so designers spend time on decisions, not archaeology.
What shipped in the browse experience
The browse surface is organized the way designers look for pain.
This week: a clear window on latest ingest and squad-level "so what"
What we're hearing: filterable cards with domain, squad, search, and a side panel for detail
Themes and sub-themes: clustered pain instead of duplicate threads
Conceptual model: Signal (what you cite) → Occurrence (one piece of evidence) → Source (how it entered the system). Designers get one map of pain; every cluster still traces to where it was said.
Delivery :
Cross-functional orchestration
Framed as giving the whole design org one browse surface, not replacing how individual squads already worked.
Product design: brief, browse UI, Machina Research area, gallery entry, harness alignment
Design leadership: channel scope, taxonomy sanity, digest tone
Design OS (Machina): Research tree matching Work patterns; prototypes stay the destination after reading evidence
Agent harness: routing so kickoff and project work can query the database instead of re-scraping Slack every time
Build milestones
From the first schema to a surface the team can open inside Machina.
✅ Schema, routing, and sample records for how signals should read in UI and briefs
✅ Browse UI with filters, themes/sub-themes, and side panel detail
✅ Bulk historical fill workflow (see constraints below)
✅ Machina Research shell; standalone browser URL redirects into design OS
✅ Harness hooks so designers can ask to "check the database" for a topic during kickoff or iteration
🔄 Weekly digests rolling out with wider team share
Constraints and how we worked around them
No new paid tool. Buying another research repository or segmentation product was a non-starter on cost and adoption. Building inside the existing design OS kept access where designers already work.
Initial backfill was expensive. The first large pool of history went through MCP connectors. Token usage made bulk fill slow and costly at the scale we needed.
Workflow shift: we replaced the MCP path with a direct API for ingest and backfill. Same quality bar, but runs much faster at scale and at near-zero marginal cost. That unlock is what made "fill the goldmine" realistic instead of a one-off experiment.
Signal quality bar: automated Slack ingest focuses on actionable negative pain (blocker / high / medium) so the database stays useful, not noisy.
Success Analysis :
Design OS integration
Gallery lists Signals database. Research opens inside Machina with the same navigation patterns as Work. Reading pain and jumping into a prototype canvas stay in one environment, so evidence is not a PDF on the side.
Primary success signal: evidence in the workflow
🎯 Designers can find, understand, and cite customer pain in under a minute, from the same place they prototype.
Pilot indicators
What we can already point to.
Structured corpus: verified pain processed into citeable clusters with stable IDs; historical depth growing through the API-backed backfill workflow
One browse surface: domain and squad filters aligned to the official roster, not whatever happened to be tagged in a single batch
Citation-ready: briefs and findings can reference SIG-* IDs; occurrences keep source URLs for audit
Harness check-ins: in chat, designers can ask the agent to check the database for what we already know about a feature and get clustered evidence without a manual Slack archaeology session
What changes for the team
Before: "I think I've seen a conversation about this in the signals channel."
After: Open Research, filter to the squad or theme, read clusters and sub-themes, paste a SIG ID into kickoff or checkout work, or ask the harness to check the database while shaping a flow.
AI leverage (the meta win)
The same agent stack that prototypes UI in Machina also maintains the evidence layer at a scale manual research ops cannot hold. A concrete win: grounding no-show protection work in clustered signals and harness check-ins instead of anecdote. Fast ingest, digestible UI, and the prototype shell stay tethered: decisions in design OS reference customer reality.
Next measures
What we will watch as more of the team starts using it.
Weekly digest open and reply rates per squad
Count of project files citing SIG-* IDs per quarter
Quarterly brief used in real planning conversations
Confirmation that the system expands how teams already work rather than duplicating it