skip to content

A design system team has 120 open requests from product teams, including an urgent seat-map component for an airline booking flow; how would you triage and prioritise them?

level: seniorimportance: should knowfreq 26%

answer

  1. sort by type before priority
  2. questions, bugs, requests differ
  3. severity, reach, fit, effort
  4. one product's need versus many
  5. say no with a reason, visibly

basics

~20 s

Sort requests by type first: answer questions and move them to the FAQ, rank bugs by severity with accessibility and blocking defects first, and judge feature requests by reach across teams, roadmap fit and effort. Close duplicates and decline visibly, with reasons.

solid answer

~50 s

I'd start by sorting the queue by **type**, because questions, bugs and feature requests are handled differently. Questions get answered and turned into FAQ entries, which can clear a large share of the queue. **Bugs** are ranked by severity: anything blocking users or failing accessibility first, then visual defects, and duplicates are merged. **Feature requests** are judged on **reach**, how many teams and products need it, on **fit** with the system's roadmap, and on **effort**. The seat map is urgent for one team but specific to one product, so I'd tell them promptly that it will not be a system component now, and help them build it locally from system tokens and parts, noting it for review if other products need one. Every request gets a response time target and a visible decision with a reason, including 'not now'.

go deeper

for a junior

Recall that a system team's requests come in different types, such as questions, bugs and feature requests, and that each is handled differently.

for a middle

Explain the triage criteria for bugs and requests, severity, reach, roadmap fit and effort, and why arrival order is a poor ranking.

for a senior

Show how you would clear a large queue in practice and answer a one-product request honestly and quickly, with concrete help instead of a vague maybe.

for a principal

Weigh how much capacity goes to requests versus the roadmap, and how to keep escalations from overriding the triage criteria everyone else follows.

## What a request queue is for A **design system** team receives requests from the product teams it serves: questions, bug reports, requests for new variants or components, and proposals. A single **request intake**, one form or queue that every request passes through, lets the team see demand as a whole instead of whatever was loudest this week. **Triage** is the regular pass that classifies each incoming item, decides what happens next, and tells the requester. A queue of 120 items usually means intake works but triage has lapsed. The fix is not to work faster through the list in arrival order; it is to sort it so the few items that matter most are handled first and the rest are answered honestly. ## Sort by type first | Type | What to do | Typical outcome | |---|---|---| | **Question** | Answer it, then add an FAQ entry or a doc fix | Closed quickly; often a large share of the queue | | **Bug** | Reproduce, rate severity, merge duplicates | Fixed in order of severity | | **Enhancement** | Check reach and roadmap fit | Scheduled, declined or deferred | | **New component** | Check whether several products need it | Built by the system, built by the product team, or declined | | **Duplicate** | Link to the existing item | Closed, with the requester added | Sorting alone often shrinks the visible queue considerably, because questions and duplicates close quickly. ## Criteria for what remains - **Severity**, for bugs: a defect that blocks users from completing a task, or an accessibility failure, outranks a cosmetic one. - **Reach**: how many teams, products and platforms are affected or would use the change. A need shared by four products beats one product's need. - **Roadmap fit**: whether the request moves the system toward its planned direction or pulls it sideways. - **Effort and risk**: small, safe changes with wide reach are the best value. - **Workaround**: whether the requester can proceed without the change, which lowers urgency without lowering importance. Urgency for one team is real information but not the ranking itself; a team's launch date matters mostly for how quickly they get an answer, not for whether the system builds their component. ## The seat-map request In the scenario, the team building seat selection for an airline booking flow needs a seat map before a launch. Triage asks: 1. **How many products need it?** A seat map is specific to this booking flow; no other team has asked. 2. **Can the system help without owning it?** Yes: the map can be composed from existing system parts, such as tokens, buttons, legends and tooltips. 3. **What is the fastest honest answer?** Tell the team within the response target that the system will not build it now, offer an office-hours session to review their local build, and log the need so a second request from another product triggers reconsideration. The team gets a clear answer before its deadline instead of waiting in a queue for a 'maybe'. ## Running triage as a habit 1. **A triage owner** on a rota reviews new items on a fixed schedule, for example every working day. 2. **A first-response target**, such as two working days, is published so requesters know when to expect an answer; the number is a team convention, not a standard. 3. **Labels** record type, component, platform, severity and requesting team, so patterns are visible later. 4. **Decisions are public**, with a reason: scheduled, declined, deferred with a trigger, or redirected. 5. **Stale items are closed** after an agreed period with a note, rather than left open forever. ## Failure modes - **Arrival order**: working the list first-in, first-out lets a trivial early request outrank a blocking bug. - **Loudest voice wins**: whoever escalates to a manager jumps the queue, which teaches every team to escalate. - **Silent 'no'**: requests left open for months are worse than a declined request, because teams wait instead of building. - **Saying yes to everything**: the system fills with single-use components that cost maintenance and dilute its guidance.

  • The seat-map team escalates to their director after hearing no. How do you respond?
    Restate the decision and its reason calmly: one product's need, buildable from system parts, reconsidered if another product asks. Offer concrete help, such as a review of their local build and guidance on composing it from system tokens. If leadership still wants the system to build it, that is a priority trade-off to make explicitly against other queued work, not a quiet queue jump.
  • Why publish a first-response time target for the request queue?
    It sets expectations, so requesters know when to follow up instead of chasing individuals, and it gives the triage owner a clear standard. The target is for a first, meaningful response, not a fix; a fast honest answer, even 'not now', lets a team plan around the decision.

saying these in an interview costs you the question

  • Requests should be worked through in the order they arrived.
  • An urgent deadline for one team means the system should build its component.
  • Leaving a request open is kinder than declining it.
  • Every request a product team makes should become a system component.
  • The team that escalates hardest should be served first.