Mihua Design Generation Framework: Adapting Enterprise Component Systems
Fan Mihua
Cross-domain Designer
Hi, I’m Fan Mihua. This article explains how the Mihua Design generation framework connects to an enterprise’s existing stack, components, and design standards.
It focuses on four questions: adapting to a different frontend stack, importing proprietary components, keeping repeated generation within standards, and creating missing components that can later flow back into the library.
1. Can a different technology stack still be integrated?
Yes. Product facts and page responsibilities stay stable, while the implementation layer is adapted to the project’s real component APIs, state model, build system, and validation rules.
| Keep | Adapt |
|---|---|
| Page roles and core tasks | Component names and imports |
| Business objects, states, and outcomes | Props, events, slots, and state models |
| Primary and supporting views | Forms, dialogs, tables, and layout composition |
| Critical flows and acceptance criteria | Tokens, responsive behavior, builds, and verification |
Mihua Design has validated this boundary with shadcn, Ant Design React, and Ant Design Vue: implementations change, but page tasks, business state, and acceptance criteria remain.
2. How do proprietary components and styles enter the framework?
The path depends on the assets already available. Existing frontend libraries are converted into an AI-readable capability catalog. Figma-first libraries need design semantics before engineering assets can be generated and verified.
Path A: Existing frontend components
| Existing asset | Information to organize |
|---|---|
| Component code and types | Props, events, states, and composition |
| Documentation | Use cases, anti-patterns, and important differences |
| Design tokens | Color, spacing, radius, density, and semantic states |
| Business components | Page tasks, dependencies, and reuse boundaries |
Path B: Figma components
- Organize tokens such as color, spacing, typography, radius, and density.
- Complete component states, variants, interaction semantics, and naming.
- Generate component code, types, documentation, and usage rules.
- Validate layout, state, and responsive behavior in real pages.
- Write verified boundaries back to rules and the component index.
In the Arco adaptation, the workflow covered 64 component categories, 67 frontend components, and 12 admin pages. The important result is a verifiable transformation chain from design assets to engineering capabilities.
A real Arco adaptation record
3. Will repeated generation drift away from standards?
No. The component catalog, tokens, and rules define available capabilities. A page checklist and runtime output verify the result before and after generation.
| 01 Before | 02 During | 03 After |
|---|---|---|
| Define the page task and component boundary | Select and compose components from the checklist | Verify code, runtime output, and acceptance criteria |
| Stage | Primary basis | System work | Output |
|---|---|---|---|
| Before | Product facts, page checklist, component docs, and rules | Extract tasks, primary expression, multi-device needs, and required capabilities | Page generation checklist |
| During | Available components, tokens, and project rules | Compose components, preserve provenance, and bind state and interactions | Runnable page |
| After | Real code, runtime output, and acceptance criteria | Verify provenance, business regions, interactions, flows, visual output, and devices | Passed gates or repair items |
4. Can AI create missing components and feed them back?
Yes, but a generated component first remains project-level. It must be validated in a real page before it can be considered reusable and promoted into the shared library.
| Existing capability is sufficient | Existing capability is insufficient |
|---|---|
| Reuse an existing component or composition | Create a project-level component, validate it, then add documentation and tests before promotion |
- Search existing components and compositions first.
- Create a project-level component only when the gap is real.
- Validate states, interactions, and responsive behavior in a real page.
- Evaluate whether it has cross-page or cross-domain reuse value.
- Complete the API, docs, examples, rules, tests, and index before promotion.
Conclusion
A generation framework should not lock a company into one component library. Mihua Design keeps product facts above the implementation layer, adapts real stacks and assets below it, and uses rules plus quality gates to keep continuous generation controlled and verifiable.