Rubric: Frontend Architect
Purpose
Use this rubric for the primary curriculum outcome: a frontend architect who can design systems, guide teams, govern quality, and keep decisions aligned with product and operational reality.
Scoring model
| Level | Meaning |
|---|---|
| 1 | Feature-level reasoning; architecture risk is mostly invisible. |
| 2 | Understands architecture terms but applies them inconsistently. |
| 3 | Designs bounded systems with reasonable tradeoffs. |
| 4 | Leads cross-team architecture decisions with evidence and governance. |
| 5 | Establishes durable architecture capability across an organization. |
Capability rubric
| Capability | Level 3 expectation | Level 4 expectation | Level 5 expectation |
|---|---|---|---|
| Platform depth | Knows browser/runtime constraints well enough to avoid harmful abstractions. | Uses platform knowledge to select rendering, delivery, and interaction strategies. | Creates platform guidance that survives framework churn. |
| Architecture decision quality | Writes ADRs with context, alternatives, and tradeoffs. | Facilitates decisions under uncertainty and defines reversibility. | Builds decision systems: templates, review gates, exception policy. |
| Rendering/data architecture | Designs route rendering, server state, client state, and cache layers. | Aligns rendering/data strategy with product freshness, SEO, latency, and cost. | Establishes portfolio-wide patterns for rendering and data contracts. |
| Performance diagnosis | Can diagnose LCP, INP, CLS, hydration, bundle, and third-party regressions. | Creates budgets, monitoring, and performance review practice. | Turns performance into product and platform governance. |
| Accessibility/security/reliability | Understands browser attack surfaces, WCAG obligations, and degraded UX. | Defines launch gates and threat/reliability models for critical flows. | Makes these concerns institutional standards. |
| Design-system thinking | Designs durable component APIs and token contracts. | Governs package boundaries, accessibility contracts, theming, and adoption. | Creates a UI platform that enables multiple teams and AI-generated surfaces. |
| Observability and incidents | Defines useful client-side signals. | Connects RUM, errors, traces, releases, experiments, and incidents. | Uses production learning to drive architecture roadmap. |
| Cross-team influence | Guides a team through architecture work. | Leads reviews across teams without becoming a bottleneck. | Develops other architects and improves organization judgment. |
| Business alignment | Explains user and delivery impact. | Prioritizes technical investments using risk, cost, and product strategy. | Shapes product/platform strategy through technical insight. |
| Written communication | Produces clear architecture docs. | Writes persuasive RFCs and executive narratives. | Creates artifacts that become organization reference points. |
| Client-side security/privacy | Identifies common browser trust boundaries, storage risks, and third-party script risks. | Runs client-side security/privacy reviews with data-flow maps, CSP plans, consent-aware loading, and incident controls. | Establishes browser security/privacy governance across scripts, telemetry, storage, dependencies, and AI-generated surfaces. |
| Platform operating model | Can follow established standards and review packets. | Designs review cadence, exception registers, scorecards, and platform adoption plans. | Creates an adaptive architecture operating system that improves through production signals and reduces review burden through defaults. |
| AI/GenUI governance | Understands generated UI, tool, retrieval, and eval risk. | Defines component registries, eval gates, trace review, kill switches, and accessibility/security controls. | Builds organization-wide GenUI governance that links product value, model quality, cost, safety, and UI platform constraints. |
Evidence to collect
- Three ADRs with alternatives and outcomes.
- One architecture review packet completed for a real or simulated system.
- One capstone or project with diagrams, NFRs, and launch gates.
- A measurable quality improvement tied to production signals.
- A technical narrative written for non-frontend stakeholders.
- One completed route architecture note covering rendering, data, state, accessibility, security, observability, rollout, and ownership.
- One frontend quality scorecard reviewed with trend, owner, and next action.
- One client-side security/privacy review for a third-party script, analytics/replay flow, or sensitive route.
- One operating-model improvement that reduced repeated review comments or unowned exceptions.
Readiness signal
Architect readiness requires no critical row below level 3, level 4 in decision quality and written communication, and at least one demonstrated cross-cutting project that affected more than one team or system boundary.
Calibration scenarios
Use these scenarios to distinguish levels.
| Scenario | Level 3 answer | Level 4 answer | Level 5 answer |
|---|---|---|---|
| Slow dashboard on mobile | Profiles route, reduces JavaScript, fixes obvious LCP/INP causes. | Adds route budget, RUM segmentation, rendering/data changes, and release gates. | Turns learning into platform defaults, scorecards, and dashboard architecture standard. |
| Third-party analytics script request | Checks performance and security basics. | Requires owner, consent category, data map, load strategy, CSP impact, and kill switch. | Establishes third-party register, drift monitoring, policy gates, and executive-visible risk model. |
| Server function mutation | Validates input and handles errors. | Defines auth, authorization, idempotency, cache invalidation, progressive enhancement, and audit. | Creates action registry, review policy, fixtures, and migration guidance across teams. |
| Design-system component adoption failure | Improves docs and fixes component bugs. | Studies adoption blockers, API durability, accessibility contract, migration tooling, and exception path. | Evolves design system into a UI platform with scorecards, governance, and product-team feedback loops. |