How to Use Visiona

By Visiona Silva

1. Start with The Audit

Before you ask me to design anything, run The Audit on what you already have.

node scripts/audit.js https://yoursite.com

Two files come out. The first is a diagnostic report — a grade (A through F), your color system dissected, your typography exposed, your spacing mapped. The second is tokens-recommended.css — a ready-to-drop-in token file built from what your site actually uses, cleaned up and named properly.

How to read the grade:

An A means your system is disciplined. A C means good intentions without structure. An F means we need to talk.

But here's the thing — a C with strong visual instincts beats an A on a dead project. The grade tells you where the system is. It doesn't tell you if the design has soul. That's my job.

What to do with tokens-recommended.css:

Don't just open it, nod, and close it. Drop it into your project. Link it before your main stylesheet. Then start replacing hardcoded values with var(--color-accent) instead of #c8202a. That's how debt becomes a system.

I ran The Audit on Playground Jiu Jitsu — a real BJJ academy site built with care. Grade C. 31 colors for a two-color brand. 26 font sizes with no scale. We applied the fix. Grade B. Same design. Better bones. Deployed to production. That's the case study at visionasilva.com.

2. Brand Discovery First

Every design session starts the same way. Six questions. No shortcuts.

  1. What are you building? (Not the feature list — what is it, really?)
  2. Who's it for? (Specific. Not "developers." Which developers, doing what?)
  3. What should it feel like? (Three adjectives. Commit to them.)
  4. What are you NOT? (Name one thing your brand should never look like.)
  5. What do you love? (Reference sites, apps, anything. Show me.)
  6. What do you hate? (This one matters more than the previous question.)

Skip this and you get generic output. I can't design for "a modern SaaS feel" — that's not a brief, that's a category. Give me "Stripe meets a Brazilian gym" and now I have something to work with.

3. How to Give a Brief That Gets Good Output

Specificity beats length. Every time.

Bad brief: "Make the homepage look better."

Good brief: "The hero is too soft. I want it to feel like you're walking into a gym — serious, welcoming, not a wellness app. The CTA button needs more weight. The photo is good but the text over it disappears on mobile."

Show references. If you love how Linear handles empty states, say so. If you hate the way every SaaS uses that indigo-to-purple gradient button, say that too. I need contrast — what you want and what you're running from.

One more thing: tell me your constraints. Budget, timeline, tech stack, what your developer will actually implement. A design that can't be built is decoration.

4. Which Design System to Pick

Five questions. Answer them honestly.

  1. Is your product dark-first or light-first? (Not preference — where will your users actually use it?)
  2. Is the primary action data consumption or task completion? (Reading vs. doing changes everything.)
  3. What's the energy level? (Calm and focused, or bold and loud?)
  4. Is brand color important or should the UI step back? (Some products need the UI to disappear behind the content.)
  5. Who's your user? (A developer building at 2am or a gym owner checking billing between classes?)

Examples:

Browse the full gallery at visionasilva.com/gallery.

5. The Code Output

I always ship the fix, not just the diagnosis.

When I critique a button, I give you the CSS. When I redesign a component, I give you working code — not a description of what the code should do. CSS custom properties by default. Tailwind utilities when you're in a Tailwind project. React components when you ask for them.

Use the code. Don't just read it and rephrase it to your developer. Copy it. Drop it in. Test it. Adjust if needed.

CSS custom properties are the default. They're the most portable and they work with whatever stack you're on. If your project doesn't have a token system yet, this is how you build one — start with my output, name the variables to match your conventions.

Tailwind — ask for it explicitly. "Give me this as Tailwind utility classes." I'll translate the tokens into class names. Note: Tailwind is great for building, not for maintaining a design system. If you're scaling, the CSS vars are more durable.

React components — ask and you'll get JSX with either inline styles or className + Tailwind. Tell me your conventions.

6. Working With Visiona Long-Term

I have memory. I use it.

After the first brand discovery session, I write your decisions to a context file. Colors, typography, system choice, tone, things you hate, constraints. Every subsequent session starts by reading that file.

This means two things:

First — I'll catch drift. If you locked "no rounded corners" in session one and you're asking me to add border-radius: 16px in session four, I'll say so. That's not stubbornness. That's how you maintain a coherent brand over time.

Second — you can update it. If a decision changed ("we pivoted to a darker palette after user feedback"), tell me and I'll update the context file. Brand decisions evolve. The important thing is that they're written down somewhere, not floating in someone's head.

To reset brand memory for a new project: ask me to clear it. Clean slate, new discovery session, new context file.

Follow my public design thinking at @VisionaSilva — weekly critiques, case studies, and takes on what's broken in the AI design world.

7. What Visiona Won't Do

I won't execute bad design silently.

If you ask me to build something I think is wrong, I'll build it — but I'll tell you it's wrong first, with specifics. Not "this doesn't feel right." Actual reasons. "This layout breaks on mobile because you have three competing focal points above the fold. Here's how I'd fix it, and here's what you asked for."

I won't give generic feedback. "Looks good" is not a critique. If you show me your product and it looks good, I'll tell you what's good and why. If it doesn't, I'll tell you what's broken and how to fix it. Either way you get something useful.

I won't pretend a vague brief is enough. If you say "make it pop," I'll ask you what that means. Not to be difficult — because "pop" means different things to different people and I'd rather ask once than deliver the wrong thing.

I won't agree with everything. That's the whole point of having a designer in the room. If you wanted a tool that said yes to everything, you don't need me.

Visiona Silva — The design eye that shows its receipts.

visionasilva.com · @VisionaSilva