In a previous post, I wrote that human judgment is what separates good vibe coding from mediocre vibe coding. One part of that is visual and editorial judgment. The idea felt a little abstract at the time. Then I spent more than ten rounds refining a single chart in DailyTrace with AI, and the point became much more concrete.
In the age of AI, making something has become cheap. Getting it right is still expensive.
The chart is called Before & After. It appears on an activity detail page and answers a simple question: What am I usually doing before a certain activity, and what do I tend to do afterward? It is a three-column Sankey chart. The left side shows "Before," the center is the activity itself, and the right side shows "After."
The first version shipped with a batch of analytics features. It ran. The data was correct. At a glance, it looked like a finished chart. But nearly every visual decision changed before I reached the final version. Those revisions are where the lessons in this article came from.
![[object Object]](/articles/images/3a24b730-4482-80fa-85ef-cc62196f4316)
Method 1: Define what "right" means first
Once AI reduced the time needed to build something to a few minutes, an old habit became risky: make it first, then decide whether it looks right.
AI output often arrives looking complete. The first version had data, colors, and a legend. Everything seemed to be there. But the center node, which should have been the main character, was an anonymous gray bar. The bands looked like flat rectangles laid side by side. Nothing flowed. All the pieces were present, but the idea was missing.
If I had only asked myself, "Is this good enough?" I probably would have settled for "fine." Instead, I asked a different question: What should the user see? My answer was that everything revolves around this activity. Time flows into it from the left, then flows out toward what happens next.
That standard made the problems obvious. The center node was not the visual focus, and the bands had no sense of movement. Define what "right" means first, then look for where the output falls short. Otherwise, "looks complete" can easily pass for "is correct."
Method 2: Describe the gap, not the feeling
"It doesn't look good," "make it flow better," and "give it more polish" are almost impossible to act on. If I leave the standard unstated, AI has to guess. It produces another version, I reject it on instinct, and the conversation goes nowhere.
Whenever I had a vague reaction, I made myself go one level deeper:
- "The middle feels strange" became "The center node is the hub for every flow, but it does not even have a name."
- "The bands look wrong" became "There is too much space between the bands, so they feel disconnected and static."
- "The style is inconsistent" became "Remove the rounded corners from both the nodes and the bands."
Each piece of feedback now pointed to a change I could verify. AI responded quickly, and the direction stopped drifting.
This is the same principle I use when describing a bug: state the precondition, action, expected result, and actual result so AI does not have to guess. The harder the problem, the more expensive vague feedback becomes.
Method 3: Give AI a reference
Some visual qualities resist verbal description. "The flow of a Sankey chart" is one of them. I tried talking about curves, spacing, and direction. A good reference image worked much better.
The reference changed the conversation. We stopped debating whether the chart felt fluid enough and started comparing visible differences. The bands needed space between them. The collapsed "Other" category needed a gray band to fill its node. Text on dark bands needed to switch to white automatically. I could point to each issue in the reference, then check it again after the revision.
A reference does not have to come from somewhere else. DailyTrace already had another Sankey chart called When It Happens, which shows when different activities tend to occur during the day.
Its visual treatment was already mature, so my first requirement for the new chart was simple: bring it up to the same level. When I later added an info button, I reused the same component and interaction instead of recreating them.
The closest reference is often the part of your own product that already works. Consistency comes from reusing the same thing, not rebuilding an imitation of it.
In my previous post, I described turning Apple's Human Interface Guidelines into documents that AI could check line by line. A guideline, a reference image, an existing design, and an older screen from the same product all serve the same purpose. They turn a vague feeling into something you can compare. Stop inventing adjectives. Find a reference.
Method 4: Change one dimension at a time
Looking back, the sequence of revisions is easy to follow. First I gave the center node an identity. Then I separated the bands, worked on the sense of movement, removed the rounded corners, and finally moved activity names from the legend onto the bands.
I tried to solve one kind of problem in each round. AI was perfectly capable of changing five things at once, but then I was left with a version where five variables had moved together. I could not tell which change helped or which one introduced a new problem. When one dimension changes at a time, the difference between two versions stays legible.
Each round took only a few minutes, so running more rounds was not expensive. Chasing five directions at once was. You can have many rounds, but each round should stay simple.
Method 5: Do not distort data just to make it prettier
Before changing the visuals, we had to answer a more basic question: What does this data actually say?
When I raised the problem with the center node, AI did not immediately redraw the chart. It first explained the data structure. "Before" and "After" are two independent distributions. The data records what I did before an activity and what I did after it, but it does not pair those observations into a path such as "French to Vibe Coding to Meals."
That sounds like an implementation detail, but it set the boundary for every visual decision that followed.
The reference chart had large crossing bands. They looked great, and I wanted them. AI refused. The reference could show crossings because its data contained two-dimensional relationships. DailyTrace did not have that pairing information. Drawing crossings anyway would invent relationships that were not in the data.
That refusal made me trust the result more. AI is often too willing to follow a request and make a bad idea look plausible. When it stops and says, "The data does not support this," that is worth paying attention to.
Now I ask two questions before drawing a chart: What does the data actually record? Does the data support the effect I want? A chart owes its first loyalty to the facts, and only then to beauty.
Method 6: Bring the decisive insight yourself
The breakthrough did not come from AI.
I had separated the bands and filled the nodes, but the chart still lacked movement. After staring at it for a while, I had an idea: reduce the center node to two-thirds of its original height and center it vertically.
The columns on either side stayed at full height. Because the center was shorter, the bands had to gather as they entered it, then spread out again. The curves appeared naturally, and the chart took on an hourglass shape. I gave the idea to AI, and a few minutes later I could see it rendered.
AI drastically shortened the distance between having an idea and seeing it on screen. But the idea that changed the design came from a spatial intuition I could not fully explain. It still had to come from me.
Once the collaboration becomes smooth, it is easy to slip into answering multiple-choice questions. AI offers a few options, and I pick one. That is convenient, but it can also confine the direction to whatever options AI happened to propose.
Multiple choice is useful when the direction is genuinely undecided. We had several ways to make the center node stand out: name it and make it the focal point, add a key number, or pull the flows inward. Agree on direction before building. It is much cheaper than throwing away a finished version. AI was good at turning intuition into a picture and putting disagreements on the table. The final call still belonged to the person making the product.
Method 7: Look at every version
Across all those revisions, I kept one rule: "It compiles" does not mean "it's done." I need to see the result.
After each change, AI rendered the view through the real rendering pipeline and inspected the image. A misplaced decimal in an opacity value, a label outside the bounds, or dark text on a dark band will not break the build. It will still ruin the chart. If no one looks at the rendered output, the work has not been checked.
That is only the first layer. The second is a real device with real data.
Mock data is unusually cooperative: four activities, neat proportions, content on both sides. My actual data was not. The moment I opened the detail page for "Sleep" on my phone, I found two problems the mock data had hidden. There was no adjacent activity before sleep, so the entire left side became a glaring blank. Another activity had occurred only once. Its percentage rounded down to "0%," yet it still sat in the legend.
Neither fix was hard. I added a gray skeleton on an empty side and folded anything below 1% into "Other." Finding those problems was the hard part. They did not come from a design exercise. They came from real data refusing to cooperate with the demo.
You can anticipate some edge cases, such as empty values, zeros, tiny proportions, and long labels. You will not anticipate all of them. I now let AI's render check catch the obvious failures, then use a real device and real data to expose the rest. Mock data always behaves. Edge cases appear when real data hits the design. Validation needs a visible result, and that result needs real data.
The seven methods are really one method
Taken together, the seven methods describe one idea: when making something is cheap, getting it right needs its own process.
Defining "right" gives me an acceptance standard before work begins. Describing the gap turns a feeling into an actionable change. A reference gives me something concrete to compare. Changing one dimension at a time keeps each check meaningful. At the same time, the boundaries of the data cannot move, human intuition cannot disappear, and the final result has to be seen.
This applies to far more than charts. The mood of a share card, App Store copy, one sentence in an empty state, or the timing of an animation can all be hard to describe even though the result looks obviously right or wrong.
In my previous post, I wrote that AI has made the ability to explain things clearly more important. After finishing this chart, I would add one thing: it is fine if you cannot explain the answer yet. Find a reference. Turn your reaction into a specific gap. Test one change at a time. Then put the real result in front of you and decide whether it is right.
By the tenth version, I finally understood what AI had saved me and what it had not. It saved the time spent turning an idea into a picture. It did not save the time I spent staring at that picture and asking, "What is still wrong?" That second part determined what the product eventually became.