This fishbone diagram template gives you a filled example and a blank starting version. Keep several possible causes visible until you have evidence to narrow them down. Each cause has a question the team can investigate next.
Start with one problem you can investigate
The original fictional example concerns a team newsletter that missed its planned noon send time. The diagram's head reads Newsletter sent after the planned noon deadline. Its branches organize possible explanations for that one effect.
| Branch | Possible cause | Next evidence question |
|---|---|---|
| Process | Final approval may have arrived after the send cutoff. | When was the review requested, and when did approval arrive? |
| Inputs | The draft may have been waiting for a working event link. | Which link was missing, and when was it supplied? |
| Tools | An image change may have disrupted the prepared email layout. | What changed in the draft, and what did the preview show? |
| People and coordination | The backup reviewer may not have known they were needed. | Was backup coverage agreed, and who received the review request? |
These are proposed explanations for the teaching example. The table contains no investigation results. A late approval could itself have followed a missing input, so drawing two branches does not establish two independent causes.
The ASQ fishbone overview describes using categories to organize many possible causes during brainstorming. Choose categories that help people examine your process. The four here suit a publishing handoff; they are not a required set for every diagram.
Make each branch specific enough to check
“Communication” could mean a missing request, an unclear deadline, or a reviewer who was unavailable. Write the particular possibility you want to examine. Someone should be able to say what record, observation, or conversation would help test it.
In the filled example, select the backup-reviewer cause to read its evidence question. You can revise the wording or move it to another branch. If the team considers backup coverage part of its procedure, placing it under Process may make the discussion easier to follow. That move changes the organization of the diagram; it does not confirm the explanation.
A branch label helps you find a question. It does not answer it. Before removing a possible cause, record why the available evidence supports or weakens it in your team's investigation notes. Keep a cause open if the relevant information is still missing.
Use the blank version for your own process
Write the effect first. “Customers receive the wrong attachment” is more usable than “Email problems” because the team can identify the outcome it needs to explain. Add the relevant period or affected work when you know it.
Then choose a few categories and add the possibilities people raise. Preserve their meaning as you shorten the labels. If someone proposes a fix, ask which possible cause it addresses and what would make that explanation credible.
Keep observations separate from the cause labels. A record showing that an event link arrived at 12:15 can support a discussion about the missed noon deadline. It still leaves questions about the handoff, the approval sequence, and whether another condition also mattered. The diagram helps organize those questions before you choose an action.
Copy a prompt for a diagram you can revise
Give an AI assistant the problem, your categories, and the possibilities you want to discuss. This prompt also includes the complete fictional example so you can reproduce it before replacing the rows with your own material.
Create one complete, self-contained US-English HTML fishbone diagram.
My process and audience: [FILL IN]
Effect to investigate, including the relevant period if known: [FILL IN]
Observed facts and their source references: [PASTE, or NOT SUPPLIED]
Branch categories: [PASTE]
Possible causes: [ID | branch | possible cause | next evidence question]
Include the following original fictional demonstration as a separate filled example. Label it Fictional team example. Its effect is: Newsletter sent after the planned noon deadline.
C1 | Process | Final approval may have arrived after the send cutoff. | When was the review requested, and when did approval arrive?
C2 | Inputs | The draft may have been waiting for a working event link. | Which link was missing, and when was it supplied?
C3 | Tools | An image change may have disrupted the prepared email layout. | What changed in the draft, and what did the preview show?
C4 | People and coordination | The backup reviewer may not have known they were needed. | Was backup coverage agreed, and who received the review request?
Keep these four causes unconfirmed. No investigation results are supplied. Do not invent timestamps, blame, verified causes, completed actions, or business outcomes. Do not turn my missing facts into facts from the demonstration.
Show the effect and all branches without hiding causes behind tabs or accordions. Give each cause a stable ID. Selecting a cause should show its full wording and evidence question beside the diagram. Provide labeled controls to revise its text and move it to a different branch. Preserve the cause ID and evidence question when it moves. Updates must change the displayed diagram immediately and clear any stale selected-cause description.
Add a separate Blank diagram button that starts an empty draft and a Filled example button that restores only the supplied fictional example. Explain that edits in this open example are temporary. Do not add cause scores, automatic diagnoses, success badges, approvals, or a fake export button.
Use an original diagram, with inline SVG if helpful, plus equivalent readable text. At 360px, arrange the same branches as labeled stacked groups rather than shrinking a wide diagram until its text is unreadable. Use at least 16px body text, labeled keyboard-accessible controls, visible focus, and written labels as well as color. Use inline CSS and JavaScript only, no network, no storage, and no external assets. Return the complete HTML document.
Read the generated cause labels before the discussion. If the assistant changed “may have arrived late” to “arrived late,” restore the uncertainty unless your evidence establishes the latter.
Let the team correct the diagram before acting on it
Once you have the HTML, put it in your NOS workspace and ask a colleague to check the branches. They may spot a missing handoff or a label that sounds more certain than the evidence allows.
If an instruction above the diagram sounds too certain, you can correct that text on the saved page without asking the AI to rebuild the layout. After you save the correction, your colleague can reopen the link you already sent to read it. Use the discussion to choose the next evidence question, then record the actual findings and agreed actions in the team's working records.