Imagery & Visual Communication

The full lesson

Images do far more work in an interface than most designers realize. Before a user reads a headline or finds the navigation, the photos, illustrations, and icons on screen have already set a tone, hinted at an audience, and said something about the product. Good imagery speeds up understanding and builds trust. Careless imagery creates friction, breaks promises, or makes everything feel generic — no matter how good the rest of the design is. This lesson covers how to choose and use visual assets intentionally, from editorial photography to empty-state illustrations to icon systems.

Why Imagery Is a Communication System, Not Decoration

Treating images as “decoration” — visual filler to make a screen feel less empty — is one of the most common and costly mistakes in interface design. It produces stock-photo sameness (people laughing at salads, generic team meetings), hero images that contradict the product’s value, and a mismatch between the feeling of an image and the task the user is trying to do.

The better way to think about it: every image in your interface is a signal. It signals:

• Who this product is for — the people shown, their context, their apparent demographics and activities
• What emotional register fits here — calm, urgent, playful, professional
• What level of abstraction the product operates at — photorealistic means concrete and real-world; geometric illustration means abstract and systematic; hand-drawn means approachable and human
• Whether this moment in the user journey deserves visual weight — a confirmation screen may warrant warmth; an error state warrants clarity, not decoration

Once you treat imagery as a communication layer, you can make principled choices instead of just browsing stock sites for something that “fits.”

Photography: Selecting and Directing with Intent

Authenticity over polish

Staged stock photography reads as staged — because it is. Users have developed a strong, almost unconscious sensitivity to stock-photo clichés: uniform lighting, models who are slightly too attractive, settings that are a little too clean. Research on trust consistently shows that photos of real customers, real products, and real use contexts outperform polished studio shots for both credibility and conversion.

Modern best practice separates product photography from editorial photography:

• Product photography should show the product clearly, in context, without styling that hides its actual appearance. Flat lays and white-background shots are functional; lifestyle shots need to be grounded in real use.
• Editorial/people photography should reflect actual user demographics and actual contexts — not aspirational projections. If your product is used by logistics coordinators in warehouses, show warehouses, not open-plan tech offices.

Composition cues for layout

Every photograph has its own visual weight. A hero image with a face looking left creates tension if text is also placed to the left — the face should look toward the content, not away from it. A dark sky or dense background competes with text overlaid on top of it. Fixing that with a semi-transparent overlay is a band-aid over a selection problem.

When choosing photos that need text on top, look for a natural clear zone — an area of low detail and consistent tone where type can sit legibly. Don’t rely on gradient overlays as a design solution. They are a production accommodation, not a design decision.

Accessibility for photographic content

Images that convey meaning need meaningful alt text. Images that are purely decorative should use an empty alt attribute (alt="") so screen readers skip them. Make this distinction deliberately during design: if you cannot write useful alt text for an image, that is a signal the image may not be earning its place.

WCAG 2.2 Success Criterion 1.1.1 requires text alternatives for all non-text content. Common failures include using the filename as alt text, writing vague descriptions (“a person smiling”), or restating the adjacent headline without adding any new information.

Illustration: Style as Brand Signal

Illustration is the most opinionated visual choice in a design system. A flat geometric style signals something completely different from a hand-drawn, textured one — and both signal something different from 3D rendering. The style choice is a brand decision: make it once, document it, and apply it consistently. Mixing illustration styles reads as disorganized, even if each individual illustration is high quality.

Choosing an illustration style

Here is how common illustration styles map to signals and contexts:

The common mistake is choosing a style because it looks good in isolation rather than because it fits the rest of the visual language. A hand-drawn illustration style paired with a sharp, geometric UI creates a split register that users experience as inconsistent — even if they cannot say exactly why.

Color coherence between illustration and UI

A frequent integration failure is using illustration files that have their own internal color palette, unrelated to the design system’s colors. The result: the UI shifts color temperature every time an illustration appears — warm peaches and terracottas in the illustrations sitting against a cool blue-grey UI.

Modern practice is to define illustration color palettes as a subset of the design system’s primitive token tier. Illustration colors come from the same tonal scales as the rest of the UI. This means the illustration palette adapts automatically when the theme changes, including in dark mode.

Icons: Function Before Form

Icons communicate at a glance only when they carry established meaning. “Function before form” means choosing an icon because your target user will immediately recognize it — not because it is elegant, novel, or visually consistent with a theme.

Recognizability vs. consistency

Icon libraries usually optimize for stylistic consistency within the set. That is appropriate, but it should be a secondary criterion. A set where every icon shares the same stroke weight and corner radius but uses obscure metaphors for common functions is worse, from a usability standpoint, than a set with slight visual inconsistency that uses universally understood metaphors.

For common functions — settings, search, notifications, account — use the canonical metaphor users have encountered thousands of times: a gear or sliders for settings, a magnifier for search, a bell for notifications. For domain-specific functions, test icon-label combinations to confirm the icon adds recognition speed, not confusion.

Icon sizing and WCAG 2.2 target size

WCAG 2.2 added Success Criterion 2.5.8 (Target Size, Minimum), requiring interactive targets of at least 24x24 CSS pixels. The AAA standard pushes this to 44x44 pixels. Icons rendered at 16px or 20px must sit inside a touch target that meets this minimum — the visual icon size and the interactive target area are two different things.

A common failure is treating the icon’s rendered size as its touch target. The correct approach is to pad the clickable region so the interactive area is at least 24x24, regardless of the icon’s visual size. In practice, most teams target 44x44 for any icon that appears in mobile contexts.

Empty States: The Underused Communication Opportunity

Empty states — the screens shown when there is no content yet, a search returns nothing, or an error prevents content from loading — are the most neglected imagery opportunity in product design. Most products ship either a blank screen or a generic “No results found” message. Both are missed chances to communicate.

A well-designed empty state has three parts:

1. Explanation — What happened and why the space is empty, not just that it is empty
2. Illustration or icon — Reinforces the emotional register. A first-time empty state should feel inviting and energizing; an error empty state should feel honest but not alarming
3. Recovery action — A clear path forward: a call to action to create the first item, refine the search, or try again

Loading states as a visual communication layer

Loading states are also visual communication. Skeleton screens — grey placeholder shapes that approximate the layout of incoming content — outperform spinners for content-heavy layouts. A spinner says “something is happening.” A skeleton says “content that looks like this is about to appear,” which reduces the visual jump when content loads and anchors the user’s attention in the right place.

Use spinners only for short blocking operations (under one second) or for operations where the result layout is unpredictable. For anything that produces a layout you can anticipate, use a skeleton.

Image Performance and Visual Stability

Imagery creates specific technical challenges that directly affect user experience: layout shift when images load, and slow rendering due to large file sizes.

Cumulative Layout Shift

When a photograph loads after the surrounding text has already rendered, it pushes content down the page — a disorienting jump. This is measured as Cumulative Layout Shift (CLS) in Core Web Vitals. The fix is straightforward: always define explicit width and height attributes on image elements (or use aspect-ratio in CSS) so the browser reserves the right space before the image arrives.

Format and compression

Modern image formats deliver substantially smaller file sizes than JPEG and PNG at the same perceived quality. AVIF is the best option; WebP is a solid fallback. A hero photograph served as AVIF at 80% quality is often 30–50% smaller than the same image as JPEG. For designers, this means specifying delivery format requirements in handoff, not just design-file dimensions — and making sure image export pipelines use modern formats.

Responsive imagery

An image designed for a 1440px desktop layout, served at the same resolution on a 390px phone, is both a performance problem (too many unnecessary pixels downloaded) and a composition problem (the crop may not work at the smaller size). Use responsive image techniques — the HTML srcset and sizes attributes, or CSS art direction with the picture element — to serve appropriately sized and cropped images at each breakpoint. This is a handoff concern as much as a development concern: the designer needs to specify which crop, focal point, or variant to use at each breakpoint.

Building an Imagery System

Ad hoc imagery decisions accumulate into visual incoherence. The solution is to treat imagery as a system layer, documented alongside typography and color.

An imagery system specification covers:

• Photography art direction — Subject matter, emotional register, lighting style, and banned tropes (no fake-diverse stock, no empty-office shots)
• Illustration style guide — Style name, color palette derived from design tokens, usage contexts, file format and size requirements
• Icon library — Source library or custom set, size scale (typically 16/20/24/32px), stroke weight, corner radius, color application rules
• Empty-state inventory — One design per state type (first-use, cleared, no-results, error) with copy guidelines
• Alt text policy — A decision tree for decorative vs. informative images, with guidelines for writing quality alt text for different image types

This documentation lives in the design system alongside component and token documentation — not in a separate brand guide that slowly drifts away from the live product.