Information Architecture Generator
Generate a complete Information Architecture (IA) for a product based on a service plan, PRD, or startup idea.
When to Use This Skill
Use this skill when the user provides:
- A service planning document
- A PRD (Product Requirements Document)
- A startup or product idea description
Trigger phrases: "IA 작성", "정보구조도 만들어줘", "화면 위계 정리해줘", "create IA", "generate IA", "make information architecture"
Knowledge Base: Navigation Flow Design Principles
An app or service is fundamentally the automation of user data manipulation.
The goal of screen design: translate the user's mental model and task flow into DB operations (CRUD).
Scope: This skill generates frontend routes (browser URLs). API endpoint design is a separate concern.
Step 1: Define Entities
Identify the core concepts (entities) the service handles, then map each user action to a CRUD operation.
| User Action | DB Operation | Example (E-commerce) |
|---|
| Create | Create | Sign up, add product, place order |
| View | Read | View profile, search/view product, order history |
| Edit | Update | Change password, update price, change order status |
| Remove | Delete | Delete account, remove product |
Step 2: Design Screen Hierarchy
Naming Rules:
- Plural nouns for collections — , , (not , )
- Entity-based naming — use data model names (), not UI labels (, )
- Minimize action segments — when a separate page is unavoidable, use a fixed set: , ,
1-Depth: Top-Level — Entity Collections
- URL pattern: (e.g. , , )
- Non-resource pages: (e.g. , )
2-Depth: Record Detail & Entry Points
- Rule: A single page handles only one entity unless absolutely necessary
- — Dynamic route, specific resource detail (e.g. )
- — Creation form (prefer modal when the form is simple)
3-Depth: Sub-pages of a Parent Record
/{entities}/:id/{sub-entities}
— Parent owns child records (e.g. )
- — Configuration page for the parent
- — Edit form that needs its own page
- Modal: simple action; preserve current page context
- Inline: page handles view + edit together (e.g. settings with save button)
- Separate page: multi-step form or independent flow
- Modals and inline editing reduce the need for action routes
Query Parameters: Reflect Page State in URL
- URL pattern:
- Filtering (), sorting (), pagination (), search ()
- Status view (), UI mode ()
- Use query params for view state instead of separate routes (e.g. not )
Step 3: Design Page Structure
Global Layout (areas shared across most pages):
- Header: brand, logged-in user info, notifications
- Sidebar: navigation aid / feature drawer (desktop & dashboards)
- Footer: legal info, copyright, support, sitemap
- Global Navigation: branches top-level paths; mobile → bottom tab bar or drawer
Content Area Types:
- Collection: a set of records for one entity — list, table, menu (e.g. )
- Single Item: one element from a collection — detail view (e.g. )
- Sub-page: child records, settings, or edit form of a parent (e.g. )
How to Generate the IA
Step 1: Analyze the Input
Read the provided service plan, PRD, or product idea. Extract:
- Core entities (what data does this service manage?)
- User roles (who uses this service? any admin/user separation?)
- Key features per entity (what CRUD operations are needed?)
- Navigation structure (what are the top-level sections?)
Step 2: Map Entities to CRUD
For each entity, list the screens required:
- Collection screen (list of all records)
- Single Item screen (detail of one record)
- Action screens (create, edit, delete flows)
Step 3: Build the Nested List
Output the IA as a Markdown nested list following this structure:
- /{entities}
- Collection Screen (`/{entities}`)
- Query params: `?status=`, `?sort=`, `?q=`
- Single Item Screen (`/{entities}/:id`)
- Sub-page (`/{entities}/:id/settings`) (modal, inline, or page)
- Sub-page (`/{entities}/:id/edit`) (modal or page)
- Child records (`/{entities}/:id/{sub-entities}`)
- Create Screen (`/{entities}/create`) (modal or page)
- /{static-page}
Rules:
- 1-depth items = top-level navigation sections (plural entity names or standalone pages)
- 2-depth items = main screens within each section
- 3-depth items = sub-pages, child records, or action forms of a parent
- Resource paths use plural nouns and entity-based naming
- Allowed action segments: , , — prefer modals/inline to reduce these
- Mark presentation format: append , , or where relevant
- Mark dynamic routes: use for record-specific screens
- Use query parameters for view state (filtering, status) instead of separate routes
- Include Global Layout section at the top (Header, GNB, Footer)
- Include Auth flow if the service requires login
Step 4: Add Screen Metadata
After the nested list, include a table summarizing each screen:
| Screen | Type | URL Pattern | Description |
|---|
| ... | Collection / Single Item / Action / Auth | | ... |
Output Format
Always output:
- Service Summary — 1–2 sentences summarizing the product
- Entities & CRUD Map — bullet list of entities with their operations
- Information Architecture — full nested list
- Screen Summary Table — metadata table
Save Instructions
When the task is complete, save the output to
in the current working directory unless the user specifies a different filename or location.
Use this format for the saved file:
markdown
# [Service Name] — Information Architecture
> Generated: [date]
## Entities & CRUD Map
...
## Screen Hierarchy
...
## Screen Summary
...