Design Frontend

VérifiéSûr

Conseils pour un design visuel distinctif et intentionnel lors de la création ou de la refonte d'interfaces utilisateur.

Spar Skills Guide Bot
DeveloppementIntermédiaire
22/07/2026
Claude CodeCursor
#frontend-design#ui-design#typography#visual-identity#art-direction

Recommandé pour

Synthèse automatique

Guide de direction artistique pour concevoir ou refondre une interface avec une identité visuelle assumée : palette, typographie et structure ancrées dans le sujet du brief plutôt que dans des rendus génériques.

Points forts

  • Ancre systématiquement les choix visuels dans le monde du sujet (matériaux, instruments, vocabulaire) au lieu de tendances abstraites.
  • Nomme explicitement les trois « looks » génériques produits par l'IA (crème + serif + terracotta, noir + accent acide, broadsheet à filets) et demande de les traiter comme des défauts plutôt que des choix.
  • Impose un processus en étapes — brainstormer, explorer, planifier, critiquer, construire, re-critiquer — et exige un risque esthétique justifiable.
  • Traite la typographie et les dispositifs structurels (numérotation, filets, libellés) comme porteurs de sens, avec vérification que la numérotation correspond réellement à une séquence.

Limites

  • Entièrement prescriptif : aucune règle technique, aucun code, aucune vérification d'accessibilité, de performance ou de responsive.
  • La qualité du résultat dépend fortement de la capacité du modèle à proposer des polices et des copy pertinentes ; le rendu peut rester génériques malgré les consignes.
  • Le fichier SKILL.md est tronqué à la fin (section processus et section écriture incomplètes), donc une partie de la méthode annoncée n'est pas lisible.
Quand l'utiliser

À utiliser au démarrage d'une nouvelle page ou lors d'une refonte visuelle quand on veut une identité forte et sur mesure plutôt qu'un template.

Quand l'éviter

À éviter pour des retouches UI mineures, du travail de design system ou d'implémentation technique, ou lorsque la charte graphique est déjà imposée.

Analyse de sécurité

Sûr
Score qualité82/100

This is a pure design-guidance instruction file with no declared tools and no executable content. It contains no shell commands, network calls, file operations, credential handling, or attempts to alter agent safety behavior; everything is advisory prose about typography, palette, layout, and self-critique of design work. Listing it poses no meaningful execution risk.

Aucun point d'attention détecté

Comment cette analyse est faite

Exemples

Distinctive landing page
Design a landing page for a small-batch coffee roaster in Lyon that delivers by bicycle. Pick the palette, type pairing and layout yourself — I want something that could not be mistaken for a template — and explain your reasoning.
De-templating an existing homepage
Here is the copy for my SaaS homepage. Reshape the visual direction so it doesn't read like a default AI-generated landing page: propose the hero concept, a type scale, and any structural devices that actually encode something about the product.
Aesthetic direction critique
Critique the aesthetic direction of my portfolio site for a documentary photographer, then propose one real risk worth taking plus a specific palette and typography pairing.

name: frontend-design description: Guidance for distinctive, intentional visual design when building new UI or reshaping an existing one. Helps with aesthetic direction, typography, and making choices that don't read as templated defaults. license: Complete terms in LICENSE.txt

Frontend Design

Approach this as the design lead at a small studio known for giving every client a visual identity that could not be mistaken for anyone else's. This client has already rejected proposals that felt templated, and is paying for a distinctive point of view: make deliberate, opinionated choices about palette, typography, and layout that are specific to this brief, and take one real aesthetic risk you can justify.

Ground it in the subject

If the brief does not pin down what the product or subject is, pin it yourself before designing: name one concrete subject, its audience, and the page's single job, and state your choice. If there's any information in your memory about the human's preferences, context about what they're building, or designs you've made before – use that as a hint. The subject's own world, its materials, instruments, artifacts, and vernacular, is where distinctive choices come from. Build with the brief's real content and subject matter throughout.

Design principles

For web designs, the hero is a thesis. Open with the most characteristic thing in the subject's world, in whatever form makes sense for it: a headline, an image, an animation, a live demo, an interactive moment. Be deliberate with your choice: a big number with a small label, supporting stats, and a gradient accent is the template answer, only use if that's truly the best option.

Typography carries the personality of the page. Pair the display and body faces deliberately, not the same families you would reach for on any other project, and set a clear type scale with intentional weights, widths, and spacing. Make the type treatment itself a memorable part of the design, not a neutral delivery vehicle for the content.

Structure is information. Structural devices, numbering, eyebrows, dividers, labels, should encode something true about the content, not decorate it. Many generic designs use numbered markers (01 / 02 / 03), but that's only appropriate if the content actually is a sequence - like a real process or a typed timeline where order carries information the reader needs. Question if choices like numbered markers actually make sense before incorporating them.

Leverage motion deliberately. Think about where and if animation can serve the subject: a page-load sequence, a scroll-triggered reveal, hover micro-interactions, ambient atmosphere. An orchestrated moment usually lands harder than scattered effects; choose what the direction calls for. However, sometimes less is more, and extra animation contributes to the feeling that the design is AI-generated.

Match complexity to the vision. Maximalist directions need elaborate execution; minimal directions need precision in spacing, type, and detail. Elegance is executing the chosen vision well.

Consider written content carefully. Often a design brief may not contain real content, and it's up to you to come up with copy. Copy can make a design feel as templated as the design itself. See the below section on writing for more guidance.

Process: brainstorm, explore, plan, critique, build, critique again

For calibration: AI-generated design right now clusters around three looks: (1) a warm cream background (near #F4F1EA) with a high-contrast serif display and a terracotta accent; (2) a near-black background with a single bright acid-green or vermilion accent; (3) a broadsheet-style layout with hairline rules, zero border-radius, and dense newspaper-like columns. All three are legitimate for some briefs, but they are defaults rather than choices, and they appear regardless of subject. Where the brief pins down a visual direction, follow it exactly — the brief's own words always win, including when it asks for one of these looks. Where it leaves an axis free, don't spend that freedom on one of these defaults. Just like a human designer who's hired, there's often a careful balance between doing what you're good at and taking each project as a chance to experiment and learn.

Work in two passes. First, brainstorm a short design plan based on the human's design brief: create a compact token system with color, type, layout, and signature. Color: describe the palette as 4–6 named hex values. Type: the typefaces for 2+ roles (a characterful display face that's used with restraint, a complementary body face, and a utility face for captions or data if needed). Layout: a layout concept, using one-sentence prose descriptions and ASCII wireframes to ideate and compare. Signature: the single unique element this page will be remembered by that embodies the brief in an appropriate way.

Then review that plan against the brief before building: if any part of it reads like the generic default you would produce for any similar page (work through a similar prompt to see if you arrive somewhere similar) rather than a choice made for this specific brief — revise that part, say what you changed and why. Only after you've confirmed the relative uniqueness of your design plan should you start to write the code, following the revised plan exactly and deriving every color and type decision from it.

When writing the code, be careful of structuring your CSS selector specificities. It's easy to generate CSS classes that cancel each other out (especially with a type-based selector like .section and a element-based selector like .cta). This can happen often with paddings/margins between sections.

Try to do a lot of this planning and iteration in your thinking, and only show ideas to the user when you have higher confidence it'll delight them.

Restraint and self-critique

Spend your boldness in one place. Let the signature element be the one memorable thing, keep everything around it quiet and disciplined, and cut any decoration that does not serve the brief. Not taking a risk can be a risk itself! Build to a quality floor without announcing it: responsive down to mobile, visible keyboard focus, reduced motion respected. Critique your own work as you build, taking screenshots if your environment supports it – a picture is worth 1000 tokens. Consider Chanel's advice: before leaving the house, take a look in the mirror and remove one accessory. Human creators have memory and always try to do something new, so if you have a space to quickly jot down notes about what you've tried, it can help you in future passes.

More on writing in design

Words appear in a design for one reason: to make it easier to understand, and therefore easier to use. They are design material, not decoration. Bring the same intentionality to copy that you would bring to spacing and color. Before writing anything, ask what the design needs to say, and how it can best be said to help the person 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 something does in plain terms rather than selling it. Being specific is always better than being clever.

Use active voice as default. A control should say exactly what happens when it's used: "Save changes," not "Submit." An action keeps the same name through the whole flow, so the button that says "Publish" produces a toast that says "Published." The vocabulary of an interface is the signposting for someone navigating the product. Cohesion and consistency are how people learn their way around.

Treat failure and emptiness as moments for direction, not mood. Explain what went wrong and how to fix it, in the interface's voice rather than a person's. Errors don't apologize, and they are never vague about what happened. An empty screen is an invitation to act.

Keep the register conversational and tuned: plain verbs, sentence case, no filler, with tone matched to the brand and the audience. Let each element do exactly one job. A label labels, an example demonstrates, and nothing quietly does double duty.

Du fichier au premier essai

Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.

Consulter la source et ses fichiers annexes

Ce téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.

1. Télécharger le fichier

Télécharger SKILL.md

Depuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/frontend-design-mrwakgfo/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.

Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.

mkdir -p '.skill-downloads/frontend-design-mrwakgfo' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/frontend-design-mrwakgfo/download' --output '.skill-downloads/frontend-design-mrwakgfo/SKILL.md.part' && mv '.skill-downloads/frontend-design-mrwakgfo/SKILL.md.part' '.skill-downloads/frontend-design-mrwakgfo/SKILL.md'

2. Vérifier les prérequis

Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.

Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.

Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.

3. Charger la skill

Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.

Claude Code
test -f '.skill-downloads/frontend-design-mrwakgfo/SKILL.md' && test -s '.skill-downloads/frontend-design-mrwakgfo/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/frontend-design' && cp -R '.skill-downloads/frontend-design-mrwakgfo' '.claude/skills/frontend-design'

Cursor
test -f '.skill-downloads/frontend-design-mrwakgfo/SKILL.md' && test -s '.skill-downloads/frontend-design-mrwakgfo/SKILL.md' && mkdir -p '.cursor/skills' && test ! -e '.cursor/skills/frontend-design' && cp -R '.skill-downloads/frontend-design-mrwakgfo' '.cursor/skills/frontend-design'

OpenSkills

OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.

Installation officielle d’OpenSkills
openskills install './.skill-downloads/frontend-design-mrwakgfo'

openskills read 'frontend-design-mrwakgfo'

La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.

Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.

openskills sync

Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.

4. Faire un premier essai

Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :

Lis .skill-downloads/frontend-design-mrwakgfo/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.

Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.

Skills similaires