This letter has been brewing for years. Parts of it have been delivered in speech and in writing to various designers over a long period of time.
However I’ve always dreaded publishing it out of fear that it would implicate the current designer or client I’m working with. So before I proceed I’d like to emphasize that this is not a specific grievance but rather an itemized list of 18 years of disagreements.
We have worked together for almost two decades, and each PSD file you’ve sent me has had (more or less) the same issues. Forgive me then for the indecency of trying to teach you your job.
I do not presume to teach you about graphics or aesthetics. I will not delve into typography, legibility, or use of white-space.
Instead, I’d like to explain how the fruits of your labor inform mine.
I’d like to remind you what is required to reproduce designs as pixel-perfect web pages. I’d like to tell you how your design files will be used for documentation and how the images you create determine the technologies used – down to the very base levels of scalability and performance.
Also, I’d like to demonstrate what can be done quickly and easily and what will generate overhead that will drag the entire production to a crawl.
And most of all, I’d like to remind you that the picture you’re creating right now will be made into a living thing that interacts and responds, that communicates with thousands of different individuals, that needs to teach them, and learn from them in the most effortless way possible. Both for it and for them.
Designing for Documentation
First of all, I’d like to remind you that the PSD files you’re producing are not only the source of the images for the client to approve, they’re also technical documentation and source materials for developers. Therefore, please keep your layers and groups tidy, organized and named .
Dear Designers, for two decades you've been sending me PSDs with the same issues.
Annotate your design. Either create a separate file with the conventions you’ve used, or note them in a separate hidden layer.
Tell me which fonts you’ve used for what. Let me know which colors, spacings, and contexts to use. I need to know.
I also need to know what to extrapolate if no design has been made for a specific feature.
I guess what I’m trying to say is: If at all possible create a brief style guide for the product you’re designing.
For both our sakes, when adding standard text blocks – such as titles – add a rectangle behind them to indicate the spacing around them. That should enable you to consistently place them every time. If this is too much work, at least indicate which example in the document is canon.
I cannot tell you how often I find that titles are placed by eye so they visually fit the single instance in which they’re being placed, but when measured, reveal that each has its own individual spacing.
The same goes for content blocks. If you have a list of different content blocks, please space them out consistently.
I’ll tell you more in the Designing for Content section, but please don’t assume that your titles will always be in one line, and use that information in the file.
I keep running into these titles that have font size 22px and a line height of 92px (obviously copy and pasted from main page title). The settings you choose are relevant even if they don’t visually change the exported file.
Designing for Technology
There are two sides to this: What can be done and what is appropriate for the medium.
While we are fast reaching the point where everything will be technically possible for website development (if nothing else, I can still draw it out pixel-by-pixel using canvas) a lot of those solutions are not production-ready.
The fact that you found an example where someone successfully combined WebGL 3D with CSS blur plus filter masks for a demo page does not mean that you can use that as a full-window parallax panel in a single page application.
And if you really want to walk the bleeding edge, please consult with your developer before submitting the design for approval. Otherwise, it will be hard to get the client to settle for less.
If you really want to test the edges, though, and if you want to try it out for fun, contact me privately. I love creating things like that as much as you do. Just don’t put that stuff into a budgeted production project.
Beyond those things – beyond testing the limits of what can be done, try to be sensitive and sensible with regard to what should be done .
You’re not a graphics artist; You’re more than that, you’re a designer.
You’re not only designing it to look a certain way, you also have to design it to run a certain way, communicate and behave in a certain way.
To go for the cliché familiar to designers everywhere: What good is a gorgeous looking chair if no one can sit on it ?
You must incorporate speed of loading, and speed of execution and ease of use in your design for it to be a design instead a picture.
Try to achieve as much as possible with only HTML and CSS.
Try to achieve as much as possible with only HTML and CSS. Avoid using nice-looking features that are available in Photoshop. Don’t use blending! Don’t use faux bold and faux italic.
Unless you intend the element to be an image, don’t use filters at all – other than the simplest shadows.
Don’t make me calculate or pick the colors because you’ve used blended color fills. Please don’t fake transparent images by using overlay blending; I actually need a transparent image on site.
If we’re using a front-end framework, such asBootstrap, many of these issues will already be solved, so learn how it’s done and how it can be modified. Don’t just go willy-nilly designing something unrelated.
If your design is not in line with what the framework does, than implementing it is not implementing the design. Instead we end up selectively overriding the framework, so it doesn’t mess with our design and then implementing it from scratch. The workload doubles instead of halving.
And finally, don’t use more than three fonts – or font variants – on the site. If you need six different weights, each with its own regular and italic variants, you’re no longer designing for the web.
Designing for Interactivity
This is a huge one. And this letter was originally written exclusively for this topic. You really have to know and understand all the ways users and functionality can interact.
Let’s start with the simplest things: links.
Links do not have solely two states.
In the navigation I receive, you always provide designs for links and an active link (current page).
In other cases you usually provide base and hover states.
If you want to be the least bit user friendly, you should have distinct designs for base, hover and focus states ( visited and active are also nice-to-have for UX). And for navigation, a link and an active link each have all of the above states .
Oh, and don’t you dare change a link layout between states (varying border width, padding, and the like).
Similarly, if it doesn’t look like a button, it doesn’t have a background. Period. Padding an inline text element is a mess, and unpadded text backgrounds will never do.
Since we are going to use this on mobile, make sure that there is enough whitespace between separate interactive elements, and that each hitbox is sufficiently large. I think that a minimum of 42px on each axis is the norm.
Draw an invisible rectangle, or a hidden layer showing hitboxes; make sure they don’t overlap and that user interactions are unambiguous.
Form elements are even worse.
The most common case I see is with the radio buttons and checkboxes. The standard ones are ugly! So, you design your own, and give me a checked and an unchecked state, and consider yourself done.
However, there is an entire multidimensional table of states for a checkbox, and each should be visually indicated to the user.
We have the following states:
Checked or unchecked
Hover or not
Focus or not
Enabled or disabled
Error or not
Each of those can combine with the others.
Disabled prevents some combinations (hover and focus are usually irrelevant when disabled) but not all (checked-disabled-error is a perfectly valid and informative state for a checkbox). So we end up with 16 enabled and four disabled states, giving a total of at least 20 distinct states. For example, the states you usually give me are checked-not-not-enabled-not and unchecked-not-not-enabled-not in that setup.