You photograph a whiteboard sketch, drop it into UX Pilot or Visily, and ten seconds later you have six polished variants of the same screen. The temptation is to pick the one that looks best and move on. That is the exact mistake this lesson exists to prevent. The six variants differ in visual treatment, but visual treatment is not what you are choosing between; you are choosing between six different ways of serving a user need, and the prettiest variant is frequently the one that serves it worst. This lesson teaches you to multiply one sketch into six directions and then critique each one against the user need rather than the polish, shipping a variant comparison table with a go or no-go and a rationale paragraph that a stakeholder will trust.

The Prettiest Variant Won, and It Was Wrong

A designer sketches a rough settings screen on a whiteboard, snaps a photo, and runs it through Visily. Out come six variants. Variant four is gorgeous: generous whitespace, a soft card layout, a hero illustration, beautifully balanced type. The team gravitates to it instantly. It photographs well, it would look great in the portfolio, and it feels finished. They are forty seconds from picking it when the lead asks the question that reframes everything: "what is the user actually trying to do on this screen?"

The answer is: change their notification settings quickly and leave. Variant four, the pretty one, buries the actual toggles below a large illustration and spreads six settings across a spacious layout that requires scrolling on a laptop. The user who wants to mute notifications in five seconds has to scroll past decoration to find a toggle. Variant two, which the team had dismissed as "boring," puts all six toggles in a tight, scannable list visible without scrolling, with a clear save action. Boring variant two serves the need. Pretty variant four fights it. The polish that drew the eye was actively misleading, because it optimized for the wrong thing.

This is the sketch-to-variant trap. The tool multiplies your sketch into options that vary mostly in surface treatment, and surface treatment is the thing humans are wired to react to first. Left unchecked, the team picks with their eyes, and the eyes are tuned to beauty, not to the user's job.

The tool gives you six ways something can look. Your job is to evaluate six ways it can work. Confusing the two is how the prettiest variant beats the right one.

Why the Tool Pushes You Toward Polish

UX Pilot and Visily are optimized to make sketch-to-variant output look finished, because finished-looking output is what demos well and what users of the tool reward. That is a reasonable product decision and a real trap for you. When all six variants are polished, polish stops being a differentiator, yet it remains the loudest signal in the room. The variants are competing on a dimension that no longer separates them while the dimension that matters, fit to the user need, is quiet and easy to overlook.

There is a second pull. The variants tend to share the sketch's structure and vary the styling, so the genuinely different structural ideas, the ones that would actually change how the screen works, are underrepresented. Six variants can give the feeling of having explored the space while really only exploring the paint. You have to read past the styling to ask whether any of the six embodies a meaningfully different approach to the task, or whether they are six coats on one structure.

The Critique: Against the Need, Not the Polish

The discipline is a critique pass that deliberately ignores visual quality and scores each variant on how well it serves the user need. To do this without your eyes hijacking the judgment, run the critique in a fixed order of questions, the same set for every variant, so beauty never gets to jump the queue.

For each variant ask: One, does the user's primary task have a clear, fast path, and how many steps or scrolls does it take? Two, is the single most important action obvious and reachable without hunting? Three, what happens to this variant under real content, a long label, an error, an empty state? Four, does this variant make a structurally different bet from the others, or is it the same structure restyled? Five, what does this variant cost the user that the others do not? Notice that none of the five asks "is it attractive." Attractiveness is real and matters at the end, but it is the last gate, not the first, and a variant that fails the need does not get to the attractiveness gate at all.

The Squint Test and the Grayscale Trick

Two fast techniques keep polish from biasing you. First, the grayscale trick: review all six variants in grayscale, which strips the color and much of the visual appeal and forces you to judge layout, hierarchy, and flow on their merits. The variant that still reads clearly in gray is structurally sound; the one that fell apart was leaning on color to hide a weak structure. Second, the squint test: blur your eyes and look at each variant; the one where the primary action still pops is the one with real hierarchy, not just decoration. Both tricks are cheap ways to mute the polish signal so the structure can speak.

The Variant Comparison Table: Six Rows, One Verdict Each

The artifact is a variant comparison table, one row per variant, built so a stakeholder can see the reasoning at a glance. The columns are: the variant (a thumbnail or label), the primary-task step count, the structural bet it makes in one phrase ("toggles-first, no decoration" versus "guided, illustration-led"), the biggest risk it carries, and a go or no-go verdict. Crucially, the table is sorted by fit to the user need, not by visual appeal, so the variant that serves the task best sits at the top regardless of how it photographs.

Below the table sits the rationale paragraph, which is the part that makes the artifact defensible. In a few sentences you state which variant you are recommending, why it wins on the user need, and what you are deliberately giving up by not choosing the prettier option. Naming the trade-off out loud ("we are choosing the toggles-first layout over the illustration-led one; we lose some visual warmth and gain a five-second task completion") is what separates a decision from a preference. It tells the stakeholder you saw the pretty option, understood its appeal, and chose against it on purpose for a stated reason.

The Go or No-Go Is a Decision, Not a Ranking

Resist the urge to rank all six from best to worst, because a ranking invites the team to negotiate up the list toward the prettier options. A binary go or no-go per variant forces clarity: this one advances, these five do not, and here is why each no-go lost. The no-go reasons are the same kind of artifact as the kill criteria in the concept sprint; they are the documented judgment that proves the decision was made on the user need, not on which variant looked best in the meeting.

The Three Variant Failures to Catch

Across many sketch-to-variant sessions, three failures recur.

Failure One: The Beauty Anchor

The team anchors on the most attractive variant and then rationalizes its usability. Catch it with the grayscale trick and the fixed-order critique, which force the need questions before the beauty question. If the variant you love loses in grayscale, your love was for the paint.

Failure Two: Six Coats of Paint

All six variants share one structure and differ only in styling, giving a false sense of exploration. Catch it by asking question four of the critique for every variant: does this make a structurally different bet? If the honest answer for all six is no, you have not explored; you have restyled. Go back and prompt for structural divergence ("show me a version with no settings page at all," "show me a version where settings are inline").

Failure Three: The Portfolio Pull

A designer favors the variant that will look best in their portfolio over the one that serves the user, often without admitting it. Catch it by naming the trade-off in the rationale paragraph; if choosing the prettier variant requires you to write "we are accepting slower task completion for visual appeal," the sentence itself usually exposes the bad trade and forces an honest choice.

When the Pretty One Is Also the Right One

Sometimes the most attractive variant genuinely is the best fit, and the discipline is not a rule that the pretty one must lose. The point is that beauty cannot be the reason it wins; fit to the user need has to be. If variant four had put the toggles first and the illustration served comprehension rather than blocking the task, it could win on the need and be pretty too, and you would document that it won on step count and clarity, with attractiveness as a bonus, not the basis. The discipline protects you from picking with your eyes; it does not require you to pick the ugly thing out of penance.

This is the L2 discipline applied to variant selection. The tool supplies the polished options fast; you supply the critique that scores them on the job, not the gloss. The comparison table and the named trade-off are your verification mechanism, the proof that the variant you advanced won on the user need and not on the fact that it looked best on the wall.

Putting It to Work This Week

Take a real sketch, run it through UX Pilot or Visily for six variants, and resist the instant pick. Review all six in grayscale. Run the fixed-order critique, need questions first, on each. Build the comparison table sorted by fit, not appeal, with a go or no-go and the structural bet per row. Write the rationale paragraph naming exactly what you give up by not choosing the prettier option.

You will know it is working the first time you advance the "boring" variant over the gorgeous one and can explain, in one paragraph, why the boring one serves the user better, with a step count to prove it. The tool will always hand you polish, because polish is what it is built to produce. Your job is to look past the polish to the job the screen has to do, and to leave behind a table and a paragraph that show you chose the right variant, not the pretty one.

Getting Six Real Directions, Not Six Skins

The whole exercise is only worth running if the six variants are genuinely six directions, and by default the tools will not give you that; they will give you one direction in six outfits. So the real skill begins before you ever click generate, in how you frame the request and what you photograph. A whiteboard sketch that already encodes a single rigid structure will produce six restylings of that structure, because the tool reads the sketch as a near-finished layout and treats its job as cleanup. If you want structural range, sketch loosely and deliberately ambiguously, or better, sketch two or three genuinely different arrangements of the same screen and feed each one in, so the tool diverges from multiple starting points rather than polishing a single one.

You can also force divergence with the prompt that accompanies the photo. Most designers upload the image and accept the defaults, which is how you end up with six skins. Instead, instruct the tool explicitly toward structural alternatives: "give me one version where everything is on a single screen with no scrolling, one where the settings are inline in context rather than on a dedicated page, one that is a guided step-by-step, and one that is a dense power-user table." Now the six variants occupy genuinely different regions of the design space, and the comparison becomes meaningful because you are choosing among approaches rather than among paint jobs. The test of whether you got real range is simple: if you can describe each variant's structural bet in a phrase and no two phrases are the same, you have six directions. If the only way you can tell them apart is by describing their colors and spacing, you have one direction and wasted the exercise. Range is something you engineer into the input; it is not something the tool reliably volunteers.

The Value of the Original Sketch as an Anchor

Keep the original whiteboard photo visible next to the six variants throughout the critique, because it is a quiet anchor against a specific failure: the tool silently dropping or adding things you did not ask for. Sketch-to-variant tools routinely invent UI elements that were never in your sketch (a search bar, a filter row, an avatar) because those elements are statistically common on screens of that type, and they sometimes omit something you drew because it did not match a familiar pattern. When you critique against the original, you catch these additions and omissions, and you ask the right question about each: did the tool add value by suggesting an element you had not considered, or did it hallucinate a component that has no home in your actual product? The sketch is your record of intent. Without it on screen, you are critiquing the tool's interpretation of your idea as if it were your idea, and the drift goes unnoticed until an engineer asks where the search function is supposed to connect.

The Conversation the Table Is Built to Win

The variant comparison table is not really a documentation artifact; it is an instrument for winning a specific, predictable argument, and understanding the argument changes how you build the table. The argument is this: a stakeholder, often a senior one, walks in, points at the prettiest variant, and says "I like that one." If your only response is "but this other one is better for the user," you are now in an opinion-versus-opinion contest that the more senior or more confident person usually wins. The table changes the contest. It lets you say "that one ranks fourth on task speed; here is the step count, here is what it costs the user, and here is the one I am recommending and why." You have moved the conversation from taste, where seniority wins, to evidence, where the argument wins. That is the entire function of sorting the table by fit rather than appeal: it puts the user-serving variant at the top before anyone has a chance to anchor on the pretty one.

This is why the rationale paragraph must name the trade-off explicitly rather than quietly recommending the better variant. "We are choosing the toggles-first layout and giving up some visual warmth to gain five-second task completion" is a sentence that respects the stakeholder's instinct while overriding it with evidence. It concedes that the pretty variant has a real virtue, which disarms the defensiveness that comes from feeling dismissed, and then it shows the trade in terms the stakeholder can evaluate. The designers who lose these arguments are the ones who present the right variant as obviously correct and treat the stakeholder's attraction to the pretty one as a failure to understand. The designers who win present the trade honestly and let the cost-benefit make the case. The table and the paragraph together are how you turn "I like that one" from the end of the conversation into the start of one. And when the evidence genuinely favors the prettier variant, the same instrument lets you say so with confidence, because you will have ranked it on the need and found it at the top on its merits, not just on its looks.

Key Takeaways

• UX Pilot and Visily multiply one whiteboard sketch into six polished variants in seconds, but the variants differ mostly in surface treatment, and surface treatment is exactly what humans react to first, so the team tends to pick with their eyes.
• The prettiest variant is frequently the one that serves the user need worst; the polish that draws the eye can be actively misleading because it optimized for appearance, not the task.
• Run a fixed-order critique that asks the user-need questions (clear fast path, obvious action, real-content behavior, structural bet, user cost) before the attractiveness question, so beauty never jumps the queue.
• Use the grayscale trick and the squint test to mute the polish signal: a variant that reads clearly in gray and whose primary action pops when blurred has real structure, not just decoration.
• The three variant failures to catch: the beauty anchor (rationalizing the prettiest variant's usability), six coats of paint (all six sharing one structure, a false sense of exploration), and the portfolio pull (favoring what looks best in your portfolio over what serves the user).
• Ship a variant comparison table sorted by fit to the need (not appeal), with a binary go or no-go and structural bet per row, plus a rationale paragraph that names exactly what you give up by not choosing the prettier option, which turns a preference into a defensible decision.