Tech Decisions
Choose the right framework and technical approach for your project — Next.js, Nuxt, or React with Vite.
Different frontend stacks share the same professional workflow: define the product experience, model the interface states, build components, wire data, verify quality, and ship. The framework changes where those responsibilities live.
For a design engineer, the useful question is not "Which framework is best?" It is "Which framework makes the product constraints easiest to express, preview, maintain, and hand off?"
Quick Choice Matrix
| Path | Best for | Watch for | Designer advantage |
|---|---|---|---|
| Next.js | Product sites, SaaS apps, dashboards, content-heavy apps, Vercel deployments | Server/client boundaries, caching, route conventions | Strong design-to-production path with app routing, metadata, image handling, and broad ecosystem support |
| Nuxt | Vue teams, content sites, product apps with Vue-first design systems | Module choices, Nitro deployment targets, Vue composable boundaries | Excellent conventions, readable templates, and smooth content authoring for design-system-driven teams |
| React + Vite | Embedded apps, design tools, prototypes, SPAs, custom runtime needs | Routing, data fetching, SSR, and deployment are assembled manually | Fast feedback loop and less framework ceremony when the product surface is highly interactive |
Pick the path that matches the product's operating model. A docs site, logged-in dashboard, marketing site, and canvas-style tool have different routing, data, performance, and collaboration needs.
Use Next.js when the product benefits from file-based routing, server rendering, metadata, image optimization, and a mature deployment story.
| Workflow area | Next.js decision |
|---|---|
| Routing | Use the App Router. Treat route groups as information architecture, not just folders. |
| Components | Keep pages and layouts server-first. Add "use client" only for browser state, effects, or event handlers. |
| Data | Fetch server data in Server Components or route handlers. Client state for interaction, not initial page loading. |
| Styling | Design tokens in global CSS mapped to primitives. No one-off colour values in feature components. |
| Quality | Test server-rendered flows, loading states, metadata, empty states, responsive layouts. |
Design engineer focus: Route structure, loading UI, error UI, metadata, and caching affect perceived product experience — these are UX decisions, not just engineering.
Use Nuxt when the team prefers Vue's template model, composables, and module ecosystem, or the design system already lives in Vue.
| Workflow area | Nuxt decision |
|---|---|
| Routing | File-based pages and layouts. Align page hierarchy with navigation and content strategy. |
| Components | Single-file components for tight template, logic, and style coupling. |
| Data | Nuxt data utilities consistently. Document loading, error, and refresh per page. |
| Styling | Tokens framework-agnostic when possible — move between Figma, CSS, and components. |
| Quality | Verify accessibility in rendered templates, not only component stories. |
Design engineer focus: Vue templates make structure highly visible. Use that to review semantic HTML, content hierarchy, and interaction states with designers earlier.
Use React + Vite for a fast SPA or tool-like surface without the full routing, rendering, or deployment conventions of a meta-framework.
| Workflow area | React + Vite decision |
|---|---|
| Routing | Choose and document the router early — it becomes your IA contract. |
| Components | Build a small set of primitives, then compose feature surfaces from them. |
| Data | Choose a data library deliberately. Document cache keys, stale states, mutations, optimistic updates. |
| Styling | Keep tokens centralized. Vite will not impose a design system structure for you. |
| Quality | Add browser tests for core flows — framework defaults won't cover app behavior. |
Design engineer focus: Vite is ideal for rapid exploration, custom interactions, and product surfaces where the UI behaves more like an application than a document.
Shared Professional Workflow
No matter which path you choose, the same checkpoints apply:
- Define the users, jobs, constraints, and success metrics.
- Map the information architecture and the primary user journeys.
- Specify components by variants, states, accessibility behavior, and responsive behavior.
- Build with typed data, predictable state, and explicit loading/error/empty states.
- Verify with automated tests, manual accessibility checks, and performance budgets.
- Ship with monitoring, rollback steps, and clear ownership.
Designer Collaboration Checklist
| Before handoff | Ask |
|---|---|
| Requirements | What user decision should this screen make easier? |
| IA | Can a new user predict where this task lives? |
| Component spec | Are hover, focus, disabled, empty, loading, error, and success states designed? |
| Responsive behavior | Does content reflow based on priority, not just available pixels? |
| QA | Can keyboard and screen-reader users complete the same task? |
| Delivery | What signal tells us whether this design actually worked? |
Collaborative Repository Workflow
Work safely with designers, developers, and agents in the same repository while redesigning UI, shipping features, and keeping the app functional.
Requirements Analysis
Translate business intent into precise, testable frontend requirements before a single line of code is written.