Cory McKinnon
Let’s talk
Case Study · Sycle

I built an AI-native design harness and put it to work

Using Claude Code, I built and orchestrated specialized AI agents into a repeatable design harness that accelerated product discovery, prototyping, and iteration.

Time to first prototype 1–2 days

What previously took weeks of design work could now reach a working prototype in a day or two.

Role
Lead Product Designer, harness architect
Company
Sycle
Collaborators
Product, Engineering, designers and internal stakeholders
Scope
Reusable AI-native workflow and a Patient Communications prototype
Patient Communications prototype built with the harness: message categories, a patient conversation and a patient details panelEnlarge
Context & ownership

I built a design harness and led its application for Patient Communications

I developed a design harness independently, applied it to Patient Communications, and helped other designers adopt the approach.

Ownership

AI-native prototyping

Agent architecture, prompts, checkpoints and coded prototypes.

Scope

Harness + product concept

A reusable AI-native workflow and the Patient Communications prototype it produced.

Problem & goals

Complex product ideas took weeks to make tangible

I wanted to accelerate product discovery, improve stakeholder feedback, and introduce AI-native workflows that the design team could adopt.

The problem

Slow, static design exploration

Traditional design workflows took weeks to move from requirements to prototypes, limiting opportunities to explore ideas and incorporate feedback.

The goal

Make exploration faster and more iterative

Build a reusable, AI-native process that produces working prototypes quickly while keeping designers in control of decisions.

The design harness

I orchestrated specialist agents around human decisions

Using Claude Code, I built specialized AI agents and an orchestrator to turn product requirements into working prototypes, with human approval at critical stages.

  1. 01

    Discover

    Goals, research and requirements

  2. 02

    Challenge

    Research and “Grill Me” questions

  3. 03

    Define

    Generate a PRD for review

    Human approvalProduct, Design and Engineering approve the PRD
  4. 04

    Orchestrate

    Coordinate agents and tasks

    Human approvalReview scope and implementation plan
  5. 05

    Build

    Code, test and iterate

    Human approvalTest and approve each iteration
Agent-led stageHuman approval Agents do the legwork at every stage. Nothing moves from PRD to plan to prototype until a person approves it.

Specialist agents, working as one system

I wrote each specialist as a focused prompt with its own inputs, outputs and stopping rules. An orchestrator runs them in sequence within a single conversation, so context carries from research through to code.

  • Research & requirements

    Research competitor solutions and best practices, challenge my brief through a Grill Me session one question at a time, and draft a PRD that is only written once it’s approved.

    TO_REQUIREMENTSTO_PRD

  • Orchestrator & planning

    Runs each stage in order and stops at every gate until I continue. Planning turns the approved PRD into a design spec and small build tasks, each flagged as needing human review or safe to run.

    STARTTO_ARCHITECTURETO_KANBAN

  • Implementation & fixes

    Builds the prototype one task at a time, stops on anything the spec doesn’t cover, and waits for me to test each step. A fix loop turns walkthrough notes into tracked changes.

    TO_BUILDTO_FEEDBACK_FIX
Harness: design decisions

I structured the harness around specialized agents and human review

Context first

Ground agents in product knowledge

I structured requirements, research, and design-system guidance so agents worked within real product constraints.

Active challenge

Question assumptions early

I built research and “Grill Me” steps to expose missing requirements and challenge assumptions before prototyping.

Human control

Keep decisions with people

I introduced approval checkpoints for requirements, implementation plans, and prototype iterations.

Patient Communications · Discovery

Patient Communications was an opportunity to put the harness to work

I used the harness to turn early Patient Communications requirements into a working prototype for stakeholder review.

The opportunity
Bring patient messaging into Sycle to improve clinic workflows and create a new revenue opportunity.
What we needed to test
Managing conversations, patient context, delivery failures, and appointment changes in one experience.
Discovery board for Patient Communications with requirements, research notes and user flow diagramsEnlarge
Discovery artifacts produced through the harness.
Design decisions

Where my judgment shaped what the agents produced

Design decision 1

The initial message categories didn’t reflect how clinics work

The first pass
The agent organized messages into categories that didn’t reflect how staff prioritized follow-up.
My decision
I introduced a Needs Attention category for failed messages, at-risk appointments, reschedules, and no-shows.
Message navigation with All, Unread and Read, plus a Needs Attention group for Failed, At-Risk, Reschedule and No-ShowEnlarge
Design decision 2

I put patient context alongside each conversation

The opportunity
I wanted staff to access patient details without leaving the conversation.
My decision
I added a patient panel showing appointments, communication preferences, and consent.
Why it mattered
Staff could respond with the right patient and communication context at hand.
Patient panel showing last and next appointments, a Create New Appointment action and consent togglesEnlarge
Design decision 3

I made messaging workflows testable without a backend

The constraint
A standalone prototype couldn’t receive patient replies or system events.
My decision
I built a Scenario Controller to simulate patient replies, delivery failures, and appointment changes.
Why it mattered
Stakeholders could experience how the interface responded to realistic events before development.
Scenario Controller panel with patient actions, system events such as delivery failure, and staff actionsEnlarge
Final design

Patient Communications brought messaging and appointments into one experience

Patient Communications inbox with categories, a conversation thread and the patient panelEnlarge
The Patient Communications prototype.
The experience

Clinic staff could manage patient conversations, appointment changes, and delivery issues in one place.

The prototype

Stakeholders could navigate conversations, inspect patient details, and simulate messaging scenarios.

I made communication issues visible in daily clinic work

Dashboard visibility
Unread messages, delivery failures and appointments needing follow-up appeared together.
Actionable states
Staff could quickly identify issues and see what needed follow-up.
Clinic dashboard with a Communications card showing unread messages and failed deliveries next to today’s appointmentsEnlarge

I designed beyond the messaging interface

Message Events settings listing automated appointment messages and their SMS and email channelsEnlarge
Configuration: the settings clinics needed to configure and manage Patient Communications.
Communication Channels settings with the clinic SMS number and outbound email addressEnlarge
Operational controls: communication preferences, permissions, and system behaviour.
Validation & iteration

Internal walkthroughs helped to refine Patient Communications

  1. 1Capture

    Focus on the conversation

    I recorded and transcribed walkthroughs so I could focus on stakeholder feedback.

  2. 2Synthesize

    Turn feedback into decisions

    I used AI to summarize the discussions, then worked with stakeholders to decide what needed to change.

  3. 3Iterate

    Update and test the prototype

    I used the harness to implement agreed changes, then reviewed the updated experience.

Outcomes & impact

The harness changed how our team approached product design

Prototyping speedFrom weeks to days

What previously took weeks of design work could now reach a first working prototype in one or two days.

Design teamAdopted by the design team

I helped both designers adopt the harness for their own feature explorations.

Product teamExpanding into Product

Two Product Managers gained access and began experimenting with the harness.

Reflection

Building the harness changed how I approached product design

What worked

Better inputs led to better results

Clear requirements, design-system guidance, and constraints helped the agents produce more relevant work.

What mattered

Prototypes changed the conversations

Stakeholders could experience real workflows, uncover missing requirements, and give more useful feedback.

What I’d do next

Measure and improve the process

Track prototyping time, improve reusable components, and test Patient Communications with clinic staff.

Next case study AI Clinical Notes

Helping clinicians document visits with AI while keeping control of the final note.

Read next

Working on something ambitious?

I’d love to hear what you’re building. Tell me about the problem and where you’re headed.

Let’s talk Download résumé