How do you handle a case that breaks the system’s own rules?

Published Read 3 min read

On this page

When a case breaks the system’s own rules, the first move is not to force it in or quietly override it but to ask whether the rule or the case is wrong, then choose deliberately between accommodating it within the system, extending the system if the case is common enough, or making a documented, contained exception. A rule-breaking case is a signal to examine, not just an obstacle to route around. The system should bend on purpose, with a reason recorded, rather than be either rigidly obeyed against good sense or silently violated against its own integrity.

The reasoning rejects a false choice. The instinct is to treat the conflict as binary: either you cram the case into the existing rules even though it does not fit, or you abandon the system for this one screen and move on. Both are failures. Forcing the case in produces something that technically complies and clearly does not work, which teaches everyone that the system is an obstacle. Silently overriding produces an undocumented deviation that the next person finds with no explanation, cannot tell apart from a mistake, and may copy or contradict. The break is information. It is telling you either that this case is genuinely special or that the rule was too narrow, and you cannot know which until you stop and look.

Walking through a concrete case shows the three real options. Suppose a system says every page uses the standard two-column content layout, and a new data-heavy comparison page simply does not work in two columns. First, examine: is the rule wrong, or is this case special? If you discover several upcoming pages will have the same density problem, the rule is too narrow, and the right move is to extend the system with a sanctioned wide-table layout that everyone can now use. If instead this is the only page that will ever need it, you accommodate it within existing primitives if you can, and if you genuinely cannot, you make a documented exception, noting in the system that this page deliberately departs from the standard layout and why. Either way the deviation is intentional and legible, not a silent crack.

Note one exception: judgment about frequency, because the same break can call for different answers depending on how common it is. Extending the system for a case that truly happens once bloats the system with a rule almost no one needs, which is its own kind of harm. Making a one-off exception for a case that actually recurs leaves everyone improvising the same departure independently, which defeats the system. So the question after examining is honestly how often this case will appear: rare and contained means a documented exception, common and recurring means extend the rule, fits-with-effort means accommodate. Getting that frequency call right is the whole craft of handling exceptions well.

It also matters that an exception, once made, stays contained and visible rather than spreading on its own. A documented exception is safe because it is bounded and explained. The danger is when a single exception quietly becomes the new informal default, copied screen by screen until the rule it broke is dead but never officially retired. Containment means the deviation lives in a known place with a known reason, and anyone tempted to reuse it has to confront whether they are facing the same special case or just borrowing a shortcut.

So when a case breaks the rules, treat the break as a signal and respond deliberately. Examine first whether the rule or the case is at fault, then accommodate it within the system if you can, extend the system if the case is common enough to deserve a real rule, or make a documented, contained exception if it is genuinely singular. Whatever you choose, write down what you did and why, so the next person inherits a system that bent for a reason rather than one that was quietly broken.

Related posts:

  1. How do you design the moment right before someone commits? You design the pre-commitment moment by pulling three levers at once: remove the last-second doubt, restate the value the person is about to get, and strip away anything that could......
  2. How do you give feedback on a tap without a full animation? You acknowledge a tap with an instant state change, a press that depresses, a color or shape shift, a subtle haptic pulse or a soft sound, because the user's real......
  3. When does color alone fail to communicate, and what has to back it up? Color alone fails the moment meaning rests on it, so the rule is simple: any state, link, category, or status signaled by color must be reinforced with a second cue,......
  4. When does a grid help a layout vs make it rigid and lifeless? Use a grid when your content shares structure and needs to align across sections; abandon or bend it when the grid starts forcing genuinely different content into the same uniform......
  5. When should an action be undoable instead of guarded by a confirmation? Reach for undo whenever the action can be reversed and you care about keeping the flow fast, and save confirmation for the truly irreversible or dangerous. The deciding question is......
  6. How do you write an error message that helps instead of blames? A helpful error message names what went wrong in plain language and tells the user how to fix it, treating the moment as a recovery instruction rather than an accusation.......
  7. How do you design a destructive button so it’s clear but not scary? You design a destructive button to be clear but not scary by letting its label name the consequence and its styling signal caution proportionately, then pairing it with a recovery......
  8. When should you wireframe vs jump straight to high fidelity? Wireframe when the structure, flow, and priority of the screen are still unsettled and you need to decide them cheaply; jump straight to high fidelity when the pattern is well......
  9. When is a sidebar nav better than a top bar? A sidebar beats a top bar when you have many navigation items, deep sections, or an app-like tool where persistent access to a lot of destinations matters, and a top......
  10. When is no animation the better design choice? No animation is the better choice when speed and directness matter most, when motion would pull focus from a task that needs concentration, or when the user has asked for......
  11. When is auto-playing content an accessibility problem vs fine? Auto-playing content becomes an accessibility problem when it moves, sounds, or changes for more than a moment with no easy way to pause or stop it, and it is fine......
  12. When does naming a component well matter more than designing it well? Naming a component well matters most when many people have to find, reuse, and talk about it, because at that scale the name is the interface to the component and......
  13. How do you redesign a page that’s working without losing what works? You redesign a working page safely by first identifying exactly what drives its success, then changing around those proven elements rather than through them, and validating every change against the......

Leave a comment

Your email address will not be published. Required fields are marked *