Skip to main content

Product + Design Collaboration

This document covers how a project moves from design through to planning and how the site team works with both Product and Design during the process. It will cover the design handoff, how projects are broken down into stories, our typical ticket requirements, and our estimation methodology.

Design Handoff​

When approaching a new project or feature, design will iterate within Figma while including Product and Engineering often to discuss feasibility and validate questions. Once designs are solidified, the group meets to review final requirements, and then the project is broken down into tasks and scheduled for the team to begin working.

Design Reviews​

When approaching a new project or feature, Design will review iterations with a small group of Product and Engineering leadership to align on direction and discuss technical feasibility. At this stage designs are still considered open and evolving.

Technical Design Reviews​

Once designs are more solidified, a Technical Design Review will be held. At this time, Product and Engineering will meet to go over designs from both UI and functionality perspectives. The goal here is to have all the design/UX information to 1. create/finalize a product requirements document (PRD) and 2. break down the project into stories for the engineering team.

Product Requirements Document (PRD)​

Product will create a PRD within Linear attached to the project. This document will hold all of the requirements, phases, and decisions made throughout the project thus far. It should help in creating stories, but more detailed technical information will likely be needed.

Story Creation​

After the Technical Design Review, the EM will begin to break down the project and Figma designs into stories/tasks to be scheduled into sprints and completed. At this stage, engineering should have everything they need to complete the project.

Story Creation and Project Breakdown Process​

A reliable way to break projects into frontend stories is to move from customer outcomes, to user flows, to thin vertical slices of UI + behavior. Then each slice becomes a small, testable story with clear acceptance criteria.

Start from outcomes​

Begin with the product goal and the user outcome, not the UI components or routes. Define a handful of high‑level epics such as “Browse catalog,” “Checkout,” or “Manage account,” each tied to a clear user benefit.

For each epic, write 1–3 top‑level user stories in “As a [user], I want [capability], so that [benefit]” form. Keep these top‑level stories business‑focused; avoid implementation details like “add React context” or “build card component.”

Map user flows​

Take each epic and map the main user journey end‑to‑end (e.g., “search → view results → view item → add to cart”). Every distinct step in that journey becomes a candidate story or at least a sub‑area that can hold multiple stories.

For each step, define what “done” looks like from the user’s perspective (what they can see, click, or understand). Capture edge cases (errors, empty states, loading, permissions) alongside the happy path so they can later become their own small stories.

Slice vertically, not by layer​

When turning flows into stories, slice so each story delivers a visible piece of user value, even if it is small or “ugly.” Avoid “UI‑only” and “API‑only” stories whenever possible; instead, combine them into a single story that covers both frontend behavior and necessary integration.

Example: Rather than “Build search results UI” and “Wire search API,” prefer “User can search and see a basic list of results,” where the UI + fetch + basic error handling all ship together.

Use placeholder data only when necessary to get early design feedback, and then follow with a separate story “Replace mock data with live API” if integration is genuinely blocked.

Split big stories with patterns​

Keep tasks technical and small (ideally hours, not days). When a story is too large for a sprint, use a consistent set of splitting strategies.

Common ways to split stories:

  • By workflow step: search, view details, edit, confirm.
  • By data subset: handle one entity type first, then expand.
  • By capability level: MVP (read‑only) first, then create/update/delete, then advanced filters or bulk actions.
  • By state variation: first happy path, then validation errors, then loading/empty/permission states.

Define acceptance criteria and tasks​

For each story, write 3–7 concise acceptance criteria describing observable behavior, data/functionality expectations, and key UX rules.

Ticket Templates​

The site experience team in Linear has built in templates for new tickets that are created. These templates include our typical required and optional fields for all tickets:

  • Description - Detailed overview of the issue or feature
  • Background - Any additional context that would be helpful in working on the task (optional)
  • Acceptance Criteria - Detailed list of requirements to meet for the task to be considered done
  • Technical Specs - Technical guidance, example data payloads, etc (optional)
  • Screenshots - Screenshots or videos of design or issue (optional)
  • Resources - Links to additional documents that may be helpful in working on the task (optional)

At a minimum tickets should have a detailed description and acceptance criteria. Acceptance criteria should cover both UI and functionality when applicable. If follow up with another team/stakeholder or updating an external system is necessary, it must be listed in the acceptance criteria of the ticket.

Estimation Methodology​

Current Iteration​

Currently, Engineering Leadership (typically the EM) points tasks before pulling them into the sprint. The team uses the format that one point equals one day of work. Zero points would mean that the work is less than a day. Using this methodology, the team typically completes 28-30 points a sprint, meaning 9-10 points per engineer. When estimating, it's important to consider the type of technology and the team's familiarity, as well as blockers or dependencies that may creep up during the process. It's better to estimate based on effort/complexity than time needed to complete, although ultimately based on how we currently point, the effort/complexity will need to be transposed to a time-based estimate.

Considerations​

Pointing using a 1:1 point to days approach has its challenges. Anything larger than a day can make progress tracking difficult, but it is also easier to set time based expectations for external teams. Continue to assess if this is the right approach for the team + external stakeholders. It also would be beneficial for the team to join in on the pointing process. Engineers will learn a valuable skill, and estimates will start to become more dialed in as time goes on.

Pointing Tips​

Story points work best when they’re a fast, relative, team-owned way to talk about effort, risk, and complexity, not time in disguise.

Align on what points mean​

Treat points as a proxy for “how hard this is” given complexity, uncertainty, and effort, not as hours. Pick a simple, well-understood story as your baseline (e.g., “1 point”), and size everything else relative to that anchor.

Use a simple, consistent scale​

Use a constrained sequence to force choices and avoid false precision. Keep the meaning of each size stable over time; if a “2” quietly becomes today’s “1,” your velocity data becomes useless.

Estimate as a whole team​

Have the entire eng team participate, using something like planning poker so everyone picks independently, then discuss outliers. Focus the discussion on assumptions, unknowns, and risks; big spreads in estimates are a signal to clarify the story, not to “average the numbers.”

Keep stories small and comparable​

Define a soft upper bound (e.g., anything above 3 points must be split) to keep work slices small and more predictable. Split by workflow step, scenario, or risk (e.g., happy path vs. complex edge cases) so each story can realistically fit in a sprint.

Use history to calibrate, not punish​

Periodically review a few recent stories: “This was a 3, did it feel like a 3?” and adjust your mental model as a team. Use past sprints to understand typical velocity and plan capacity, but avoid tying points to individual performance or rewards.

Emphasize conversation over numbers​

Let points drive shared understanding and forecasting, not debates about whether something is a 3 or a 4. If you’re stuck, pick one and move on. If points stop giving you useful planning signals, be willing to tune the process (or even switch to something like t-shirt sizes) with the team’s input.