Bridging the Gap: Designers Who Code

Coding becomes useful to a designer when it changes a decision. A portfolio gallery makes that tangible: the same image must work as a comparison thumbnail, a complete composition, and something a viewer can inspect closely. One attractive screenshot cannot settle all three jobs.

A concrete portfolio problem

The current Art collection separates browsing from inspection. Its catalogue uses aligned 4:5 image stages, but contains each artwork inside that stage rather than cropping it to fill the frame. Opening a work leads to a viewer with fit, 100%, and 200% options. This example describes the portfolio’s 2026 implementation, not a historical client delivery.

That distinction protects the composition. Green Oracle is 810 × 1280 pixels; Red Moon Profile is 1277 × 1600. Forcing both into an identical crop would treat part of the artwork as expendable. Keeping the outer stages aligned while preserving the inner proportions is a different design decision from making every image edge align.

Size the request as well as the rectangle

CSS controls the rendered stage. The image component also needs to know the source dimensions and the likely display width. These are separate concerns: making an image look small does not by itself describe which rendition the browser should request.

<Image
  src={work.img}
  alt={work.alt}
  width={work.width}
  height={work.height}
  sizes="(max-width: 600px) 90vw,
         (max-width: 1000px) 44vw,
         370px"
/>

Next.js uses the supplied dimensions to infer the image ratio, while CSS determines its rendered size. The sizes hint helps the browser choose among responsive candidates. It should describe the layout, not a hoped-for download size. Image dimensions and responsive sizes are documented by Next.js.

Here the catalogue moves from one column to two and then three. The hints broadly follow those widths. They are not exact container measurements, and device pixel ratio also influences image selection. A layout change therefore deserves a second look at the request hints, not only a screenshot review.

Interaction rules are part of the drawing

Inspection adds decisions a static grid cannot answer. When the viewer closes, where should keyboard focus return? If a different work loads, should the zoom level persist? When the image is enlarged, should arrow keys change artworks or move around the image?

The current viewer resets magnification when changing works. At fit size, its arrow-key handler browses the collection; at actual size, it yields those keys to the scrollable image region. Close and Escape return focus to the opening control. The failure state keeps a retry path without replacing the surrounding viewer.

These rules make the design more specific. “Open the image” becomes a sequence with an entry point, an inspection state, a failure path, and a return. That is the useful contribution of code literacy—not a claim that a designer must take over every engineering responsibility.

Keep the proof proportional to the claim

• Use differently proportioned works, not repeated placeholder rectangles.
• Check narrow and wide layouts against their actual image requests.
• Open the viewer by keyboard, change work and scale, then close it.
• Interrupt an image request and verify the recovery route.
• Open a direct artwork link without first navigating through the gallery.

Those checks establish observable behaviour, not improved hiring conversion or a measured performance uplift. The resulting design is a clearer division of labour: the catalogue supports discovery; the viewer supports inspection. Try that distinction in the complete Art collection and the Green Oracle record.