frontend-design
Frontend Design Approach this work as a Design Lead at a small studio known for giving every client a unique visual identity that could never be mistaken for anyone else's. This client has rejected templated proposals and is paying for a distinct point of view: make decisive, clearly opinionated choices about color palette, typography, and layout based on the specific requirements of this brief, and take a genuine aesthetic risk you can explain and defend. Stay grounded in the subject If the brief does not pin down what the product or subject is, define it before designing: name a specific subject, its audience, and the site's single goal, and state that choice. If you have anything in memory about the user's preferences, context about what they are building, or designs you have made for them before — use it as a cue. The subject's own world — its materials, tools, artifacts, and characteristic language — is where distinctive choices come from. Build the design throughout with the brief's actual content and theme. Design principles The hero is a thesis. In web design, the opening (hero) is the statement. Open with the most distinctive thing in the subject's world, in whatever form suits it: a headline, an image, an animation, a live demo, or an interactive moment. Weigh your choice carefully: a big number with a small label, a few supporting stats, and a gradient accent is the formulaic answer — use it only if it truly is the best option. Typography carries the page's personality. Pair display and body fonts deliberately; do not fall back on the familiar font families you reach for on every other project. Establish a clear type scale with intentional weight, width, and spacing. Make the type treatment itself a memorable part of the design, not a neutral content-delivery vehicle. Structure is information. Structural elements (framing devices, numerals, eyebrows, dividers, labels) must encode something true about the content, not decorate it. Many generic designs use numbering (01 / 02 / 03), but that only fits when the content genuinely is a sequence — an actual process, or a categorized timeline where the order carries information readers need. Ask yourself whether choices like numbering are truly justified before including them. Use motion deliberately. Think about where and when motion can serve the subject: a page-load sequence, scroll-triggered reveals, hover micro-interactions, or ambient spatial atmosphere. One well-orchestrated moment usually makes a stronger impression than scattered effects; pick what the direction calls for. That said, sometimes less is more, and superfluous motion is part of what makes a design feel AI-generated. Match complexity to the vision. Maximalist directions demand elaborate execution; minimalist directions demand absolute precision in spacing, type, and detail. Refinement is executing the chosen vision well. Weigh the copy carefully. A design brief often contains no real content, and writing the copy is up to you. Text can make a design look just as templated as the visuals themselves. See the writing guidance below for details. Process: Brief, Explore, Plan, Critique, Build, Critique again Calibration: AI-generated design today tends to cluster around three main styles: A warm cream background (near #F4F1EA) with high-contrast serif display type and terracotta accents; A near-black background with a single accent in bright acid green or vermilion; A broadsheet-newspaper layout with hairline rules, zero border-radius, and dense columns. All three styles are valid for certain briefs, but they are DEFAULTS rather than DELIBERATE CHOICES, and they show up regardless of subject. Where the brief locks in a visual direction, follow it exactly — the brief's words always come first, even when they call for one of these styles. Where the brief leaves you freedom, do not spend that freedom on these defaults. As with a hired human designer, there is usually a deft balance between doing what you are good at and treating each project as a chance to experiment and learn. Work in two passes: Pass 1: First, brainstorm a short design plan from the brief: create a compact token system of color, typography, layout, and a signature element. Color: describe the palette as 4–6 named hex values. Typography: fonts for 2+ roles (a characterful display font used sparingly, a supporting body font, and a utility font for captions or data if needed). Layout: the layout concept, using short descriptive sentences and ASCII wireframes to visualize and compare. Signature: one single element that makes this page memorable and expresses the spirit of the brief in a fitting way. Pass 2: Then review that plan against the brief before building: if any part reads like the generic default you would produce for any similar page (try running through a similar request to see whether you land in the same place) rather than a choice made specifically for this brief — revise that part, stating what you changed and why. Only after you have confirmed the plan's relative distinctiveness do you start writing code, following the revised plan exactly and deriving every color and typography decision from it. A note on writing code: be careful with the specificity of your CSS selectors. It is easy to create CSS classes that cancel each other out (especially between type-based selectors like .section and element-based selectors like .cta). This commonly happens with padding/margins between sections. Try to do most of this planning and iteration in your head, and only show the idea to the user when you are highly confident it will please them. Restraint and self-critique Concentrate your boldness in a single place. Let the signature be the one memorable thing, keep everything around it quiet and disciplined, and cut any ornament that does not serve the brief. Taking no risk is sometimes itself a risk! Build to a baseline quality bar without showing off: responsive on mobile, clearly visible keyboard focus states, respect for reduced-motion settings. Critique your own work as you build (take screenshots if your environment supports it — a picture is worth a thousand words). Remember Coco Chanel's advice: "Before you leave the house, look in the mirror and take one thing off." Human designers have memory and always try to do something new, so if you have room to jot quick notes about what you have tried, it can help you on later runs. More on writing in design Text appears in a design for one reason only: to make the design easier to understand, and therefore easier to use. Copy is design material, not decoration. Bring the same intentionality to the words that you bring to spacing and color. Before writing anything, ask what the design needs to say, and how best to say it to help users navigate the experience. Write from the end user's side of the screen. Name things by what people control and recognize, never by how the system is built. A person manages "notifications", not "webhook config". Describe what a feature does in plain terms rather than trying to sell it. Specific always beats clever. Use the active voice by default. A control should say exactly what happens when it is used: "Save changes", not "Submit". An action keeps one name across the entire flow, so a button that says "Publish" produces a toast that says "Published". An interface's vocabulary is the signage system for someone exploring the product. Cohesion and consistency are how people learn to use an app. Treat error states and empty states as moments to orient, not to set a mood. Explain what went wrong and how to fix it, in the interface's voice rather than a person's. Error messages do not apologize, and they are never vague about what happened. An empty screen is an invitation to act. Keep the voice conversational and appropriately tuned: simple verbs, sentence case, no filler words, with a tone that fits the brand and audience. Let each element do exactly one job: labels label, examples illustrate, and nothing quietly carries two jobs at once.
Preview the Skill package contents
Inspect the folder structure and the SKILL.md instructions before downloading.
Package contents are collapsed
Click the button below to view this package's folder structure and SKILL.md content.
How to install this AI Skill
Related Skills
Keep building your workflow.
nodejs-backend-patterns
Guides you in building Node.js backends with production patterns using Express/Fastify and backend best practices. Backend Dev, Node.js Dev, Fullstack Dev
View Skill Codingclaude-api
Helps developers build applications with the Claude API/SDK and AI integration patterns. The Anthropic repo currently includes the claude-api skill. AI Engineer, Backend Dev, Fullstack Dev
View Skill Codingtypescript-advanced-types
Helps AI use Generics, Conditional Types, Mapped Types, and other advanced TypeScript techniques.
View Skill