Last week, we discussed a few ways design deliverables can be made with the goal of streamlining the front-end development process. This week, we’ll address design complexity and how to simplify things with that same goal.
Assemble page designs as a collection of modular pieces that fit together, and provide notes for any edge cases
By now, it’s fairly common practice for us and the design partners we’ve worked with, but component-based design is still something we strive for. Designing a bunch of reusable, self-contained parts that can be pieced together to form a page in pre-determined regions is the quickest way to build. Alternatively, designing many one-off pages with design aspects that are not re-usable elsewhere can lead to code bloat and process inefficiencies.
Keep region layout possibilities to a minimum, and consider how they will work in a one-column, small-screened mobile device
At the bare minimum, you might want to limit layouts to these basic two:
Alternating “full-width” content (has a maximum width) and “full-bleed” (no maximum width, inner content runs to edges of the screen). This is good for homepages/landing pages, and there can be multiple components of various size in any given region.
A main content region with sidebars, which is good for interior/detail pages.
Exceptions can be made to accommodate the design to keep it from being too boring. Keep in mind that for every variation added though, it may be available to site editors who may not have an eye for design. They might go creating a Frankenstein-like page that you, as the designer, never intended to be cobbled together. For example, like this (the numbers represent varying grid column widths).
Use a semi-transparent background behind text that lies on top of a customizable image to provide contrast
In a design comp, an image can be pre-selected to ensure proper contrast and positioned so that the important part of an image is not obscured. But this never works out in real life. One or more of the following problems crop up:
- The client will have trouble in the future finding images from their library that works as well as the comp
- At different screen sizes, the text overlaps different parts of the image, which either causes problems with contrast or obscures important parts of the image
Keep in mind that high contrast isn’t just for people with vision impairments. If I’m using my phone outside in the sun, or if I don’t have my glasses on, high contrast is a big help. Don’t make contrast a challenge by placing white text on top of images that may make the text hard to see.
For “hero” style images
Text placed over images is usually okay. Use a semi-transparent overlay or other technique to increase contrast. Notice the nearly transparent dark background lying on top of the cityscape – making the image as a whole darker – so that white text on top will visually pop.
For “teaser” style images
Through the use of a gradient, a semi-transparent overlay can partially cover the image just where the text is expected. It is darkest near the text in this example.
Maintain the same aspect ratio for images across breakpoints and screen sizes
Avoid using different aspect ratios of the same image for different screen sizes. It makes Drupal configuration for responsive images overly complicated by having to manage many image styles and breakpoints.
Stick to one approach for designing lists of content
When designing lists of content, (for example, a listing of blog teasers), keep the content styled consistently. Mixing different visual styles that deviate from existing standards adds costs and complexity. When considering how to present a list of content in mobile vs. desktop, use the same approach for both. If you want a carousel/slideshow for a content list when seen in mobile devices, but not for desktop, it’s going to complicate things.
Consult with developers when designing menus and menu behavior
During design, it’s easy to get really ambitious around main menus. Sometimes those great plans are approved by stakeholders. Then eventually passed along for implementation by front-end developers, where reality steps in. The confines of budgets, time, real-world usage or technical possibilities can hand us stark choices on how to change things. Issues can be raised early if we communicate about ambitious menu systems.
It’s worth noting that where possible, build things iteratively by adding on layers of complexity as the project evolves. So start with a basic menu then, if there’s room in the budget, we can make it “sticky.” Or maybe convert it to a “mega menu” (image/text content interspersed with the menu links).
However, be on the same page about this from the start. The client may be disappointed by the final product if they’ve only seen the fanciest version in the comps. Instead, the comps should also show things iteratively. So for the example above, create separate comps for the simple menu, sticky menu, and mega menu.
Communicate throughout the course of the design process
Both the design and development teams all want a finished product that the client loves, and done within budget. Developers would love the chance to help resolve problems early before really tough or disappointing decisions have to be made. Assuming things are cheap or easy to develop can be a recipe for creating sad shareholders.