Design for AI-built apps
Making an AI-built product look and feel like it was designed on purpose.
Design for AI-built apps: making it not look AI-madeAI-built apps look alike because the tools reach for the same components, neutral palettes, fonts and layouts. Fix it by deciding the product's own type, colour, spacing and voice as design tokens, then designing the flows and states the tools skip: empty, error, loading, onboarding and mobile.Building a design system for your MVPAn MVP design system is small: a set of tokens for type, colour, spacing and radius, a dozen components that use only those tokens, and one page of rules for layout and states. In a Tailwind v4 and shadcn/ui app it lives in globals.css and components/ui, and takes days to set up, not months.Dashboard design for MVPsDesign the dashboard around the one question a user opens it to answer. Lead with the number that matters and what it compares to, use bar or line charts rather than pies, show what needs action next, and make tables scan with right-aligned, tabular numbers in the user's currency. Cut anything that does not change a decision.Empty states, errors and loading states AI forgetsEvery screen that shows data needs at least four states: loading, empty, error and full. AI builders usually generate only the full one. In Next.js 15, add loading.tsx and error.tsx per route, give every list a designed empty state with one clear action, and show pending and error states on every form.How to make a shadcn app not look like shadcnChange the theme, not the screens. In a Tailwind v4 shadcn/ui app, set your own fonts with next/font and @theme inline, replace the colour tokens under :root and .dark, change --radius, adjust the type scale, then edit the Button and Card files directly, because you own that code.Landing pages for AI-built products that convertA landing page converts when a visitor understands what the product does, who it is for and what to do next within a few seconds. Replace the generated hero with a specific headline, show the real product, keep one primary call to action, answer the obvious objections, and keep the page fast.Making an AI-built app accessible (WCAG 2.2)Aim for WCAG 2.2 level AA. AI-built apps usually start from accessible components, then lose it in the custom parts: clickable divs, icon buttons with no name, missing focus outlines, placeholder-only labels, low-contrast text, tiny targets and errors shown only in colour. Check each area below against its success criterion and test with a keyboard.Onboarding flows that convert for new appsGood onboarding gets a new user to the first useful result as fast as possible. Ask only for what you need to start, skip the welcome carousel, let the first empty screen teach the next step, and offer help in context when someone reaches a feature, not all at once on day one.Teardown: redesigning a vibe-coded finance dashboardThe typical AI-built finance dashboard has the right parts and no priorities: a gradient header, four identical stat cards, a rainbow chart and placeholder rows. Redesigning it means picking the question users open it to answer, then rebuilding around that with real data, one accent colour, a readable chart and a table that shows what needs action.UX mistakes AI tools make in every appAI builders reliably get the happy path right and miss everything around it: what matters most on a screen, what happens when data is empty, slow or wrong, what an error actually says, and how the app behaves on a phone or with a keyboard. Check those areas before real users arrive.Why every AI-built app looks the sameMost AI builders generate from the same ingredients: shadcn/ui components, Tailwind's default scales, a neutral theme and the most common layouts in their training data. The sameness comes from defaults nobody changed, so it is fixable with a few deliberate decisions about type, colour, spacing and layout.
See if BlackFig fits your idea (it probably does)
A quick 30 minute call. No slides, no hard sell. You leave with a clear next step either way.