"The person who makes the 'draft' is the greatest"

Reading this article, I found myself nodding along intensely, and I wanted to write about what I've been thinking too. In respect to the article, I'll also use the term "draft" (tataki-dai) here.

A "draft," not a "rough sketch"

When people talk about a draft in design, they often mean something like a "rough sketch" or a "first pass." What I actually produce is close to that, but the nuance I want to emphasize is a bit different.

It's often said that professional designers finish 80% of the work quickly and spend the remaining 20% carefully polishing it. The image is something like "showing something for confirmation on the way to the final form I have in mind." A draft used in this sense really is just a "rough sketch."

Where it's a bit different is in the reason for showing the design in the first place: it's not "please confirm this" but "please give me your opinion."

The difference between "please confirm this" and "please give me your opinion" comes down to how strongly you hold the mindset of wanting the other person to change the design.

Design comps within a workflow that assumes improvement

We've moved from an era of pixel-perfect comps to an era of liquid and responsive design suited to the viewing environment, and along with that, the meaning of a design comp has changed too.

The production workflow has also shifted—from a solid approach where every page is fully decided before moving forward, to one where you start with something minimal that still communicates value, as in MVP or Scrum-style approaches.

In that context, I think what matters most is "how much feedback can you get on the design."

Of course, that's not the only thing that matters. There are plenty of other important points, but I feel this is a perspective worth keeping in mind when building a product that assumes ongoing improvement.

So how should you actually make it?

So concretely, how do you create a design that gets "poked at" effectively?

1. Incorporate feedback carefully

First, use a tool that makes it easy for people to give feedback.

I use Figma. Not only does it have a comment feature, but the fact that edits are reflected in real time gives people a good sense that "something is actually happening," which I really like. Have people add comments on the design you've created, and actively encourage questions and doubts too.

What matters is not leaving the comments you receive unaddressed. Even if a comment is obvious or just a confirmation, bring it up in a meeting or on Slack and carefully communicate how it will be resolved. This helps the whole team feel that "my opinion is being heard."

2. Resolve doubts with patterns

"I'm worried this part might not communicate well—what do you think?" ↑ This is a common type of comment.

"Huh, so what should I do? Fix it? Not fix it?" As a designer, you might tend to think this way, but when you get this kind of open-ended comment, things often move forward quickly if you just present a few possible patterns.

As a designer, you've probably already thought it through and reached a conclusion, so the idea is to show the intermediate options you considered along the way, as patterns.

Pairing each presentation style with its intent makes it easier to choose from, and gives people more confidence in their choice.

Example: Presentation A: Shows a lot of information per item and looks appealing, but takes up more space Intent A: Create a rich content experience that builds anticipation and drives users to click through

Presentation B: Compact information and appearance that preserves scannability Intent B: Make clever use of title copy so that even a small amount of text conveys a lot of content appealingly

↑ These are just rough examples, but if you can explain why something looks the way it does, then even if a pattern doesn't quite land, you've still established common ground for discussion.

3. Don't block with specialized knowledge

The people leaving comments are mostly not designers. Naturally, there are things they don't know, and plenty of things that are obvious if you've actually done the work yourself—especially things like font size, color, and UI where there's a fairly established theory.

Even comments that seem to override that kind of convention or premise should basically be welcomed. If something would genuinely break, show what it looks like when it breaks, or explain by pointing to existing applications as examples.

Explaining in words how well-known services like Google, Facebook, Twitter, or Instagram solve similar problems raises the whole team's design literacy.

Sharing "why something is the way it is (or isn't)" also matters a great deal for ongoing improvement after launch. Let's share the specialized knowledge that only designers tend to hold.

4. Don't explain everything from the start

This is a somewhat detailed technique. If you focus only on "putting things into words," you might end up filling Figma with a ton of explanatory text from the very beginning, showing every possible pattern, or even preemptively narrowing things down for people to choose from.

However, I don't think this is a good idea. The goal, after all, is to "create a draft that's easy to participate in," so explaining everything from the start defeats that purpose.

I'd recommend raising the current problems while intentionally building the proposal at a level of detail that doesn't fully resolve them all, and then fleshing it out from there. Of course, the issues should ultimately be resolved, but sharing that moment of resolution as it happens helps people outside the design role become able to explain the intent behind the design themselves.

5. Use your skills to move fast and deliver quality

This may seem to contradict points 1 through 4, but ultimately, being responsible for the quality of the design is still the designer's job. While you create the design meant for comments quickly, once all the feedback has been incorporated, go back and carefully review the final design data to deepen the details.

Reviewing to check for consistency with components and design guidelines, and whether the rules are easy to implement—that final "polish" is extremely important.

I don't think this approach suits creative work meant to showcase a strong visual world. But for things like web services or corporate sites for reasonably large organizations—work done within an organization or team—I think it's an interesting approach worth trying.

Seeing a design covered in comment pins gives me a fun sense that everyone's working on it together.