01 Overview
Closing a bug as by design is one of the most misunderstood outcomes in a triage queue. It is not a rejection of the reporter's effort, nor a claim that the behavior is good. It is a routing decision: the observed behavior matches the intended specification, so the defect report does not represent a code change. The craft lies in making that determination carefully, documenting it clearly, and ensuring the decision survives scrutiny. A by-design closure is a statement about intent, not about quality.
In practice, by-design closures often arise when the specification is ambiguous, outdated, or silent. The tester sees a mismatch; the engineer sees expected behavior. Triage is where those two views meet. The goal is not to win an argument but to establish a shared understanding of what the system is supposed to do. If the specification is wrong or missing, the correct outcome may be a documentation change or a product decision, not a code fix. That distinction matters for severity, priority, and the report's final status.
This article treats by-design closure as a disciplined triage outcome. It covers how to read the report's claim, separate severity from priority, write reproducible steps, run the queue, handle reopened defects, and answer common questions. The emphasis is on evergreen craft: clear reasoning, traceable evidence, and respectful communication. No specific tools or products are required; the principles apply wherever defects are tracked and reviewed.
02 What the report is actually claiming
Every defect report makes a claim, even when it is phrased as a question or a screenshot. The claim is usually that the system's behavior deviates from an expected standard. To close as by design, you must first identify that standard. Is it a written specification, an acceptance criterion, a design mock, an API contract, a regulatory requirement, or an implicit convention? If the standard cannot be located, the report is not ready for a by-design closure; it is ready for clarification. The tester's job is to surface the mismatch, but the triage team's job is to name the authority that resolves it.
A common trap is treating the current behavior as the specification. That is circular: the system does what it does, so it must be intended. Instead, look for an artifact that predates the report and describes the desired behavior. If the artifact is silent, the behavior may be accidental. If the artifact is contradictory, the report has found a real documentation defect. The distinction between a code defect and a documentation defect is central to by-design triage. Closing as by design without identifying the standard leaves the next reporter to repeat the same investigation.
The report may also claim a user-experience problem rather than a functional deviation. For example, a confirmation dialog may be technically correct but confusing. That is not a by-design closure in the strict sense; it is a product or design decision. Triage should route it accordingly. The key question is always: what did the team intend, and where is that intent recorded? If the answer is nowhere, the defect is not by design; it is under-specified.
03 Severity versus priority
Severity describes how much damage the defect causes when it occurs. Priority describes when the team intends to address it. These are independent axes, and by-design closures often expose the confusion between them. A behavior can be severe in its impact yet intended by design, such as a destructive operation that requires explicit confirmation. Conversely, a trivial cosmetic issue can be high priority if it undermines trust in a visible surface. When triaging a possible by-design closure, assess severity first: if the behavior were a defect, what would it break? Then assess priority: even if intended, does it need attention now?
For a by-design closure, severity should reflect the risk of the intended behavior, not the risk of a failure. If the intended behavior is safe and documented, severity is typically low. If the intended behavior is surprising or dangerous, severity may be high even though no code change is planned. That high severity is a signal to improve documentation, add guardrails, or revisit the design. Priority, meanwhile, may remain low because the team has decided not to change the behavior in the current cycle. Recording both values prevents the false impression that a by-design closure means the issue is unimportant.
Triage teams should resist the urge to inflate severity to force a fix. That tactic erodes trust in the severity scale and makes the queue harder to read. Equally, teams should not deflate priority to avoid discussion. The honest approach is to state the intended behavior, assign severity based on its real-world impact, and set priority according to the team's scheduling constraints. If the behavior is intended but harmful, the correct outcome may be a design change, not a by-design closure. Severity and priority are tools for that conversation, not substitutes for it.
04 Writing steps someone else can follow
Reproduction steps are the backbone of any defect report, and they matter just as much when the likely outcome is a by-design closure. The steps must be short, deterministic, and free of assumptions. Start from a known state: a fresh account, a clean database, a specific build, or a documented configuration. Then list the smallest sequence of actions that reliably triggers the behavior. Include the exact input values, the environment, and the observed result. If the behavior depends on timing, data volume, or permissions, say so explicitly. A by-design closure is only credible if the reviewer can reproduce the behavior and compare it to the specification.
Avoid steps that mix observation with interpretation. Write what you did and what you saw, not what you think it means. For example, "Enter a negative quantity and submit the form; the order total becomes negative" is better than "The system allows invalid orders." The first version gives the triager a concrete behavior to check against the specification. The second invites debate about intent before the facts are established. If the behavior is intermittent, document the conditions under which it appears and the frequency you observed, without inventing statistics. A clear, reproducible case is the foundation for a fair triage decision.
When the behavior is confirmed as intended, the steps become part of the closure rationale. They show that the team understood the report and verified it. They also help future readers who search for the same behavior. If the steps cannot be made reliable, the report should be sent back for more information rather than closed as by design. A closure based on unreproducible steps is a guess, and guesses do not belong in a defect ledger. The discipline of writing precise steps pays off whether the outcome is a fix, a documentation change, or a by-design resolution.
05 Running the triage queue
Triage is a routing activity, not a debate club. The queue should move reports toward a decision: fix, defer, document, or close as by design. To run it well, establish a consistent agenda. First, confirm the report is complete: clear title, affected area, reproduction steps, expected versus actual behavior, and any relevant evidence. Second, identify the authority for expected behavior. Third, decide whether the observed behavior matches that authority. Fourth, record the outcome with a concise rationale and a link to the specification or decision record. This sequence keeps by-design closures from becoming arbitrary.
A useful practice is to separate the roles of advocate and adjudicator. The reporter or tester presents the case; an engineer or product owner checks it against the specification; a triage lead confirms the routing. In small teams, one person may play multiple roles, but the steps should still be visible in the report's history. When the decision is by design, the rationale should name the intended behavior and explain why the report does not require a code change. If the decision is to document, the rationale should identify the gap. If the decision is to fix, the rationale should describe the expected change. Ambiguous closures create rework.
The queue should also track patterns. If multiple reports converge on the same by-design behavior, that is a signal: the behavior may be correct but poorly communicated. The triage team can then route a documentation or design task instead of closing each report individually. This is not about suppressing reports; it is about addressing the root cause of confusion. A healthy triage queue produces decisions that are consistent, traceable, and respectful of the reporter's time. By-design closures are a normal part of that flow, not an exception to be avoided.
06 When a defect comes back
A reopened defect is not a failure of the triage process; it is new information. When a report closed as by design returns, treat it as a fresh claim with a higher bar for evidence. The reporter may have found a specification that contradicts the earlier decision, a new user impact, or a scenario the original steps missed. The triage team should reopen the discussion without defensiveness. The first question is whether the new information changes the authority for expected behavior. If it does, the earlier closure was premature and should be corrected. If it does not, the team should explain the intended behavior more clearly and consider whether documentation is still adequate.
Reopened defects often reveal that the original closure lacked a durable rationale. A one-line comment like "works as intended" is not enough. The record should state what was intended, where that intent is documented, and why the observed behavior is consistent with it. If the reporter disagrees, the disagreement should be captured, not erased. That record helps future triagers and prevents the same cycle from repeating. In some cases, the right outcome is to convert the report into a documentation task or a product decision. In others, the behavior may indeed need to change. The goal is not to defend the original closure but to reach the correct routing.
Persistent reopenings can also indicate a deeper problem: the specification is wrong, the design is confusing, or the team lacks a shared definition of done. Triage should escalate those signals rather than absorbing them indefinitely. A defect that keeps returning is a symptom of an unresolved decision. The team may need to revisit the requirement, update the documentation, or change the behavior. Closing as by design is a valid outcome, but it is not a way to end conversations. It is a way to record a decision that the team can stand behind and revise when the facts change.
07 Frequently asked questions
What if the specification is silent? If no artifact describes the intended behavior, a by-design closure is not justified. The report should be routed for clarification, and the team should create or update the specification. Silence is not intent; it is a gap. The triage outcome should reflect that gap, whether as a documentation task or a product decision.
Can a tester close a bug as by design? Closing is a workflow action, but the decision belongs to the triage team. A tester can recommend a by-design closure with evidence, but an engineer or product owner should confirm that the behavior matches the intended design. The separation of recommendation and decision keeps the process honest and traceable.
How much detail should the closure note contain? Enough for a future reader to understand the decision without asking questions. Name the intended behavior, cite the specification or decision record, and summarize why the report does not require a code change. If the behavior is surprising, note that documentation or design follow-up is needed. A vague closure invites reopenings.
What if the behavior is intended but harmful? Then the defect is not a by-design closure in the strict sense. It is a design or product issue. Triage should route it to the appropriate owner, with severity reflecting the real-world impact. Closing as by design would hide the harm and undermine trust in the queue.
Does a by-design closure affect severity or priority? It can. Severity should reflect the risk of the intended behavior, and priority should reflect the team's scheduling decision. Recording both prevents the false impression that the issue is unimportant. The closure note should make those values explicit so the ledger remains readable.