Products are never finished; the process shouldn’t pretend otherwise
Ask a designer or product manager to walk through a project, and you’ll likely get a tidy story: research first, then brainstorming with Post-its, sketches, a pixel-perfect prototype, user testing, and a clean ship. It’s a satisfying narrative — but rarely an accurate one. The reality of modern product development is messier, non-linear, and full of overlapping, half-finished work. Yet the idealized "linear process" persists as a mental model.
That model made sense when products were physical. You couldn't easily change a shipped object, so following a carefully staged process was materially important. Digital products changed that calculus. Updates can ship in minutes, not years, and the design space itself is now infinitely malleable. As a result, every digital product is effectively a work in progress — and our workflows have yet to fully catch up with that reality.
This is the environment we operate in at Figma, and it shapes how we think about both our own processes and the tools we build. Browser-based collaboration means files are no longer static documents passed around for approval. Work is shared via URL, often in real time, and people iterate together while the design is still alive. When it’s easy to share early and often, people do — hence the ubiquitous "[WIP]" label that signals to viewers that what they're looking at is unfinished.
Sharing early vs. sharing at the "right" time
Early sharing has clear upsides: faster feedback, faster course correction. But in a world where nothing is ever truly final, the traditional milestones disappear. There's no distinct moment where the problem statement locks, the solution locks, or the product locks. Instead, everything remains fluid, and collaborators hop in and out of evolving documents. Comments left on a section today may be moot tomorrow, and what you thought was signed off might have shifted by the time you look again.
Staying in the loop becomes a challenge in its own right. Figma has responded with notification improvements and mobile comments so feedback can be addressed on the go, plus integrations — like a Chrome extension for attaching files to Google Calendar events, and collaboration in Microsoft Teams and Zoom — to keep workflows connected. But no tooling removes the underlying difficulty: without a clear "done" moment, when should you actually ask for a review?
Switch from perfect timing to a predictable cadence
The temptation is to wait for the right moment — when the problem is well-aligned, the solution feels solid, or launch is near. In practice, that moment never reliably arrives. Problem spaces shift as you explore; iterations surface new directions; other parts of the product keep moving. The longer you wait to share, the higher the stakes and the greater the risk of misalignment.
At Figma, we've solved this by institutionalizing regular design critiques on Tuesdays and Thursdays. People bring their work regardless of its state and solicit direct feedback from peers and stakeholders. The value isn't in the polish of what's presented; it's in the rhythm. Stakeholders get weekly signals on how the team is thinking and feeling, which allows the team to iterate and adjust continuously. This predictable cadence beats chasing a perfect review moment every time.
Match the feedback format to the work's maturity
Knowing when to get feedback is one problem; knowing how to give it is another. A stakeholder dropping into a file with little context, leaving a string of comments that must be addressed, can derail momentum — a phenomenon often called the "swoop and poop." The issue isn't the feedback itself; it's the altitude at which it's offered.
One effective technique comes from Figma's marketing team. When sharing long-form content for review, they send stakeholders screenshots of drafts in FigJam rather than link out to a Google Doc. Feedback arrives as stickies, annotations, and reactions — an open-ended and expressive format that doesn't carry the same obligation to resolve every note. Stakeholders can share input without slowing the team down.
The flip side of lightweight, high-level feedback is that important detail can get lost. That's a real risk when comments are made casually and designs keep evolving. During a stint at Uber, my team shared an early idea about reordering the request flow to ask for the destination upfront. A researcher flagged a critical issue from our India team in a comment. The work progressed, the product shipped, and the feedback was never acted on — leading to a fix weeks after launch.
One framework we've found useful for addressing this is "flashtags," a convention popularized by HubSpot's co-founder. It's a simple way for leaders to signal the urgency of their feedback. Appending a flashtag to a comment communicates the degree of commitment:
- #fyi means the comment is informational, with no expectation of action.
- #suggestion means the author has seen the issue but isn't going to push for it.
- #recommendation means the author has considered making a stand but decided against it.
- #plea means the author feels strongly enough to want action, and the feedback should be prioritized.
There's no single right format for feedback in an always-WIP world. Porting screenshots into FigJam lowers the pressure of collaborative editing; flashtags bring nuance back to written comments and help key feedback rise above the noise. Choosing the right vehicle for the stage of the work — and making the priority explicit — keeps an inherently chaotic process moving forward.
Shipping before it feels ready
There is no perfect moment to ship. The work can always be better, so it’s tempting to keep polishing indefinitely. The idea of a launch review where every box is checked before release is a myth—and if it were real, it would only slow us down and undermine the benefits of constant iteration. We have to accept that the product that ships will be slightly different from what we last reviewed.
Yes, this means some launches will be imperfect. But customers are not judging us on that single moment. The product can still improve after it goes out. The Browser Company’s work on Arc is a great example: when Head of Design Dustin Senos shared a video asking for feedback, he got hundreds of replies with mocks, prototypes, and sharp suggestions. When you invite people into the work, they care and invest in it—and the result is often better for it.
More customers than you’d expect want to be part of the journey of watching a product grow. I saw this with Uber drivers when we invited a small group to help redesign the driver app; many kept texting us suggestions afterward. I see it now with designers in the Figma community who join every beta and push feedback in hopes of shaping the roadmap. Users prefer—and increasingly expect—products that are always getting better, not ones that are fine but static.
The takeaway: be less precious about what ships, because there is both an expectation and an opportunity to keep improving.
Our users prefer—and even expect—to have a product that’s always getting better. Not one that’s “good enough” but never changes.“Our users prefer—and even expect—to have a product that’s always getting better. Not one that’s “good enough” but never changes.”
Making peace with the work-in-progress
This is the new way of working. It feels chaotic because it challenges long-held assumptions about how work should happen. But it’s also liberating, closer to how the creative process actually works.
That said, even I feel lost or out of control at times in this world of constant iteration. My own journey with the WIP mindset is itself a work in progress, which is why I’ll keep developing these ideas in public on the Figma Community.
Confessions of modern design: How design is changing, and how we need to change with it
Yuhki Yamashita is the Chief Product Officer at Figma, where he leads the product and design teams. Before joining Figma, he spent over four years at Uber leading the redesign of the rider and driver apps, and prior to that he was responsible for the YouTube app on iOS at Google.
