Use a Claude skill to turn product feedback into a design brief

“Make the dashboard clearer” is easy feedback to give and expensive feedback to receive. A designer can spend a week answering it without knowing which customer task the founder had in mind.

For a startup with a shipping product and a small team, a useful Claude skill should help close that gap. Give it a specific journey and the context behind it. Ask for an observable problem, a proposed change and a check the team can run. The output should be concrete enough for a designer to challenge before anyone builds it.

Humbleteam’s AI SaaS Design Director packages that kind of review guidance for Claude and ChatGPT. This article follows the Claude workflow, with an illustrative example of turning a screen critique into a brief. The example is not a customer result or a report from a live product test.

What a skill adds to a design conversation

Anthropic describes skills as reusable instructions and resources that Claude loads when relevant. For product reviews, that means you can reuse a review method instead of explaining it again in every conversation.

The distinction matters when several people review the same product. One founder might ask for conversion ideas; a product manager might ask for usability problems. A shared skill can give their requests a common structure. It still needs the product context each time. It cannot infer why a customer abandoned a task from a screenshot.

The AI SaaS Design Director accepts screenshots, accessible URLs or Figma context. Its review instructions separate visible issues from business hypotheses and prioritize suggested fixes. Figma drafting requires a configured connection with the necessary access. You can start with a written review before connecting a design file.

Give it the decision you need to make

Imagine a funded startup selling an AI tool that prepares weekly account summaries. The product already has customers. The founder wants to improve the screen where a manager reviews a generated summary before sharing it with colleagues.

“Review this dashboard” leaves too much open. Supply the screen before the review, the review itself and the state after sharing. Add a short explanation:

The user is an account manager preparing a weekly update. They need to check the generated summary and share the approved version with their team. Sharing publishes to the workspace immediately. Our goal is to make that consequence clear before they act. Review the attached screens. Separate what you can observe from assumptions that need customer or product evidence. Do not redesign the whole dashboard.

Use synthetic account information or material your company permits you to upload. A working URL does not guarantee access to signed-in screens. Screenshots of the relevant states can be more useful than a login page the assistant cannot get past.

Include constraints that would change the recommendation. Perhaps the team cannot add approval roles this quarter. Perhaps a shared summary cannot be withdrawn. Those facts determine whether a proposed interaction is workable.

Turn one finding into a brief

In this hypothetical interface, the main button says “Continue.” The next screen appears only after the summary has been shared. The review could reasonably identify a mismatch between the label and the action. It could not establish how many customers have shared accidentally.

A weak recommendation would be “Improve the CTA to increase engagement.” It leaves the designer to discover the task, the problem and the product behavior all over again.

A useful brief would read:

• Screen: generated-summary review, before publication to the workspace.
• Observation: the primary button says “Continue,” although pressing it shares the summary immediately.
• Proposed change: use “Share summary with team” and name the destination workspace beside the action.
• Unresolved question: do customers understand who can see a shared summary? Check with representative account managers.
• Product dependency: engineering must confirm the destination and whether sharing can be reversed.
• Acceptance check: before pressing the button, a participant can explain what will be shared and who will receive it.

The product manager owns the behavior question. The designer owns the proposed screen. The researcher, or the person conducting the session, owns the comprehension check. That division prevents an AI suggestion from becoming an accidental product promise.

Ask for alternatives before asking for Figma

The interesting decision arrives when the skill suggests adding a confirmation dialog. Is another step needed, or would a precise label and destination be enough?

Ask it to describe both options in text. Compare what each one makes visible and what interruption it adds. If sharing is consequential and difficult to reverse, a confirmation may be appropriate. If the screen already contains a complete review, another generic “Are you sure?” could add little.

Make the decision with the people who understand the actual workflow. Then ask for a Figma draft of the chosen option, using the existing components and the real behavior. The skill’s instructions support text proposals before drawing; the Figma step depends on the available tools and permissions.

A neat mockup is still a proposal. Check it against the implemented product before treating it as ready for development.

Keep the useful finding, discard the confident guess

Review the output sentence by sentence. “The destination is absent from these screenshots” is inspectable. “Customers do not trust the AI” needs evidence. A proposed copy change might be sensible even when the explanation attached to it is too confident.

Keep a small record of accepted and rejected suggestions. Rejections are useful when the same review happens again: “Do not suggest undo; this action cannot be reversed” is better context than another round of corrections.

For a broader redesign, use the product redesign baseline brief to define the customer task and the test it must pass. For a weekly review, keep the scope small enough that the team can follow a finding through to a checked change.

Start with one journey in the AI SaaS Design Director. Finish with a brief your designer can disagree with in specific terms. “The destination is already visible here” is progress. “Make it clearer” is another meeting.