Ishikawa Creator

The problem

I coordinate software quality, and the fishbone diagram comes up every time we need to understand why something failed. The method works: it forces you to separate categories of cause and to move from the apparent cause down to the real one. What does not work is the format. Drawing the spine on a whiteboard or in a diagramming tool eats most of the session, and reordering a branch when somebody contributes a new cause means redrawing it. The tool ends up competing with the analysis.

How I solved it

The starting observation is that an Ishikawa diagram is not really a drawing: it is a tree. Categories, causes within each category, and sub-causes beneath those. Represented as a nested structure it fills in as fast as you think, reorders without redrawing anything, and loses none of the information the graphical version would hold.

• Nested structure mirroring categories, causes and sub-causes
• JSON export to save the analysis
• JSON import to pick it back up or revise it later
• A single HTML file — no install, no account

The decision that defines the project

The obvious temptation was to render the fishbone at the end, to deliver the "real" diagram. I decided against it. The value of the method sits in the discipline of classifying causes, not in the figure; adding the render would have doubled the maintenance work and reintroduced exactly the rigidity the app exists to avoid. If somebody needs the figure for a report, the JSON holds everything required to generate it elsewhere.

How it is built

• One index.html, no dependencies and no build step
• State held in memory, serialised to JSON on export
• Published on GitHub Pages straight from the repository
• Public repository, with the full source on view