Transcript
00:00:00If you've been watching this channel for some time, you probably know that we've covered a lot
00:00:03of design workflows and tools. We've been testing all of them for months and we finally figured out
00:00:08why the same model can give you something that looks completely custom or something that immediately
00:00:13screams AI generated. It comes down to three levels. Level one is designing a single page and
00:00:19there's one thing most people skip that's the entire reason their output looks generic. Level
00:00:23two is where you stop designing pages and start designing systems and the workflow here is
00:00:28completely different. And level three is how we test designs against each other to find the version
00:00:34that actually works, which is the part we use on every real project now. So level one is about
00:00:39creating a good design for a single page. This is the level that most people teach because it's the
00:00:44foundation of every good design. We talked in our previous video about how Opus 4.7's design
00:00:50capability has gotten so much better and a lot of the AI slop we used to see is gone. Earlier when we
00:00:55used to give it a simple prompt like creating a landing page, it would just straight up take the
00:00:59purple and white theme and build everything around it. That specific pattern has gotten better. But
00:01:04just like any other AI model, this one also converges to safe patterns. And from all our testing and
00:01:09experimenting with it, we have found that it defaults to one particular style every time. So now whenever
00:01:15we see that style, it's a dead giveaway that the site came from Opus 4.7 and it's only a matter of time
00:01:21before it becomes the next AI slop. So we need other ways to make this website look better.
00:01:25Now this level mostly comes down to prompt engineering and how we specify the app because
00:01:30if you structure your prompt properly, you can just one shot the app entirely. The prompt should start
00:01:35with the intent of the website you are aiming to build, then mention the non-negotiables, like the
00:01:39exact things you want in the app and how you want the UI elements to look. After that, you specify the
00:01:44color system. Now here we use OKLCH, which is basically a measure of lightness, chroma and hue.
00:01:49Using OKLCH instead of the usual RGB or HSL is better because it represents colors the way the
00:01:55human eye actually perceives them, so it handles lightness and balance better. It also creates
00:01:59smoother gradients, unlike hex codes which can produce ones that look uneven. Now once you have
00:02:04set the color scheme, you also need to mention the contrast flows. Contrast is a very important
00:02:08factor of UI design because it actually creates a hierarchy that guides your eyes toward the things that
00:02:13matter. Without explicit contrast, the model treats every element as equally important,
00:02:18which makes it hard to form the visual hierarchy. And to make sure the website doesn't look like
00:02:22AI slop, you also have to control the typography from the prompt, so you define which fonts are banned
00:02:27because of AI slop and which ones to use in different areas of the design. Fonts like Inter and Geist
00:02:33have become AI slop giveaways because every agent reaches for them by default, so calling them out
00:02:38explicitly forces the model to look elsewhere. Then you define the layout and rhythm of the website,
00:02:42but first you need to know about symmetry and asymmetry. Symmetric layouts have components
00:02:47evenly placed on the grid with a balanced look, which is more suited toward professional and
00:02:51straight designs. But for a more artistic look, go for asymmetry because that gives you more room
00:02:56to experiment. It is especially good when you need to use negative space since that lets the design
00:03:01breathe. The kind of product you are building decides which one fits better. Then define all the sections
00:03:06that you want, the materials you'll use, and how the website should behave responsively. And the most important
00:03:11part is mentioning the anti-patterns. These are the hallmarks of AI slop like the simple centered CTA,
00:03:17Lucid icons, and gradients with glassmorphic design. So once you give this prompt to Claude Code or
00:03:22whichever agent you are using, it will analyze your app and go through the implementation details. Then it will
00:03:27build the app just like the prompt described, with asymmetry because of the artistic goal and proper use of negative space.
00:03:34So level 2 is about keeping the same design across every page of the site because most agent generated apps
00:03:40fall apart the moment you leave the landing page. Often when generating whole apps with agents, you might
00:03:45have encountered exactly this. The landing page is mostly pretty good, but when you go to the other pages,
00:03:50they don't follow the UI style as coherently as they should. The dashboard ends up with different
00:03:55button styles, different spacing, different typography, almost like the agent forgot it was building the
00:04:00same app. The other pages end up looking like they're not even a part of the same site and it gives away
00:04:05that the site was generated by an agent. Sometimes the design does hold on the auth pages, but then on
00:04:10the dashboard, the style breaks completely. So for that, you need to create two of the most important
00:04:15files, Claude.md and Design.md. These two files are what keep the design consistent across the whole site.
00:04:21In Claude.md, as we've talked about many times, you only put your project information, not the design.
00:04:27This is because the file stays loaded in the session all the time and design content there will just
00:04:32distract the agent when it's working on something else, but it's still the key file because it keeps
00:04:37the context of the project which informs good design. For the design itself, we need a separate file
00:04:42which mentions everything for the visual system, the layout, the colors, the typography and all the
00:04:47details we covered in level 1. The design.md should be the kind of file that any agent could pick up and
00:04:52immediately understand what the visual system is. And just like in the previous level, you need to
00:04:57define the color system in OKLCH here too. To create these two files, we gave Claude code a detailed
00:05:03prompt covering what each file needs and it generated both files for us. The Claude.md is short, just
00:05:09containing the project's details. The design.md is longer with each and every detail, including color codes,
00:05:15typography choices, and everything else. But that isn't the end of the design.md. We need to keep
00:05:20refining it over time. So we put a line at the start, telling the agent to add any new design value
00:05:25it finds to this file. That way, every session starts from a more refined version of the design
00:05:30system than the one before it. But just letting Claude create the design.md isn't enough,
00:05:35because what it generates doesn't follow best practices properly. Google has open-sourced their
00:05:40template for the design.md file. The template also contains commands to cross-verify your design.md
00:05:46against it and flag any errors. So you can just prompt your agent to iterate using those commands
00:05:51to perfect the design.md. And this still isn't the end of level 2. To generate good enough designs at
00:05:56this level, you also need to audit them against existing design principles. For that, there are
00:06:00many open-source skills that do exactly this. You can use any of them, but we use VersaLab's skill,
00:06:06because instead of hard-coding all the principles inside the skill, it points to an external source
00:06:11that they're actively maintaining. So the principles stay up to date with current best practices instead
00:06:16of being frozen at whatever was state-of-the-art when the skill was first written. You install this skill
00:06:21in the project, run it, and your design comes out in way better shape than it was before. But before we
00:06:25move forwards, let's have a word by our sponsor. So I recently started using ZillysCloud and let me tell
00:06:30you why. Most RAG apps work fine with a handful of docs, but the moment you throw in real data,
00:06:35they start falling apart because the setup just wasn't designed to handle that kind of load.
00:06:40Milvus is the most starred open-source vector database on GitHub with over 44,000 stars,
00:06:46and it's built to handle that kind of load, but self-hosting means managing infrastructure yourself.
00:06:51So that's where ZillysCloud comes in, the fully managed version with the same API that's up to
00:06:5610 times faster, and you can set it up in minutes without changing a single line of code.
00:07:00So we ran a semantic search query on ZillysCloud, and the results are actually relevant because it
00:07:05understands meaning not just keywords, and the response time is almost instant even with a large
00:07:11dataset. We also ran a recommendation query given one article. It found the five most similar ones
00:07:16across the entire dataset ranked by similarity in under a second. And the dashboard tracks your cluster
00:07:21performance, storage usage, and data metrics including collection and entity counts in real time. No credit card
00:07:27needed, just click the link in the pinned comment and try ZillysCloud for free.
00:07:31So level three is about testing the design programmatically, the same way engineers verify
00:07:36code with TDD. Now we know you can't visually write tests the way you do with code. With code,
00:07:41there are clear inputs and outputs for everything. Design doesn't have that because it's more subjective
00:07:46and can't be quantified like code can, but just because it's subjective doesn't mean we can't write
00:07:51tests for it. The reason TDD works for code is that the test pins down what the behavior should be,
00:07:57and the implementation has to satisfy that pin. The same idea applies to design just with different
00:08:01kinds of pins. In the app we were building, the first step was the same as before, to create the
00:08:05clod.md and design.md files before even thinking about implementation. Now tests should always be
00:08:12written before the code, that way the implementation can actually be tested against them. If we write tests
00:08:17after the implementation, the agent slacks off. It just writes test cases that optimize toward the
00:08:22existing code, because that code is already in its context. Writing the test first forces the
00:08:27implementation to fit the test instead of the test fitting the implementation. So we use the design
00:08:32files as the source of truth for the tests because these files contain all the anti-patterns that we can
00:08:37programmatically verify against. Every anti-pattern in design.md becomes a test case. Every color rule,
00:08:44every spacing constraint, every typography choice gets a programmatic check. We gave Claude Code a
00:08:49detailed prompt to write the test cases specifying every section it should focus on. Also if you are
00:08:54enjoying our content, consider pressing the high button because it helps us create more content like
00:08:59this and reach out to more people. With your prompt, it will write all the test cases for the design
00:09:04of the app. It writes multiple types of tests. There are the static tests, which directly check for the
00:09:09anti-patterns we mentioned in the prompt. Then there's the visual testing, which basically uses
00:09:14play right underneath and runs regression testing to make the site incrementally better. It will also
00:09:19write test cases for other components and helper functions like scan and report. Now these tests
00:09:24check for the static anti-patterns, but design testing needs something else. For that, there is
00:09:28another tool called Visly Test, which is basically a CLI that conducts TDD for UI. The way it works is
00:09:34that it runs local TDD, where you can check the design as the code changes. So you can monitor the
00:09:39diffs yourself instead of relying on the agent's self-monitoring. You also get a better diff with
00:09:44metadata and other details, which makes review faster. Without that metadata, you are just comparing two
00:09:49screenshots side-by-side and hoping you spot the difference. With it, Visly tells you exactly which
00:09:54pixels changed and by how much. To use it, first install the CLI by running the install command from the
00:10:00docs. Once it's set up and initialized, it's ready to go. Now just open Claude code and tell it to use
00:10:05TDD and implement whichever part of the UI you want using the Visly CLI as the testing medium. When
00:10:10you run the Visly TDD command, a local server starts and monitors the screenshot changes. To send the
00:10:16screenshots, Claude basically writes separate tests with the name Visly. These tests use playwright
00:10:21screenshotting mechanisms to push the images to the viewer on the server. From there, you can approve or deny the
00:10:27design and view diffs comparing it to the previous version. Each rejected diff becomes feedback the
00:10:32agent uses to adjust the next pass. Over a few iterations, the design converges to what you actually
00:10:37want instead of what the agent thinks you want. Now the prompts used here can be found in AI Labs Pro
00:10:43for this video and for all our previous videos from where you can download and use it for your own
00:10:47projects. If you've found value in what we do and want to support the channel, this is the best way to do it. The
00:10:52links in the description. That brings us to the end of this video. If you'd like to support the channel
00:10:57and help us keep making videos like this, you can do so by using the super thanks button below. As
00:11:02always, thank you for watching and I'll see you in the next one.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video