10 Questions to Critique a Web Design

Web Design workstation showing code

10 Questions to Critique a Web Design

Previously I wrote about the hidden power that resides in the hands of a designer. A design can make a project succeed or fail. But how do you know? Here are 10 questions you can apply to a supplied design, and the answers to them, or even the process of getting those answers, can bring a good design through to being a great design for your project. Remember, a design is just a picture until it is implemented, and it is important that the technical implementation is considered at the design stage.

1) Image Sizes

How many image sizes are there across the site? How many different aspect ratios? Is there any commonality between images? Where can we reuse an image? In Drupal terms, we're asking: Can I use image styles? How many do I need? In which area of the site can I use each image style?

If there seems to be no obvious pattern, it can be worth articulating the benefits of using standardised image styles to the designer, such as performance and improved editor experience.

Remember that with a responsive design, images will usually stretch to fill a space, so image styles will generally set an image to its maximum required width. The single most important thing to consider is aspect ratio. If all the images have the same aspect ratio, then the implementation of a design becomes much, much more straightforward.

2) Content Order

In a responsive site, as screen size diminishes, chunks of content flow around each other and jump below other content to accommodate the smaller screen width. It is important to realise that designs for smaller screens are sometimes supplied without due regard to this flow of content. If you see content order on a mobile design that doesn't match up with that in the desktop design, ask about it. Either it is a mistake that is easy to rectify at the outset of the project, or it will turn into a monster that will eat your budget.

3) Horizontal Alignment

People love horizontal lines. They particularly love columns of content, with line breaks, each of which line up with its neighbour in the next column. Unfortunately, the web, and responsive design in particular does not make such a design easy to implement.

It is bad practice to set absolute heights to elements in responsive design, to allow elements to expand as necessary, but without control of heights, any content change or width change will break the layout. As widths decrease, the height of content in a restricted space increases, which means that either the content will overflow its bounds, the content will be clipped, or the container expands, breaking the nicely arranged horizontal alignment.

There's no easy solution to this, so it is important to bring it to the attention of all concerned early on, lest it become an issue late in the project when deadlines are tight.

Often this issue only comes to light at launch time, when a client is putting real content, and replacing the nice, consistent three lines of dummy text in the design.

Ask how much content should be in the space. Ask whether the lines need to line up. Ask whether you want to rely on brittle Javascript to make heights equal. Ask early.

4) Long Titles

In a typical design, in my experience, titles and teaser text will be short, bordering on terse, lending themselves to smart, ordered layouts, and small containers in which to fit these elements.

When a site is live in the wild, titles can be really, really long. Editors are given content, control over which they may not have. The design has to accommodate this situation. Try swapping out
'Lorem Ipsum Dolor Sit Amet.'
'Many editors struggle to fit their content into the cramped confines of a small title block.'

Then see if the design still works. Ask about maximum title length and the ebb and flow of text on the web.

What happens with a long title on a small screen?

5) Large, Full Screen Background Images

Do you really need it? How big is it in kilobytes? Is it worth the extra page weight? Can the weight of it be reduced by blanking out where the content will live? What happens on small screens? Do they need to download it?

Think of performance, think of the value of that background image, and think of mobile users.

6) Fonts

What fonts are in use? Are they special? Is there a cost associated with them? Do they have all the necessary characters in the font? (e.g. I recently had to use a font that had no ampersand character.) Does the client know about any cost? Are they happy with that? Where are webfonts in use? Are they just for headings? Or are they for body text? Do they work on cheap, low-resolution screens? (If they don't, it's probably a poor choice.) Is the 'Flash Of Unstyled Text' before the webfont loads acceptable? How much does the font add to the page weight? Can you use a subset of the font? Do you need bold, italic and other variations?

7) View Modes

How many different ways is the same content (e.g. a node or a bean) viewed on the site? Where on the site are these places? Each different representation directly corresponds to a View mode. If there are many variations, can these be rationalised? View modes are immensely useful, but there comes a point where YAVM (Yet Another View Mode) becomes painful. Less is more.

Another consideration here is seeing if view modes can be shared across content types. For example, is the listing page for news posts the same as the listing page for events? If so, we can use the same view mode for both? This will cut down on the time needed to style these view modes with CSS.

8) Configuration

Does the client need to configure anything? What does the site editor want to be able to change? Should footer blocks be editable? Or any of the site chrome? Should only the main content area be editable? Should the site editor be able to modify listings? Panel Pages? Forms?

The answers to these questions are relevant because they directly affect how you approach a build.

(Aside: read our article The Drupal Content Editor deserves and easy Life.)

9) Browsers

What browsers need to be supported? Can the design even be properly implemented in older browsers? What does 'graceful degredation', or 'progressive enhancement' look like in practice with this design? Which design elements, e.g. funky CSS3 effects or killer Javascript libraries, won't work in poorer browsers? Is there a fallback? Should there be? Ask about analytics. What are the actual site visitors using?

The older the supported browser, the more it will eat into your budget, and the older you go, the more it will eat.

10) Colours

How many shades (e.g., of grey) are there in the design? Can you tell the difference between them? For lighter shades, can you even see them on a poor screen? You can bet that the design was put together on a high quality, high resolution, bright screen. Does it work on a low budget, 10 year old 15" LCD screen? If colours cannot readily be differentiated on such a device, then they may be surplus to requirements.

Further Reading

Josh Riggs' excellent presentation from Drupalcon LA on creating great design without a huge budget.


Would you like to create something beautiful?

Ask us about it.


Hi, Anthony
Nice to see your new update, as a web designer i agree with you points, we always confused with images and titles, and content order mainly. many times happen we are so irritated with some of clients just because of arrangement, i hope your article help me some where in my job.

Thank you.

Annertech's default 'Annertechie' profile image.

Great article... As a developer myself, I've discussed most of these with designers over the years.

A couple of additions:
Effects that can only be done in an image editor but must be applied to dynamic content, e.g. semi-transparent text with a blend mode such as multiply, overlay etc.

Graphical embellishments that need to be "just so". If you need to have drop shadows, gradient backgrounds and rounded corners, then is it acceptable to use CSS3 rules to achieve this? They might not be exactly the same as the design but could reduce page weight significantly. Is it OK if the degrade gracefully for older browsers?

In point 3 (Horizontal alignment) the one that I always see is a two column grid with an image on one side and a paragraph of text neatly filling up the corresponding vertical space in the other. Of course apart from the fact that editors must constrain their copy to fit the design, another problem is that in a responsive design as those columns get narrower, the image gets smaller while the paragraph gets longer, so the design will look horrible when seen on a tablet for example.

Annertech's default 'Annertechie' profile image.

Good collection, thanks!
A small mistake: the link to the previous article in the first paragraph is broken (the "blog" is duplicated).

(Editor's note: fixed now, thanks for pointing that out to us.

Annertech's default 'Annertechie' profile image.

A real good read and thanks for the same. Now, first of all I am not a web designer, by profession I am Digital Marketing coach who loves designing like anything. We see designing from the user stand point and always think how much a visual presentation insists a user to take a desired action on a page, which ultimately matters for the businesses.
I am not sure why you think height is a big problem for responsive design. We actually do not have to use height if we mention position relative and use proper padding and margin. Things are not that tough in RWD but yes images especially the slides are always a big problem in responsive design.

Soumya Roy

Annertech's default 'Annertechie' profile image.

Add new comment

Restricted HTML

  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <h4> <h5> <h6>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.