Figma Design Specification Request
Component-Based Design (Next.js / React Compatible)
| Item | Content |
|---|---|
| Subject | Figma Design Specification (Component-Based) |
| Target Framework | Next.js (React) [To be configured] |
| Styling | Plain CSS / Tailwind CSS |
| Intended Assignee | UI Designer / Design System Manager |
1. Background and Purpose
This project adopts Next.js (React) as the frontend framework. To ensure a smooth implementation process, we request Figma designs that incorporate component-based thinking from the design stage.
Please follow the rules and guidelines described below to ensure design data can be smoothly converted to code.
2. Basic Principles of Figma Design
2-1. Component-Based Granularity Design
Please design with a component-based approach and organize with conscious granularity.
Step 1 — Define Styles
Before creating components, define the following as Figma Styles or Variables:
- Color Style: Primary / Secondary / Semantic / Neutral colors
- Text Style: Combinations of Font Family, Size, Weight, Line Height
- Effect Style: Shadows (corresponding to elevation levels)
Step 2 — Component Structure
Create components that reference Styles and organize them in the following categories (category names should function as a team's common language):
- Primitives (Smallest Parts): Icons, badges, labels, and other minimal components that cannot be divided further
- Components (Parts): Buttons, input fields, cards, modals, and other reusable parts with fixed appearance and behavior
- Patterns (Structures): Headers, form layouts, list pages, and other flexible layout guidelines combining Components
Note: Component names should be in English and use names corresponding to React component names (PascalCase) (e.g.,
PrimaryButton,CardItem). Category names should prioritize functioning as a team's common language, emphasizing "clear naming at a glance" over strict hierarchical rules.
2-2. Thorough Use of Auto Layout
Design all components using Auto Layout in preparation for responsive implementation.
- Clearly indicate whether horizontal or vertical stretching is expected
- Unify Padding, Gap, Min/Max Width values in
pxunits for CSS implementation - Properly use stretch settings (Fill / Hug / Fixed) considering content increase/decrease
- Set appropriate constraints for each element (corresponding to parent frame resize behavior)
2-3. Variant Settings
Manage components with state changes or variations centrally using Variants.
Set Variant property names in camelCase with appropriate names that are self-explanatory (e.g., state, size, variant).
- Buttons:
state=default/state=hover/state=disabled/state=loading - Form inputs:
state=default/state=focus/state=error/state=disabled - Size variations:
size=small/size=medium/size=largeetc.
Note: Variant names should support CSS data attributes (
data-state="hover"etc.) or aria attributes. Unify both property names and values in camelCase (e.g.,state=default,size=medium).
2-4. Component Property Settings
Actively utilize component properties beyond Variants.
- Boolean properties: Flags to control part visibility (e.g.,
showIcon,hasLabel) - Text properties: Define replaceable text like labels and descriptions (e.g.,
label,placeholder) - Instance swap properties: Allow icon and internal component replacement (e.g.,
icon,leadingElement) - Slot properties: Define areas for inserting child content (e.g.,
prefix,suffix,children)
Note: Property names should be in camelCase and correspond to React Props names.
2-5. Layer Naming Conventions
Do not use Figma's automatic naming (Frame 42, Group 7, etc.). Name layers to correspond with code component names and variable names following these rules:
- Component names in PascalCase (e.g.,
PrimaryButton,CardItem) - Property names in camelCase (e.g.,
variant,isDisabled,showIcon) - Layout frames with descriptive names (e.g.,
layout/container,section/hero) - Icons unified with
icon/prefix + PascalCase (e.g.,icon/ArrowRight,icon/CheckCircle)
Note: AI tools and code generation tools use layer names as identification criteria, so meaningful naming directly affects code quality.
2-6. Specification Annotations
For specifications, behaviors, and intentions difficult to convey through design alone, add text annotations near relevant frames or components. Place them where implementers can immediately understand.
Note: Use Figma's comment function only for temporary notes, confirmations, and feedback exchanges. For specification explanations, use text on canvas rather than comments. Mark comments as resolved after completion.
3. Design Token Definitions
Define the following design tokens as Figma Styles or Variables, assuming conversion to CSS Custom Properties (CSS Variables).
3-1. Color Tokens
- Primary / Secondary / Accent colors with their gradations (100-900)
- Semantic colors:
success/warning/error/info - Neutral / Gray scale
- Background, text, and border colors
3-2. Typography Tokens
- Font Family (specify Web font names)
- Font Size
- Font Weight
- Line Height / Letter Spacing
3-3. Spacing Tokens
When defining spacing scales, recommend 4px or 8px base (e.g., 4 / 8 / 12 / 16 / 24 / 32 / 48 / 64px).
3-4. Other Tokens
- Border Radius (
sm/md/lg/full) - Shadow (corresponding to elevation levels)
- Z-index scale (as needed)
3-5. Token Naming Convention and Export Format
To improve conversion accuracy to CSS Variables and implementation tools, follow these naming and export rules.
Naming Convention: Use / delimiter in {category}/{group}/{name} format. Since / functions as a group delimiter in Figma's Style panel, unify Style names and token names.
color/primary/default
color/primary/hover
color/semantic/error
typography/body/md
spacing/md
radius/lg
shadow/elevation/1
Export Format: Use plugins like Tokens Studio to enable JSON format export. Define structures assuming conversion to Style Dictionary or CSS Variables.
4. State Design
Implementation uses data attributes or aria attributes for state management. Reflect state changes in Figma according to the following policy:
- Always provide designs for all states of interactive UI
- Example: Button →
state=default/state=hover/state=active/state=disabled/state=loading - Example: Accordion →
state=closed/state=open - Example: Modal →
state=hidden/state=visible
- Example: Button →
- For areas expecting animations or transitions, prepare both before and after frames and note transition duration and easing in remarks
- Always include error states, empty states (no data), and loading states
5. Layout and Responsive Design
5-1. Breakpoints
Deliver designs corresponding to the following breakpoints (consult in advance if changes are needed).
| Name | Screen Width | Notes |
|---|---|---|
| Mobile (sm) | ~ 767px | Smartphone portrait |
| Tablet (md) | 768px ~ 1199px | Tablet / Landscape |
| Desktop (lg) | 1200px ~ | PC Standard |
5-2. Grid System
- Clearly specify column count, gutter width, and margin width used at each breakpoint as Figma Grid settings
- Specify content maximum width (Max Width)
6. Figma File Structure
Organize Figma files with the following page structure.
| Page Name | Content |
|---|---|
| Cover | File overview and update history |
| Design Tokens | List of Styles / Variables definitions (as needed) |
| Components | Library of all components (Primitives → Components → Patterns order) |
| Pages | Design for each page (both PC / SP compatible) |
| Prototypes | Prototypes of main interactions and flows (if needed) |
Note: In the Components page, describe Props and usage in each component's Description field in the following format. AI tools and code generation tools reference this field to generate code, so please do not omit it.
Component: PrimaryButton
Usage: Button for primary actions. Used for form submission, confirmation operations, etc.
Props:
- variant: primary | secondary | ghost
- size: sm | md | lg
- disabled: boolean
- loading: boolean
7. Delivery and Communication Rules
7-1. Sharing Method
- Share Figma file sharing links (edit permissions) with our contact person
- Contact address will be provided separately
- If component masters exist in separate files, ensure our contact person can view and access those files
7-2. Review and Feedback
- Feedback will use Figma's comment function
- Please reflect modifications within [To be configured] business days as a principle
- Please consult via [To be configured] in advance if major specification changes occur
7-3. Export and Assets
- Image assets (icons, illustrations, etc.) should be exportable in SVG or PNG (2x) format
- Use fonts available on Google Fonts or as Web fonts, or clearly specify licenses
7-4. Prohibitions and Cautions
- Avoid flattening components; maintain layer structure
- Third-party plugin-specific features may impact implementation, so please confirm in advance
8. Contact Information
| Item | Content |
|---|---|
| Our Contact Person | (Enter contact name and department) |
| Contact Method | (Enter email / Slack / chat tool, etc.) |
| Design Review Flow | Figma comment → Contact person review → Approval |
| Questions/Consultation | Please confirm any uncertainties before starting work |
End
Support
If you have any other questions, please contact us or check out Our Slack Community.