Trusted by Market Leaders in Education, Travel, Finance and E-commerce since 2007
We put excellence, value and quality above all - and it shows
A Technology Partnership That Goes Beyond Code
“Arbisoft has been my most trusted technology partner for now over 15 years. Arbisoft has very unique methods of recruiting and training, and the results demonstrate that. They have great teams, great positive attitudes and great communication.”
How I Collected Structured Client Feedback on a Figma Make Prototype (Without Native Comments)
Building interactive prototypes today is easier than ever. Tools like Figma Make allow designers to quickly bring ideas to life, simulate flows, and create near-real product experiences without writing production-level code.
But there’s one thing that still isn’t as seamless: collecting structured, actionable feedback.
And if you’ve ever worked with clients on interactive prototypes, you already know feedback can either accelerate your design process… or completely derail it.
In this blog, I’ll walk you through how we tackled this exact challenge while working with a Figma Make prototype and how a simple integration completely transformed our feedback workflow.
The Context: When Prototyping Moves Faster Than Feedback Systems
I had already built a working prototype using Figma Make. The flows were interactive, the screens were functional, and we were ready for client review.
Everything was going smoothly until we hit a limitation.
Figma Make doesn’t support native commenting.
At first glance, this might not seem like a big issue. After all, feedback can always be shared over email, Slack, or even a quick call. But in reality, that approach creates multiple problems:
- Feedback gets scattered across different platforms
- Context is lost (Which screen? Which state?)
- Bugs and suggestions get mixed together
- There’s no easy way to track what’s resolved vs pending
And as a Product Designer, I wasn’t just looking for feedback. I needed feedback that was:
- Contextual (tied to specific UI elements)
- Actionable (clear, not vague)
- Trackable (so we could iterate efficiently)
The Problem: Feedback Without Structure Breaks the Workflow
Let’s break down the core issue.
When feedback is unstructured, it creates friction at every step:
- Clients say things like “this screen feels off” without pointing to anything specific
- Designers spend time guessing what the problem is
- Developers struggle to translate vague feedback into implementation tasks
- Iterations become slower and less effective
In short, bad feedback systems slow down good design work.
So instead of forcing the client to adapt to a broken system, we asked a better question: What if we redesign the feedback process instead of changing the tool?
The Idea: Borrowing a System From Product Development
During a discussion, our Product Manager suggested something interesting:
“If users can report issues on live websites, why can’t clients report issues on prototypes?”
That’s when we decided to experiment with Marker.io which is a tool typically used for reporting bugs and UI issues directly from live products.
The idea was simple:
- Treat the prototype like a live product
- Treat feedback like issue reporting
This shift in mindset changed everything.
The Solution: Integrating Marker.io Into Figma Make
Instead of switching tools or compromising on feedback quality, we integrated Marker.io directly into the prototype. Here’s exactly how we did it.
1. Injecting the Script
Marker.io provides a lightweight script that can be embedded into any web-based interface. We added this script directly into the Figma Make setup by inserting it into the <head> tag of every page.
Figma Make handled this smoothly. No extra engineering effort required.
(Reference image shows the script successfully injected into the prototype environment)
2. Enabling “Report Issue” on Every Screen
Once the script was live, something powerful happened:
Every screen in the prototype now displays a “Report Issue” button automatically.
This meant:
- Clients didn’t need to switch tools
- Feedback could be given in context
- Every screen became interactive, not just for navigation, but for feedback
(Reference image shows the Report Issue button integrated within the prototype UI)
This small addition completely transformed how feedback was captured.
3. Turning Feedback Into Structured, Visual Inputs
Now comes the most important part.
When a client clicked on “Report Issue”, they could:
- Capture a screenshot of the current screen
- Select the type of issue:
- Bug
- Improvement
- Add a clear title and description
- Annotate directly on the screen using:
- Rectangle
- Circle
- Text
- Highlight
(Reference image shows the annotation interface and issue reporting flow)
This eliminated vague feedback completely.
Instead of: “This layout feels weird.”
We now have: “The spacing between these two fields feels too tight” (with a highlighted area)
That’s the difference between subjective feedback and actionable feedback.
4. Centralizing Everything in One Place
All reported issues were automatically stored in a single Marker.io project dashboard.
This gave us:
- One centralized place for all feedback
- Clear visibility of:
- Open issues
- Resolved issues
- A structured workflow for reviewing and prioritizing changes
(Reference image shows the centralized issue tracking dashboard)
Instead of chasing messages across Slack or email threads, we now had a mini issue-tracking system built into our design process.
Why This Approach Worked So Well
From both a product and UX perspective, this workflow solved multiple problems at once.
1. Reduced Friction for Clients
Clients didn’t have to learn a new system.
They simply clicked a button and shared feedback instantly.
2. Eliminated Ambiguity
Every piece of feedback was tied to a specific UI state and element.
3. Separated Bugs From Improvements
This made prioritization much easier during iterations.
4. Saved Time Across Teams
Design, product, and development were all aligned on the same source of truth.
5. Improved Collaboration
Feedback became structured, visual, and easy to discuss.
Most importantly, We didn’t let a tool limitation block progress. We designed around it.
Key Takeaways for Designers
If you’re working with prototypes (especially interactive ones), here are a few lessons worth remembering:
- Tool limitations shouldn’t break your feedback loop
- You don’t always need a new tool; sometimes you need a better integration
- Treat design feedback like product issues, not casual comments
- Build your feedback system early, not after chaos begins
Final Thoughts
As designers, we spend a lot of time thinking about flows, UI, and interactions.
But there’s something equally important that often gets overlooked:
How feedback flows through your process
Because no matter how good your design is, if feedback is messy, unclear, or untrackable, your iterations will suffer.
This simple integration helped us maintain:
- Clarity
- Speed
- Accountability
Even without native commenting support.
And honestly? That’s the real win.
If you’re working with Figma Make or any prototyping tool that lacks structured feedback, this workflow is 100% worth trying.
Just published
