Systems Governance
One shared image viewer, two legitimate requirements: a practical example of governing an exception without duplicating the system.
Published Updated
Governance becomes useful at the moment two reasonable requirements disagree. A team needs to know whether to extend a shared pattern, create an exception or decline the change—and who will maintain the result. A committee, a contribution form or a large library cannot answer that on its own.
Start with the decision, not the organisation chart
A small example lives in this portfolio. A long interface artboard needs to open wide enough for someone to read its labels, then scroll through the flow. A packaging mock-up needs to show the entire object before someone zooms into a label. Both need an image viewer, but “fit” means something different in each context.
Making every image fill the available width can push a tall package beyond the first view. Fitting every image into the available height can reduce a long artboard to an unreadable strip. These are competing requirements in the current site, not a reconstructed account of a client meeting.
Scroll sideways or focus the table and use arrow keys →
| Concern | Decision | Reason |
|---|---|---|
| Interface artboard | imageFit="width" | Prioritise readable detail; allow scrolling. |
| Packaging mock-up | imageFit="contain" | Show the complete object before inspection. |
| Both contexts | One shared modal | Keep closing, zoom, retry and focus behaviour consistent. |
Current implementation: CasePrototypeModal owns inspection; PackagingImage requests the contained fit. Width remains the default for existing interface consumers.
Make the boundary of variation visible
The resulting API makes a narrow difference explicit rather than copying the viewer or introducing a general-purpose styling escape hatch. The project supplies the asset, title, description and fit policy. The shared component owns the interaction around it. That boundary allows the packaging experience to improve without silently changing every product case study.
In a larger team, I would ask the requesting designer to explain the task and provide a representative asset, the component maintainer to own compatibility, and a reviewer to check both contexts. These are recommended responsibilities, not a claim about the staffing of this independently maintained site. Every accepted exception still needs an owner.
Review the change against both requirements
A useful contribution record would contain the competing needs, the rejected global change, the bounded API and acceptance checks. Here those checks include the full object at fit, readable artboard detail, 100% and 200% inspection, narrow-screen scrolling and recovery when an image fails. An attractive default screenshot would miss most of that contract.
Keyboard behaviour belongs to the shared contract too: the dialog must provide a way to close, keep its keyboard sequence within the open dialog and restore a sensible focus position when it closes. The WAI modal-dialog pattern describes these expectations. An implementation still needs testing; using a shared component is not itself an accessibility guarantee.
Release the rule with the example
The decision is easier to understand beside real consumers. Open an original board in the mortgage case, then inspect a finished mock-up in Pure Chocolate. The fit labels state the difference while the surrounding controls remain familiar.
This is deliberately a small governance example. It does not demonstrate organisation-wide adoption or a formal enterprise contribution process. It demonstrates the habit those processes need: explain the exception, constrain it, test the affected consumers and leave the next contributor a decision they can understand. Governance should preserve useful consistency without erasing the task that made an exception necessary.