Success Criteria

What it is. Success criteria are the numeric targets that sit in section five of every working design spec and prove whether the shipped feature delivered on its intent. They force every vague product hope into concrete measurable results that can be argued over before a single pixel leaves Figma or a prompt hits Cursor. In 2026 spec driven teams treat them as the contract between design intent and business reality. Write them right after edge cases while the user problem still burns in your head. Each one names the exact metric the baseline the target the time window and the user segment when it matters. If the intent paragraph claims the feature will cut churn then one success criterion must read churn for new users drops from 24 percent to 17 percent within 30 days post activation measured via Mixpanel cohort analysis. They connect the spec to real outcomes instead of designer vibes. Engineers use them to know when to stop polishing. PMs use them to decide if the feature gets more engineering time or gets killed. AI tools do not consume them directly but the clarity they force into the behavior and edge cases sections produces better prompts and fewer scrapped generations. Designers who master this section stop decorating interfaces and start owning product results that survive quarterly reviews.

What it isn't. Success criteria are not fluffy statements about how users will feel or how the design will intuitively make sense. Never write users will love this new flow or the interface feels cleaner. That language died with wireframes and belongs in the same bin. They are not vanity metrics pulled from a dashboard after launch to paint the project in a good light. They are not engineering acceptance criteria which only check if the code does what it was told. Success criteria measure what happens when real humans use the live feature over real time. They are not invented after the build ships or during a retro when the team scrambles to justify their sprint. A criterion without a number a baseline and a deadline fails the test immediately. They are also distinct from evals. Evals are the automated tests like does the empty state render the correct copy in under 800 milliseconds. Success criteria track whether that empty state actually drove the 35 percent lift in saves you promised in the spec. Mix them up and you will ship green test suites that still lose money.

Concrete example. The save to collection spec from the article shows success criteria operating at full strength. Instead of hoping users organize content better the criteria read 30 percent or more of weekly active users save at least one item per month average user reaches 2.4 collections within 30 days of first save and 60 percent or more of saved items get revisited inside 14 days. Those three lines came from real baseline data on repeat visit rates and gave the team a clear kill switch if the numbers did not move. Six months after shipping the actuals landed at 33 percent 2.7 collections and 61 percent revisit rate. The spec was updated in the repo with the real numbers and became the template for three more features that year. Another concrete case hit at Linear in 2025 during their smart triage feature. Success criteria demanded time to first team comment on new issues drops from 4.2 hours to 1.1 hours average triage accuracy reaches 87 percent as measured by manual audit of 400 tickets and power user retention lifts 19 percent in the following sprint. When early AI generated builds only moved the time metric by 40 percent the team rewrote the entire behavior section until all three criteria aligned in testing. A third example appeared in Vercel is 2026 preview deployment improvements. Success criteria required deployment preview open rate to climb from 41 percent to 68 percent within one week of launch engineering team satisfaction score on preview quality hits 4.6 out of 5 in their internal survey and rollback rate falls below 3 percent. These numbers shaped every edge case entry and forced the spec writer to confront awkward permission and network failure paths early. In each case the criteria stopped the team from celebrating beautiful UIs that failed to move the actual needle.

When to use when not to. Use success criteria in every spec that touches external users or drives business metrics. Drop them into onboarding flows checkout redesigns AI assist tools and dashboard overhauls at companies like Cursor Perplexity or Figma clones in 2026. They earn their keep during spec review meetings where they expose misaligned assumptions before the first prompt hits Claude Code. Reference them when routing the same spec to v0 for UI generation and again when QA writes test plans from the evals section. They turn portfolio case studies from pretty screenshots into proof that you can move metrics that matter to hiring managers. Skip them only for pure brand hero illustrations novel layout explorations that the design system cannot yet support or internal tools used by fewer than ten people where the sole measure is fewer Slack complaints. Never force them onto legacy teams still stuck on executive wireframe reviews because the conversation will collapse into blank stares. Write them immediately after edge cases while the pain points remain vivid. Challenge every target with a peer who will call it too soft then tighten it again.

Success criteria turn designers from people who push pixels into people who own results that actually ship.