The comp is not the interface

The first version of C62Y looked finished before it worked.

I had a carefully aligned desktop composition for an equipment catalogue: navigation in a left rail, a wide product photograph, specifications arranged in a strict grid, and a comparison table that filled the remaining width. The typography had a deliberate rhythm. The boxes lined up. At the size in which I had designed it, the page made a convincing argument.

Then I put it in a browser.

One product name wrapped. A missing image collapsed the visual balance. Increasing the text size pushed the navigation into the content. A narrow window made the comparison table escape the frame. On a phone, the page was not merely small; its relationships stopped making sense.

My instinct was to protect the composition. I reduced type, tightened gaps, shortened labels, and added fixed heights to recover alignment. Every correction made the screenshot look more like the original and the system more fragile.

The browser was not failing to implement my design. It was revealing that the design described only one arrangement.

What the composition knew

The static file knew the viewport I had chosen. It knew the exact product name in the example, the amount of description text I had pasted, and which image happened to have a convenient aspect ratio. It knew that every font had loaded. It knew that the pointer was a mouse because I had used one to inspect it.

None of those facts belonged to the catalogue’s durable contract.

A real page needed to survive conditions the composition had resolved in advance:

• The viewport could be narrower, wider, or zoomed.
• Text could wrap according to content, font availability, or user settings.
• A product could have no image or a much taller one.
• Navigation could be used with touch, keyboard, or another input method.
• Scripts and styles could load late or not at all.
• A table could contain more products and longer units than the example.
• The connection could make a decorative choice materially expensive.

The composition was useful evidence of hierarchy, tone, and visual relationships. It was not an implementation specification. Treating it as one converted every unknown into a defect.

That distinction now sounds ordinary. In early 2012, it was not ordinary in my own practice. I still thought of web design as producing a page image and frontend work as making the browser resemble it.

I was measuring the wrong differences

My first browser review used overlay screenshots. I compared the rendered page with the design at the chosen desktop size and corrected offsets.

The process found real defects. A heading was too close to its metadata. Table rows lacked enough separation. The primary navigation needed stronger hierarchy. Pixel comparison was not useless.

It was simply answering a narrow question: does this one rendering resemble this one reference?

It could not tell me whether the product title and image remained related when the title wrapped. It could not tell me whether keyboard focus followed a meaningful order. It could not tell me whether the first screen transferred an unnecessarily large photograph. It could not tell me whether a fixed height would cut off translated text.

I began writing review questions in terms of relationships:

• Does the model identity remain the first thing a reader can establish?
• Are decision-making specifications easier to compare than reference details?
• Can the navigation become compact without becoming unavailable?
• Does a product remain identifiable when its photograph is absent?
• Can the comparison task survive even when all columns cannot be visible at once?
• Does the baseline document still make sense before layout and behavior enhance it?

Those questions were less precise in pixels and more precise about the product.

The composition placed elements at coordinates. The browser needed constraints.

Instead of saying that the content column began 248 pixels from the left edge, I could say that navigation needed enough width for its labels, the product content should use the remaining space, and the whole arrangement should stop growing after lines became uncomfortable to read.

Instead of fixing the product image to one height, I could constrain its maximum width, preserve its intrinsic ratio, and let the surrounding content determine the section’s height.

Instead of forcing specification labels into one line, I could give them a readable minimum and allow values to wrap without separating units from numbers.

This changed the shape of the CSS. The early version was full of dimensions inherited from the comp. The next version used normal document flow first, percentages and maximum widths for the page, and media queries only where the content could take advantage of additional space.

The result did not match the composition at every coordinate. It preserved the composition’s important relationships across more conditions.

That was the first time I understood fidelity as something other than visual coincidence.

The missing image test

One of the most useful changes was also one of the least glamorous. I removed a product image.

The page had treated the photograph as both content and layout support. Without it, the heading shifted, the specification block widened awkwardly, and a fixed-height container left a large blank area. More importantly, the product became difficult to identify because the model name had been visually subordinate to the image.

I rewrote the identity block so text carried identity and the image added recognition. The model, manufacturer, category, and availability remained in a coherent group whether the photograph was present or not. A missing-image state explained the absence rather than rendering a broken icon.

The improvement helped even when images loaded normally. A person scanning with images disabled, waiting on a slow connection, or using a nonvisual interface no longer received a page whose meaning arrived last.

The static comp had never asked what an empty image region meant. It had assumed completeness because the example assets were complete.

After that, I started removing or stretching one assumption at a time: no description, very long model name, unknown measurement, six comparison columns, increased text size, no JavaScript. Each test converted an implicit visual dependency into an explicit product choice.

Source order became visible

The desktop layout placed navigation beside content and arranged product details in columns. I had written the HTML in the same order that the visual boxes appeared to me, with some secondary information early because it occupied the upper-left region.

When I removed the CSS, the document read poorly. A reference note interrupted the product identity. Navigation appeared after part of the main content. A related-items block arrived before the specification it was meant to contextualize.

I reorganized the source around reading and task order:

1. Site and catalogue navigation.
2. Product identity.
3. The specifications used to make a choice.
4. Additional reference details.
5. Manuals and related items.

Wider layouts could then arrange those regions without rewriting their meaning. A visual column was a presentation of the document, not the hidden owner of its sequence.

This helped keyboard navigation and narrow screens, but the lesson was broader. Layout should not be the only place where hierarchy exists. If removing CSS destroys the story, the design has probably stored meaning in coordinates that other presentations cannot recover.

Fixed heights were my quickest way to make cards align. They were also a quiet agreement that content would remain the length I had seen.

In C62Y, product names, availability messages, and specification notes broke that agreement immediately. I could hide overflow, truncate text, or keep increasing the height until the current examples fit. All three approaches optimized the catalogue around a content snapshot.

I removed fixed heights from content regions and allowed rows to grow. Alignment became less mathematically clean in some views, so I looked for the actual comparison boundary. Specification values benefited from row alignment. Product descriptions did not need to end on the same baseline.

The change made the layout visually less rigid and structurally more honest. It separated alignment that supported a task from alignment that served the screenshot.

I still used fixed dimensions where the dimension was the contract: a small icon box, a touch-target minimum, a bounded thumbnail crop. The point was not that fixed values were wrong. The point was that every fixed value spent flexibility and needed a reason.

States the comp did not contain

The design showed the catalogue after a successful load with complete data. The browser implementation introduced states that deserved their own design:

• The image was loading or unavailable.
• A comparison value was unknown, not applicable, or not supplied.
• Navigation had enhanced into a disclosure and was open or closed.
• A filter had no matching products.
• A form submission was invalid or waiting.
• The stylesheet had not arrived yet.

My early habit was to implement these states after the main page looked correct. That made them inherit whatever space and language happened to remain.

I started adding state examples beside the ideal page. They were primitive compared with later component laboratories, but they changed review. A product summary was no longer one rectangle. It was a small system with content variation, missing information, focus, and loading behavior.

The empty result was especially useful. The original copy said “No results,” which did not explain whether the catalogue was empty, the filter was too narrow, or the request had failed. Naming the cause and recovery turned an edge case into part of the task.

A comp can include these states, of course. The mistake was assuming that one polished comp represented the interface rather than one state of it.

The browser was an active participant

I had treated browser variation as noise between design and implementation. Responsive work made it clear that the browser contributed valuable behavior: document flow, intrinsic sizing, link semantics, form controls, focus order, text selection, zoom, and fallback rendering.

The more I forced the page into fixed coordinates, the more of that behavior I had to recreate.

Letting a heading wrap was not surrender. It was the browser adapting language to available measure. Keeping navigation as ordinary links before enhancement was not unfinished design. It was a dependable interaction model that a compact presentation could build upon.

This did not mean accepting every default. It meant understanding which platform behavior already upheld the product and changing it deliberately.

The shift reduced code. The earliest layout used script to equalize heights and calculate dimensions after load. Normal flow and CSS constraints removed the need. The page became more capable by doing less.

What I documented after the failure

I replaced the single annotated comp with a small set of design artifacts:

• A content hierarchy naming identity, decision, and reference information.
• Layout sketches at narrow, intermediate, and wide measures.
• A behavior note for navigation and comparison overflow.
• State examples for missing data, loading, and empty results.
• An asset budget for the first view.
• A test checklist organized by task and capability.

None was as visually impressive as the original composition. Together they described the interface more faithfully.

The wide composition remained useful as one expression of the system’s tone. It no longer carried the impossible responsibility of specifying every condition through one picture.

I also began noting the reason behind a constraint. A maximum line length existed for reading. A breakpoint existed because the identity and decision groups could share a row. A table scrolled because preserving two-dimensional comparison mattered more than eliminating local horizontal movement.

Reason survived change better than coordinates. When content or browser support changed, I could revisit the rule without reconstructing why it had been there.

Review moved into the spaces between the comps

I still captured a narrow and a wide reference, but the most revealing review happened while dragging the viewport slowly between them. Components rarely failed exactly at the width chosen for a mockup. They failed where a label had just wrapped, where two columns technically still fit but had stopped being comfortable, or where an image consumed space without adding useful detail.

I made an intermediate-width pass part of every layout review. The goal was not to approve every pixel value independently. It was to watch how the rules transitioned.

One version of the product summary jumped abruptly from one column to two. Just below the breakpoint, the text had enough width to feel loose. Just above it, the image and specifications became cramped. The breakpoint existed because a device category had suggested it, not because the content benefited.

Moving the transition later improved both sides. The narrow mode remained comfortable over a wider range, and the two-column mode began only when it could express a real relationship. The design gained fewer states and a more defensible one.

I also tested widths larger than the desktop comp. Without a maximum measure, text lines grew long and the relationship between image and specifications dissolved into empty space. Responsive did not mean stretching forever. It meant allowing the content to establish both minimum and maximum useful conditions.

The intermediate pass made animation of the viewport a diagnostic tool rather than a design. Nobody needed to resize the page continuously in ordinary use. Watching it happen exposed where a component depended on a hidden threshold or changed its meaning during transition.

Later I would automate viewport sets and visual fixtures, but the underlying question stayed manual and semantic: does this rule remain understandable before, during, and after it changes presentation?

Before C62Y, I thought design happened first and implementation translated it. The responsive work made the relationship iterative.

Content modeling exposed which relationships mattered. Browser implementation exposed variation the static artifact had hidden. Performance testing changed image and font choices. Keyboard testing changed navigation. Those findings returned to the visual design.

The code was not a lower-fidelity output of the design. It was one of the materials through which the design became knowable.

That changed how I approached polish. I still cared about rhythm, typography, alignment, and detail. I stopped polishing one condition at the expense of the rules connecting them.

A slightly awkward intermediate width was not solved by another hard-coded exception until I understood which relationship was failing. A long title was not “bad content” because it disrupted a card. It was evidence that the component contract had been too narrow.

The process became slower at the beginning and faster after the third exception I no longer needed.

The lesson was not to abandon compositions. A strong static arrangement can express hierarchy and intent quickly. It gives people something concrete to discuss. It helps explore visual language without waiting for a complete system.

I kept three things from the original:

• The contrast between quiet reference material and prominent decision information.
• The dense, tool-like tone appropriate to an equipment catalogue.
• The idea that comparison should feel spatially stable rather than like a sequence of separate product pages.

I released the coordinates, fixed heights, and assumption of a permanent left rail. Those were implementations of the intent under one condition, not the intent itself.

The distinction made critique more useful. Instead of asking whether the browser matched the comp, I could ask whether both expressed the same priorities.

The first durable change in my craft

C62Y did not make me stop drawing pages. It made me stop confusing a page drawing with the interface.

The interface was the set of relationships and behaviors that remained when width, content, input, network, and state changed. The browser rendering at one moment was evidence of those rules, not the rules themselves.

That idea became the starting point for the work that followed: visible state could not be trusted unless the rules behind it survived changing content, capability, time, and failure.

The domains grew more complicated, but the original correction stayed recognizable: never let the most convincing presentation become the only model of what the system is.