Decisions Behind a Simple Design
A seemingly straightforward text-and-media component can hide a surprising number of development decisions. When content is unpredictable and users access sites through a growing range of devices, developers often find themselves making design choices that were never specified in a static mockup. This case study walks through the thought process behind building a flexible component, from layout and content length to accessibility and authoring options.
Rethinking Visual Order
The design calls for alternating components, with the image on the left in some and on the right in others. On mobile, the image stacks above the text in every case. CSS Grid or flexbox can handle this visually with flex-direction or the order property, but those techniques only change what is seen — the DOM order remains untouched. For a screenreader user, the content might then appear to jump between left-to-right and right-to-left layouts in a way that feels illogical.
When one column contains only an image, using order is generally acceptable. However, with two columns of text, CSS reordering risks a confusing experience. In such cases there are alternatives:
- Flag the accessibility concern and recommend that visual order on mobile match desktop.
- Use JavaScript to physically reorder elements in the DOM.
Another question is whether to enforce alternation with :nth-child or let the client choose the order by adding a class to each instance. The right answer depends heavily on the project’s requirements and the client’s expected workflow.
Handling Variable Content Lengths
The designed proportion of text to image looks pleasing, but real content rarely matches. Long text forces a choice about how the media column behaves:
- Media stays at the top, with space added below.
- Media is centered vertically.
- Media scales to match the text height, using
object-fit: coverto fill space without distortion — at the cost of cropping.
Cropping worked well for images, where authors could source suitable visuals with minor loss acceptable. Video presents a greater risk, since key content might be clipped. The solution was to add another variation where video maintains its original aspect ratio within a maximum width, rather than stretching to match the column height. This option was extended to images too, giving clients more layout variety and allowing for more visually interesting pages when multiple blocks appear together.
Short Text and Heading Length
Shorter content raises different issues. Should the media height shrink to match a small amount of text, or keep a minimum aspect ratio? If the media stays tall, should the text be aligned to the top or centered?
Headings also need testing at multiple line lengths. A short, snappy heading in the design may wrap awkwardly when translated into languages like German, where words run longer. Font size and line length should be checked, and long words may need hyphenation rules. It’s also worth asking whether authors may omit the heading altogether when needed.
Supporting Content Omission
Genuinely flexible components allow authors to drop fields without breaking the layout. The body text, link, or even the heading may be unnecessary in certain contexts. Testing every combination is essential, as is avoiding empty HTML tags for missing field content, which can cause unexpected layout bugs.
CMS “required” fields can restrict authors, but there may be value in offering the option to omit the image entirely or go without any text content. Adjusting the text width and indentation can keep the component balanced when the image is absent.
Multiple Links and Click Targets
In practice, clients often wanted additional links in this component. That leads to layout decisions: side-by-side or stacked vertically? With stacked links, setting both widths to match the longest label creates a tidy look. Horizontal layouts demand further choices around alignment and spacing. A secondary visual style may be needed to differentiate links of different importance.
For single links, it may be worth asking whether the entire component should be clickable, as is common in card-based designs. The answer depends largely on the surrounding page context.
Video Playback Considerations
Using video instead of an image introduces questions the static design doesn’t answer. Playback control is the main one: does video play on hover, autoplay on scroll, or show visible controls? Hover-only playback excludes devices without hover capability. Autoplay should respect the prefers-reduced-motion setting to avoid triggering discomfort for those with vestibular disorders. All users should also have a clear way to stop playback when they choose.
Context and Page Rhythm
Components are often designed in isolation, but they live on pages with other sections and repeated instances of themselves. Spacing between identical components and across mixed layouts needs attention. These text-and-media blocks are meant to add visual interest sparingly, yet a content author could easily fill an entire page with them, producing a monotonous result.
To prevent that, the build process introduced an option to omit the background color, allowing an alternating pattern across the page. This could be forced with :nth-child or exposed as a CMS field for artistic control. The addition wasn’t in the original design, but open communication between designer and developer led to a more robust set of options.
Rich Text and Element Variety
Body copy fields shouldn’t be limited to a single paragraph. A WYSIWYG or rich text field permits multiple paragraphs, lists, and anchor links, but such flexibility demands testing. Styles must work across every element type an author might insert, and sufficient color contrast needs checking against all background colors available in the component.
Building Flexibility Into Components
What seems like a simple component often hides a web of decisions that only surface during development. The more a design leaves out, the more responsibility falls on the developer to anticipate how that component will behave across real content and real contexts. Asking the right questions early — and testing the edges — turns a basic layout into a resilient piece of UI that serves clients well beyond the initial build.
Question Everything Before You Build
Breaking a component into its constituent parts is the first step. Before writing any code, consider every variation the content team might throw at it. This includes not just different lengths of text and image sizes, but also the absence of certain elements. A heading, body copy, links, or an image might all be optional in practice, even if the mockup shows them present.
Thinking this way also improves estimation: when you know the edge cases upfront, your timelines are far more accurate. The result is a component that adapts without requiring a developer to revisit it for every new page.
Beyond the technical checks, this process depends on good communication within the team. A collaborative culture — where designers, developers, and content strategists talk through usage scenarios — leads to more durable builds. The investment pays off: baking flexibility into both the design and the build process produces sites that avoid brittle fixes later.
A Practical Testing Checklist
Use this list as a starting point for stress-testing a component. It works well for a card-style layout but can be adapted to other patterns.
- Accessibility of the layout on both mobile and desktop.
- Images of different intrinsic aspect ratios — are they cropped appropriately at each size?
- Longer and shorter body text, including multiple paragraphs.
- Longer and shorter headings, including various word lengths.
- Omitting each element in turn: heading, body text, links, and image.
- Multiple links, including different lengths of link text.
- Accessibility of any embedded video content.
- WYSIWYG content in the body — links, lists, and other rich text elements.
- Testing in context: place multiple copies of the component with varied content, and mix in other component types on the same page.
Working through these scenarios systematically helps surface layout breakages early and ensures the component handles real-world content gracefully. In the end, the goal is simpler: build components that don’t need hand-holding once they land on a page.
Further Reading
- An Introduction To CSS Scroll-Driven Animations: Scroll And View Progress Timelines
- Three Approaches To Amplify Your Design Projects
- How To Improve Your Microcopy: UX Writing Tips For Non-UX Writers
