Written Spec

A written spec is the one page document that forces clarity before any pixel gets pushed. It names the exact problem the work solves identifies the user segment pins a single success metric lists the primary failure modes and draws hard cut lines on scope. This becomes the foundation for everything that follows with the Figma file treated as appendix material that supports the spec rather than driving it. In 2026 this document is table stakes for any senior designer who wants to survive budget cuts and role consolidation at companies still hiring. It replaces the old PM handoff and puts the IC in charge of the metric the date the research and the launch write up. Linear designers write these specs for every major surface update. So do the teams at Stripe Vercel Anthropic and Figma. The spec lives in a shared Notion page or Coda doc that the paired engineer references daily and that the manager uses to brief leadership. It contains direct quotes from the five user interviews the designer ran personally. It references the exact dashboard number that will prove success or failure such as activation rate for new users or retention curve for power users. No vague language no open ended feature lists and no decorative mood boards. Just the minimum information needed to align the team defend the work in review and hold the ship date without excuses.

A written spec is not a collection of Figma frames with comments serving as requirements. It is not a 15 page PRD bloated with competitive analysis long term roadmap items or ten different success criteria. It is not a vision deck or slide presentation full of aspirational statements and pretty screenshots. Those tools have their place but they come after the spec is locked. The written spec stays short and brutal. One problem statement. One primary metric. Three to five failure modes. Three to five cut lines. Anything more and you are avoiding the hard choices that define real ownership in the new role. It does not include detailed user flows wireframes or visual explorations. Those belong in the appendix or a follow up deck. The document focuses on product thinking not interface details. Designers who treat the spec as an afterthought or a box to check quickly find their role merged away in the next reorg because they failed to absorb the work that used to sit with a separate PM.

Concrete examples prove how this works in practice. The Linear team used a written spec to launch their improved issue search in late 2025. The document opened with the problem. Engineers lose an average of 17 minutes per sprint hunting for the right issue due to poor filtering. The user was defined as the engineering manager coordinating multiple work streams. Success was tied to a 45 percent reduction in search time tracked through their product analytics. Failure modes included over complicating the query syntax and alienating newer users who prefer simple interfaces. Cut lines ruled out AI powered natural language search in v1 limited saved filters to five per workspace and blocked any changes to mobile. The designer who wrote this had run eight user interviews and quoted two of them directly in the spec. This document set the ship date of March 12 which the team held firm. When scope creep appeared around additional notification features the cut lines provided the language to say no. The Figma file was created after the spec was locked and served as visual validation of the written decisions. The work shipped on time. The metric moved 52 percent. The designer then published the post launch write up that analyzed the results against the original spec and what the team learned for the next iteration.

Stripe followed identical discipline for their 2026 checkout optimization project tied to the pricing page problem. The spec named the problem as cart abandonment at 41 percent during the payment method selection step for mid market merchants. Target user was the small business owner processing their first international payment. The metric was set to bring abandonment under 25 percent measured by conversion lift. Failure modes listed interface overload from too many options and security concerns that could increase distrust and support tickets. The cut lines excluded cryptocurrency payments kept the scope strictly to three new payment methods and blocked any redesign of the cart summary page. The designer defended this spec against engineering pushback by referencing the user research summaries and Sentry traces included in the document. The project hit the ship date and reduced abandonment to 23 percent. That same designer now leads spec reviews for the rest of the product team and owns the metric dashboard that tracks ongoing performance.

Vercel designers applied the format to their 2026 dashboard refresh referenced in the marketing site stack 2026 paper. The written spec targeted improving preview load times visibility with a concrete goal of increasing user confidence scores by 30 points on post deploy surveys. Failure modes focused on information overload creating noise and false positives in status indicators that could erode trust. Cut lines prevented any changes to the core deployment engine and ruled out analytics visualizations beyond three core metrics. The designer ran the research wrote the spec held the ship date and published the launch post that got forwarded to the entire company. Anthropic requires specs in the form of detailed eval rubrics that serve as both spec and test plan. Their product designer for the new comparison view wrote criteria that included specific thresholds for accuracy speed and comprehension. This document replaced traditional specs and ensured every decision tied back to measurable outcomes with the designer on the hook for results. Figma is own config panel updates follow the same discipline. Their designers produce specs for features like the new variables panel that clearly state the problem of managing design tokens across large files set a metric around time saved per week and list cut lines that prevented scope creep into full theming overhauls.

Use the written spec for every project where you own the outcome and the metric. Write one at the start of any new feature work major iteration or surface overhaul that takes longer than one week. It becomes critical when your team has flattened the PM and designer roles into one IC seat and when you need to set expectations with engineering without an intermediary. Deploy it when preparing for a design review that could impact ship dates when joining a new team to demonstrate ownership or when planning your quarterly roadmap contributions. Senior designers at every company still hiring in 2026 use this format religiously for roadmap items user facing surfaces and anything that touches a named number like activation rate conversion lift retention curve or NPS on a target segment. It is the artifact that proves you are not just decorating but driving product results that survive finance scrutiny. Stop jumping into Figma first. The spec comes first or the work stays decoration that gets cut in the next cycle.

Avoid writing a full written spec for trivial updates that take less than two days or for tasks where the problem and metric are already established at the system level like minor tweaks to a design system component. Do not use this format for brand design projects marketing collateral or illustration work where the success criteria come from a different creative brief. Pure visual roles at agencies or in contractor positions rarely need this level of product ownership because the client or PM provides the direction. If your work consists of executing someone elses spec then you are in the role the market is actively pricing out automated or consolidated. The written spec is for designers who want to own the chair the budget line and the ship date.

The written spec is how you stop pretending the merger is coming and start being the designer-PM the market actually pays for.