Design Pitfalls for Implementation

Intro

The purpose of this site is to help guide web designers to steer around common pitfalls and problems, encoutnered when the web developers are tasked with impelmenting them. Often, designs are signed-off by the clients, which, when rubber meets the road and the website is created, complain that the website doesn't match what they were presented in the design phase. These pitfalls often result in unanticipated budget over-runs.

These website projects have limited developer time available. Pitfalls can exhaust this budget, such as:

Component Sprawl

Desining a wide variety of different structures, instead of a smaller set of re-usable structures, cause extra work. These could be in-page widgets, or different types of pages entirely.

A 1000 page-website can take less development time (setting aside content/data entry) than a 5-page site, if the 1000-page site is just the homepage design, and a single subpage design/template that's re-used 999 times, rather than the 5-page site being comprised of 5 entirely different design layouts that each have to be independently developed.

It may not even be pages, but more subtle things like each top navigation dropdown panel having separate construction/functionality, or each hero-banner carousel slide being completely different fundamental design.

Each time the next design element is different than anthing previous to it, the new element requires new development.

Design Gaps

This is unanticipating issues that arise between design examples, such as low and high resolution versions - placing the web developer into a situation where they may need to do ad-hoc graphic design to solve the problems, deviating from the approved design.

The developer could stop an ask for help, but this is frequently slower on the time schedule, and is more time consuming. Timewise, the developer can simply guess, and have a 90+% chance of being correct. It's more efficient than the developer needing to stop, craft a request, wait, have back and forth, get a decision back, craft more responses, etc, potentially hundreds of times. It's underestimated how many decision points and gaps can exist in a design beyond the look-and-feel version phase.

Most of the sections on this site are about conceptual gaps in the design.

Platform-Naive Design

This is not accounting for or leeraging front-end or back-end frameworks, and in the process, often "going against the grain". The designs may miss the fact that the design is to be integrated into a CMS at all, and the implications therein.

As such, it's good to review the intended front/back-end frameworks, such as what end components, or stylesheet properties that already exist. Try to work them into the design, instead of designing in a vacuum. The can help avoid the developer trying to retrofit the design to the framework. For example, review what can be done with just CSS (and make sure they're browser compatible)- there's many interesting tools there, that are often under-utilized because the designer simply isn't aware of them.

This site attempts to provide guidance and examples of these issues.

Word Wrapping

• Avoid using HTML to force newlines where word wrapping doesn't "do it right".
• Maybe ysing fixed-width stepped breakpoints can establish a more predicable context for style calibrations.
• Plan on text wrapping naturally.

Original Presented Design

Different ways of forcing newlines.

All approaches have problems.

Image and Text Dimension Relationship

• Avoid creating width/height relationships between adjacent elements. Further, presenting this to the client can create unrealistic expectaions.
• Plan on the heights or widths not matching.

Original Presented Design

My Site

Lorem ipsum dolor sit amet, consectetur adipiscing elit. In pretium, lacus vitae commodo cursus, orci mi pulvinar sem, et egestas elit dui pellentesque ipsum. Aliquam eget ex ac eros dapibus semper. Morbi laoreet blandit sapien. Pellentesque varius faucibus leo ut ullamcorper. Sed lacinia nunc tempor, dignissim arcu ut, faucibus massa. Praesent enim nunc, pretium in dapibus vitae, tempus sit amet dui. Duis sed urna sapien. Aliquam id ultrices sem, nec fringilla ipsum. Ut non diam tempus, imperdiet ligula non, tincidunt felis.

50%/50% Ratio

Presented Design Width

My Site

Lorem ipsum dolor sit amet, consectetur adipiscing elit. In pretium, lacus vitae commodo cursus, orci mi pulvinar sem, et egestas elit dui pellentesque ipsum. Aliquam eget ex ac eros dapibus semper. Morbi laoreet blandit sapien. Pellentesque varius faucibus leo ut ullamcorper. Sed lacinia nunc tempor, dignissim arcu ut, faucibus massa. Praesent enim nunc, pretium in dapibus vitae, tempus sit amet dui. Duis sed urna sapien. Aliquam id ultrices sem, nec fringilla ipsum. Ut non diam tempus, imperdiet ligula non, tincidunt felis.

Static Left

Presented Design Width

My Site

Lorem ipsum dolor sit amet, consectetur adipiscing elit. In pretium, lacus vitae commodo cursus, orci mi pulvinar sem, et egestas elit dui pellentesque ipsum. Aliquam eget ex ac eros dapibus semper. Morbi laoreet blandit sapien. Pellentesque varius faucibus leo ut ullamcorper. Sed lacinia nunc tempor, dignissim arcu ut, faucibus massa. Praesent enim nunc, pretium in dapibus vitae, tempus sit amet dui. Duis sed urna sapien. Aliquam id ultrices sem, nec fringilla ipsum. Ut non diam tempus, imperdiet ligula non, tincidunt felis.

Image and Text Position Relationship

• Avoid creating relationships between foreground and background elements, particularly with text, which word-wrap unexpectedly.
• Avoid embedding the text inside the image file, as this poses accessibility/responsive issues.
• Create consistency in placement, and content management guidelines, particularly if there'll be ongoing updates, or multiple versions.

Positioning

The dotted white box indicates where the text block is.

Original Presented Design

Static Text Position with Cropping Image

Relative Text Position with Static Cropping Image

Relative Text Position with Covering Cropping Image

Relative Text Position with Containing Cropping Image

Text Embedded in Image

Text may become unreadably small, or comically large.

Circular Constraints

Sometimes a designer creates a situation which is impossible to make responsive - not just difficult, but actually impossible. A simple example of a circular constraint might be:

1. Box A must be on top of Box B.
2. Box B must be on top of Box A.

We can adhere to #1 or #2, but not both at the same time.

• Avoid doing this.
• Provide a "release valve" plan to break the circular constraints when needed (e.g. allow the text to scroll).

Original Presented Design

Suppose the developer were presented with the below. The developer infers rules, behaviors and constraints by looking at it. This is what the developer may understand.

My Site

In pretium, lacus vitae commodo cursus,orci mi pulvinar sem, et egestas elit dui pellentesque ipsum. Aliquam eget ex ac eros dapibus semper. Morbi laoreet blandit sapien. Pellentesque varius faucibus leo ut ullamcorper. Sed lacinia nunc tempor, dignissim arcu ut.

1 2 3 4 5 6 7 8 9 10 11 12

In other words...

1. The text width is proportional to the panel width minus the image width.
2. ... and the panel width minus the image width is proportional to the panel height.
3. ... and the panel height is proportional to the text height.
4. ... and the text height is inversely proportional to the text width.
5. ... and the text width is proportional to the panel width minus the image width.
6. [loop forever]

Attempting to change the size

In effect, only presented exact text, at this presented panel size, can exist, and still meet the constraints. Problems shown aren't a coding issue. It's a how-its-possible-for-things-to-exist-in-physical-reality issue.

Presented Design Width

My Site

In pretium, lacus vitae commodo cursus,orci mi pulvinar sem, et egestas elit dui pellentesque ipsum. Aliquam eget ex ac eros dapibus semper. Morbi laoreet blandit sapien. Pellentesque varius faucibus leo ut ullamcorper. Sed lacinia nunc tempor, dignissim arcu ut.

Consistency Across Content

• Avoid scenarios where the client may add different background behind text.
• Create consistency in placement, and content management guidelines, particularly if there'll be ongoing updates, or multiple versions.

Original Presented Design

High Contrast Example

Background images can change over time, and what works for one, may not work for another, especially at different sizes.

This is an extreme-contrast example, but problems can arise even at lower contrast.

Mid-Contrast Example

Possible Fix

Create a predictable semi-transparent background behind the text.

WCAG2.0 Requirements

WCAG2.0 requires 3:1 contrast for text for large text, and 4.5:1 contrast for regular text. For instance, no part of the text on this background meets contrast requirements. One should measure the brightest background point versus the darkest foreground point.

Complex Backgrounds

Also keep in mind that complex or sharp-edged backgrounds can make reading foreground text more difficult, even if it's passing contrast requirements.

Consistency Across HTML

• Avoid designs that require the HTML to be structured in different physical places depending on resolution.
• Remember - Device agnostic design is one template or theme, not multiple.
• Follow responsive rules for "collapsing" content to fewer columns.

This difficult to describe - but aim for allowing the HTML structure to be identical whether it's high or low resolution. In short, avoid design decisions which force this to happen.

Column collapsing typically follows a nested left-to-right top-to-bottom pattern (which the 12-column grid frameworks use).

Normal Collapse Order

Bad Collapse Order (Confused)

Placing blocks or elements where they wouldn't go under normal circumstances can confuse the order.

Bad Collapse Order (Duplication)

This doesn't just affect the order of content from an accessibility/keyboard-navigation order, but sometimes it requires the developer to code and integrate two different constructions into the HTML and CMS templating.

This results in a larger DOM tree size for the browser to deal, and creates more development time and technical debt for the developer to figure out how to integrate into the CMS.

Maybe this can be done with the CSS "order" property instead of two separate copies, but that results in a confused ordering for those navigating with a keyboard, but visually viewing the screen - making a separate, but properly ordered copy, virtually mandatory.

Proportionality

• Avoid creating dependencies on proportionality for the presentation.
• Create decoupled, independent components.
• Plan for what happens when the screen is largerthan the presented design, not just smaller.

Original Presented Design

Pay attention to how the relative sizes the components seem "right" versus each other in the original presented design.

A "screen view" is added to show what's above-the-fold versus below-the-fold on a typical 16:9 horizontal screen.

Full-Width Scaling (no max-width)

Allow component rows go to the edge of the monitor/screen.

Max-Width Scaling

Allow component rows go scale up to a maximum width.

Mixed Scaling

Some components stretch - some don't.

Uniform Scaling

Everything scales the same amount, including padding, font sizes, border witdths, etc. The biggest issue is that eveything becomes rediculously large on large screens.

Designing on a Grid

Most front-end frameworks use a 12-column grid system.

Front-end frameworks are only useful if the designs deliberately incorporate and adhere to the framework's tenets.

Note: This relates heavily to the quesiton of prime-number column count. Namely, that prime numbered columns (outside of 2) does not evenly fit into a 12-column grid structure.

• Avoid arbitrary sizes of columns.
• Plan using a grid system - likely a 12-column one.

Example 12-Column Design

With Real Content

Similar to other warnings on this page, the amount of content in each panel can make the design awkward. Prepare for this.

Presented Design Width

My Site

Lorem ipsum dolor sit amet, consectetur adipiscing elit. In pretium, lacus vitae commodo cursus,orci mi pulvinar sem, et egestas elit dui pellentesque ipsum. Aliquam eget ex ac eros dapibus semper. Morbi laoreet blandit sapien. Pellentesque varius faucibus leo ut ullamcorper.

In pretium, lacus vitae commodo cursus,orci mi pulvinar sem, et egestas elit dui pellentesque ipsum. Aliquam eget ex ac eros dapibus semper. Morbi laoreet blandit sapien. Pellentesque varius faucibus leo ut ullamcorper. Sed lacinia nunc tempor, dignissim arcu ut, faucibus massa. Praesent enim nunc, pretium in dapibus vitae, tempus sit amet dui. Duis sed urna sapien.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. In pretium, lacus vitae commodo cursus,orci mi pulvinar sem, et egestas elit dui pellentesque ipsum.

Primes and Columns

Note: This relates heavily to the quesiton of using a standard grid. Namely, that prime numbered columns (outside of 2) does not evenly fit into a 12-column grid structure.

• Avoid prime number columns (3, 5, 7, 11, etc)
• Use numbers which have multiple divisors, like 6 (6x1, 3x2, 2x3, 1x6)

Original Presented Design

Wrapping

Because there's no even breakdown, we're left having lopsided presentation.

Potential Fix - Non-primes

A column count of 4 can subdivide more evenly.

Designing around Breakpoints

Most front-end frameworks use a 12-column grid system.

Front-end frameworks are only useful if the designs deliberately incorporate and adhere to the framework's tenets.

Note: This relates heavily to the quesiton of grid systems.

• Avoid design elements or situations that need specific spacing or proportionality to "work".
• Avoid design elements or situations that need custom behavioral styles that change outside of the standard established breakpoints.
• Plan using a grid system - likely a 12-column one.

Example 12-Column Design

With Real Content

Similar to other warnings on this page, the amount of content in each panel can make the design awkward. Prepare for this.

Perfect Content

• Avoid copy/pasting placeholder text, creating perfect balance in the presentation.
• Use varied content, with realistic varying lengths that'd happen in the real world.
• Avoid character limits as a solution. The client inevitably doesn't provide content which adheres to the rules, and most font families are variable-width fonts.
  
  "WWWWWWWWWWWWWWWWWWWW" and "iiiiiiiiiiiiiiiiiiii" are both 20 characters long. This, along with word-wrapping rules, reduces the usefulness of character-limits in creating predictable outcomes.

Original Presented Design

My Site

Example Panel Label Text

In pretium, lacus vitae commodo cursus, orci mi pulvinar sem, et egestas elit dui pellentesque ipsum.

View More

Example Panel Label Text

In pretium, lacus vitae commodo cursus, orci mi pulvinar sem, et egestas elit dui pellentesque ipsum.

View More

Example Panel Label Text

In pretium, lacus vitae commodo cursus, orci mi pulvinar sem, et egestas elit dui pellentesque ipsum.

View More

Example Panel Label Text

In pretium, lacus vitae commodo cursus, orci mi pulvinar sem, et egestas elit dui pellentesque ipsum.

View More

Example Panel Label Text

In pretium, lacus vitae commodo cursus, orci mi pulvinar sem, et egestas elit dui pellentesque ipsum.

View More

Example Panel Label Text

In pretium, lacus vitae commodo cursus, orci mi pulvinar sem, et egestas elit dui pellentesque ipsum.

View More

Realistic Design

Presented Design Width

My Site

Lorem

In pretium, lacus vitae commodo cursus, orci mi pulvinar sem, et egestas elit dui pellentesque ipsum.

View More

Nullam varius, turpis et documentationes, est eros bibendum elit, nec luctus magna felis sollicitudin mauri

In pretium.

View More

Lacus vitae commodo

Excepteur sint occaecat responsabilitas cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. Curabitur pretium tincidunt lacus, nulla gravida orci a odio. Nullam varius, turpis et documentationes, est eros bibendum elit, nec luctus magna felis sollicitudin mauris.

View More

Econsectetur administrationes adipiscing

Excepteur sint occaecat responsabilitas cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

View More

Vestibulum tortor quam, feugiat vitae

In pretium, lacus vitae mi pulvinar sem, et egestas elit dui pellentesque ipsum.

View More

Occaecat

Elit dui.

View More

Having some kind of box/outline can change the dynamics of the presentation.

Presented Design Width

My Site

Lorem

In pretium, lacus vitae commodo cursus, orci mi pulvinar sem, et egestas elit dui pellentesque ipsum.

View More

Nullam varius, turpis et documentationes, est eros bibendum elit, nec luctus magna felis sollicitudin mauri

In pretium.

View More

Lacus vitae commodo

Excepteur sint occaecat responsabilitas cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. Curabitur pretium tincidunt lacus, nulla gravida orci a odio. Nullam varius, turpis et documentationes, est eros bibendum elit, nec luctus magna felis sollicitudin mauris.

View More

Econsectetur administrationes adipiscing

Excepteur sint occaecat responsabilitas cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum

View More

Vestibulum tortor quam, feugiat vitae

In pretium, lacus vitae mi pulvinar sem, et egestas elit dui pellentesque ipsum.

View More

Occaecat

Elit dui.

View More

Sticky Headers

• Avoid sticky excessive headers/footers — especially for small screens. They permanently use up vertical real estate.
• Maybe disengage the stickiness below a certain "comfortable" resolution.
• Avoid large page headers/footers — keep them trim - if sticky.

Original Presented Design

Varying Widths; Regular Scaling

Also: beware of dropdown panels that go offscreen.

Compressable Space

• Avoid filling every blank space with something in the design.
• Plan on having blank space ("crumple zones") available for things to move into, on smaller screens.
• If the implementation goals include CMS-integration, it'd be better to avoid horizontal navbars entirely. Or, to configure the CMS to police this strictly.
  
  Otherwise, this opens up the chances that the client or content manager will add a new navigation entry, see that it "works" for them on their screen, and deploy without bothering to check other resolutions, resulting in breaking the site at lower resolutions.

Original Presented Design

Broken Under Varying Widths

If the design doesn't have a plan or space for smaller/larger widths, the design quickly breaks. What the developer supposed to do if there's no room at lower resolutions?

Design with Compressable space

Other Design Checklist

• Follow the USWDS Design Guidelines. While the framework itself isn't required, they have good advice on different kinds of components or situations, in terms of usability and accessibility.
• Avoid designing for "mobile", "tablet" and "desktop" - switch the mentality and framing to "low", "medium" and "high" resolutions, for example. The former accidentally focuses too much on specific devices, as opposed to how a device reacts.
  
  Desktops can have resolutions in the "tablet"/"phone" ranges, and phones/tablets can have resolutions in the "desktop" range.
• Focus on device-agnostic designs that are based on device capaibilities, not based on whether they're technically phones or not, for example.
• Provide resolutions and pixel density - don't make the developer guess at what resolution they're examining.
• Specify supported range of resolutions - for example, 480px to 4000px wide; factor in pixel density, etc..
• Specify content rules - if a banner/hero row has an important visual element framed in the background image (though this should be avoided), at least provide instructions about how this would be consistently constructed for content managers going forward, so the design will continue to work.

• Conceptualize the design around rules - The design should be able to be fully recreated from verbal description, without a visual design provided. For example, a row of the page could be described as:

  • Full screen width.
  • There's left and right columns at 50%/50% split with a 1rem gap between them.
  • Text is on the left, word-wrapping.
  • An image is on the right, with a square aspect ratio, 100% the width of the parent container.
  • That image is dynamically cropped to stay square - focusing on the center of the image.
  • The sizing of the image content into the image panel uses the "cover" mode.
  • The height of the row is the greater of the left/right column height, with the left/right column concent vertically centered.

  Communicate this to the developer, instead of relying on them to interpret the design, and guess at its behavior.