Make an interactive tool with Opus 5.5

Start with the decision the tool supports

A paint estimator helps someone decide roughly how much paint to buy. Inputs might include total wall area, the coverage printed on a paint can, the number of coats and a waste allowance. The result should explain its units and assumptions. It should not quietly substitute a generic coverage value while presenting the answer as exact.

Write a small specification before opening the builder. In this example, required liters equal wall area multiplied by coats, divided by coverage, then adjusted for the waste percentage. Decide whether the tool rounds the displayed result, suggests whole cans, or does both. Label it as an estimate and explain that surface preparation and the actual product can change coverage.

For scientific, financial or health-related tools, the stakes may be higher. Get the rules and limitations reviewed by someone qualified for the subject. A polished slider does not establish that the underlying model is correct.

Show inputs, output and assumptions together

Use labels that describe what a person should enter: “Wall area in square meters” is clearer than “Area.” Provide example values and a brief explanation of coverage. Display the main answer near the controls, followed by a transparent calculation and the assumptions. Someone should be able to explain why the answer changed.

Try one complete example on paper. If wall area is 40 square meters, coverage is 10 square meters per liter, coats are two and waste is zero, the result is eight liters. With a 10 percent waste allowance it is 8.8 liters. These are editorial test examples, not a recommendation about any particular paint product.

Use Opus 5.5 to build a paint-estimate tool. Inputs: wall area in m², coverage in m²/liter, number of coats and waste percentage. Calculation: area × coats ÷ coverage × (1 + waste/100). Show liters to one decimal place and an expandable calculation explanation. Reject negative area, zero coverage and invalid values with helpful inline messages. Include worked tests for 40 m², 10 m²/liter, 2 coats, with 0% and 10% waste. Keep data local and add no accounts or external API. Build keyboard- and touch-friendly controls.

Test behavior before visual polish

Ask the agent to keep the calculation in a small function that can be checked independently of the screen. Give it the worked examples and ask it to test empty fields, decimal values, zero, negative numbers and unusually large values. A field that silently converts an empty string to zero can create a misleading answer.

Check the displayed result yourself. Change one input at a time and predict the direction of the change. More wall area should not reduce liters; higher coverage should not increase them. These simple relationships catch mistakes that a screenshot cannot. Reload the page and inspect whether retained inputs behave as the interface promises.

• Known example: 40 × 2 ÷ 10 gives 8 liters before waste.
• Boundary: zero coverage produces a clear message, never infinity.
• Units: labels and output use the same measurement system.
• Rounding: the explanation distinguishes an estimate from a purchasing quantity.

Choose an artifact or an independently hosted tool

Claude can create interactive artifacts, and current artifacts can support more than a disposable visual preview. Capabilities and sharing settings depend on the product and plan. New shared artifacts normally require visitors to have a Claude account. Published legacy chat artifacts are a documented exception, so do not rely on old tutorials when planning a new public launch.

If you need a public tool on your own site, inspect the available export or project-file route and choose hosting that supports the resulting application. Do not assume every artifact becomes a standalone HTML file with all integrations intact. Verify the actual output, dependency needs and data behavior before committing to a launch URL.

• Current Claude artifacts overview ↗
• Current artifact sharing rules ↗
• Choose hosting ↗

Package the tool with enough explanation

Give the tool a descriptive page title and an introduction that answers who it helps. Add a small worked example, the calculation source or method, units, meaningful limits and a contact route for errors. Keep the inputs visible instead of burying the tool below a long essay. Supporting content should help someone use the result.

Look at Amit Patel’s interactive explanations or Bartosz Ciechanowski’s visual articles to study how an interface can reveal a relationship. Their work is a design reference, not evidence that this paint-estimator exercise reproduces their methods or uses their tools. Build an explanation that fits your own subject and acknowledge the sources of the underlying rules.

Finally, send a real link to someone unfamiliar with the project. Ask them to estimate the same example and describe what the answer means. If they cannot tell which units to enter or what to do with the output, improve the wording before adding another visualization.