Skip to main content
When reviewing an application, feedback is much easier to understand when it’s connected to the part of the product being discussed. Instead of sending messages like:
Change the button on the dashboard.
or:
I don’t like the section near the bottom.
AIWA’s preview commenting workflow allows collaborators and clients to leave feedback while reviewing the project. This creates a clearer cycle:
Keep feedback connected to the product instead of scattered across emails, messages, and screenshots.

​
Review the Preview

Before commenting, open the latest preview of the project. The preview lets you experience the application before the latest changes are published. Use it to review:
  • Pages
  • Layouts
  • Content
  • Navigation
  • Forms
  • Buttons
  • Mobile experience
  • User flows
  • New functionality
  • Recent changes
For client projects, this gives clients an opportunity to review the actual experience rather than relying only on screenshots.

​
Leaving a Comment

When you find something that needs attention, use the commenting functionality available in the preview. Comments should explain what needs to change and, where possible, why. Instead of:
Fix this.
write:
Make this button more prominent because it’s the primary action we want visitors to take on this page.
Specific feedback is much easier to act on.

​
Comment on the Relevant Area

When possible, connect feedback to the part of the interface you’re discussing. For example, imagine a pricing page contains:
A comment associated with the Agency plan might say:
Highlight this plan as “Most Popular” and make it more visually prominent than the other plans.
That’s much clearer than:
Make the pricing better.

​
Good Comments vs Vague Comments

Useful feedback describes the desired outcome. Vague
I don’t like this.
Better
This section feels too crowded. Increase the spacing between the feature groups and make the headings easier to distinguish.
Vague
Fix the mobile version.
Better
On mobile, these pricing cards feel too narrow and the text is difficult to read. Stack the plans vertically while keeping the desktop layout unchanged.
Vague
Change the dashboard.
Better
Make Monthly Revenue, Active Customers, and New Signups the primary metrics at the top of the dashboard. Move the activity feed below them.
The more specific the feedback, the easier it is to turn into a useful change.

​
Reviewing Client Comments

For agency projects, comments can become part of the client-review process. Your workflow might look like:
Don’t immediately implement every comment without reviewing it first. Some feedback may require clarification or affect other parts of the application.

​
Turn Feedback Into AIWA Prompts

Once you understand the requested change, turn the feedback into a clear instruction for AIWA. For example, the client comments:
The booking button should stand out more.
You might tell AIWA:
Make the “Book Appointment” button the primary call-to-action in the hero section. Increase its visual prominence while preserving the existing design style and mobile responsiveness.
The comment captures the client’s intent. Your prompt translates that intent into a clear product instruction. You don’t necessarily need to make one AIWA request for every individual comment. Suppose a client leaves these comments:
Homepage: Make the headline shorter. Hero: Make the booking button more prominent. Services: Move this section higher. Testimonials: Show three testimonials instead of six.
These are all relatively small homepage changes. You could combine them into one clear prompt:
Update the homepage with the following changes:
  • Shorten the hero headline while preserving the current message.
  • Make the booking CTA more prominent.
  • Move the Services section above Testimonials.
  • Display three testimonials instead of six.
Keep the existing visual identity and don’t modify other pages.
This can make iteration faster.

​
Separate Major Changes

Don’t combine everything simply because the comments arrived at the same time. Suppose another comment says:
Customers should be able to create recurring bookings.
That’s not a simple visual adjustment. It may affect:
Treat significant functional requests separately. For larger changes, consider using Plan Mode before building.

​
Clarify Ambiguous Feedback

Sometimes a comment isn’t specific enough to implement safely. For example:
Make this more premium.
That could mean:
  • Different typography
  • More spacing
  • Different imagery
  • Less visual clutter
  • Different colors
  • Better hierarchy
  • Different copy
Instead of guessing, clarify what the reviewer wants. This is especially important for client work where unnecessary revisions cost time.

​
Comments Can Reveal Bigger Product Problems

Sometimes feedback about one screen actually points to a deeper issue. For example:
I can’t figure out how to add a customer.
The problem might not be the button they’re commenting on. It may indicate that the application’s navigation or onboarding isn’t clear enough. Instead of simply making the button larger, consider the actual user problem. Ask:
What prevented the reviewer from understanding what to do?
Good product development solves the underlying problem, not only the surface-level comment.

​
Review Comments Before Building

For larger review rounds, go through all comments before making changes. You may discover that several comments are related. For example:
Comment 1: Dashboard feels crowded. Comment 2: Too many cards. Comment 3: Important numbers are difficult to find. Comment 4: Activity feed takes too much space.
These may all describe the same underlying problem:
The dashboard needs stronger information hierarchy.
Instead of four unrelated fixes, you can give AIWA one coherent objective.

​
Resolve Conflicting Feedback

If multiple stakeholders review the same project, they may disagree. For example:
Marketing Manager: Make the signup CTA larger. Designer: Make the hero cleaner. Founder: Add another CTA. Client: Remove the second CTA.
Don’t ask AIWA to implement contradictory instructions. Determine which direction should be followed first. For client projects, establish who has final approval.

​
Make the Changes

Once you’ve reviewed the feedback, use AIWA to implement the agreed changes. Your workflow becomes:
After AIWA makes the changes, review them yourself. Make sure the requested updates were implemented without breaking existing functionality.

​
Review the Updated Preview

Once the changes are ready, generate or open the updated preview. Check the areas that were changed. Then test anything that could have been affected. For example, if the client requested changes to a booking form, don’t only inspect the design. Actually submit the form and confirm the booking workflow still works.

​
Send It Back for Review

After you’ve checked the changes internally, send the updated version back to the client or collaborator. The cycle becomes:
If everything is correct, you can move toward approval. If additional changes are required, repeat the process.

​
Resolve Completed Feedback

Once a requested change has been implemented and verified, treat that feedback as completed. This helps distinguish between:
and:
For projects with many revisions, keeping track of completed feedback prevents the same requests from being revisited unnecessarily.

​
Don’t Publish Before Reviewing

A client comment shouldn’t automatically result in a production change. Use:
not:
This becomes especially important when the application already has real users.

​
Comments for Mobile Review

Comments can also be useful when reviewing mobile experiences. For example:
  • The Save button is difficult to reach on mobile.
  • This menu takes up too much of the screen.
  • The booking form requires too much scrolling.
  • These buttons are too close together.
When providing mobile feedback, mention that the issue occurs on mobile. For example:
On mobile screens, move the primary booking action closer to the top of the page. Keep the existing desktop layout unchanged.
That helps prevent a mobile fix from unnecessarily changing the desktop experience.

​
A Good Client Review Process

For agency projects, a strong review process looks like:
This keeps the agency in control of the development process while still giving the client a clear way to participate.

​
Keep Feedback in Context

The biggest benefit of preview commenting is context. Instead of:
you can move toward:
The closer feedback is to the product experience, the easier it is to understand and implement.

​
From Feedback to Better Products

Comments aren’t just correction requests. They can help you understand:
  • What users find confusing
  • Which features matter most
  • Where workflows break down
  • Which information isn’t clear
  • What clients expected
  • Where the product can improve
That creates the same continuous product loop we’ve discussed throughout AIWA:
Your first version isn’t the end. Feedback helps AIWA and your team continue evolving the application.

​
Next: Billing & Credits

The next section is Section 8, Billing & Credits, starting with Plans overview (Launchpad, Solo, Agency, Enterprise).

Plans Overview

Compare Launchpad, Solo, Agency, and Enterprise plans.