To Designers With Love (A Letter From a Front-end Developer)

Dear Designers,

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.

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. 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 as Bootstrap, 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.

Other form elements might not have an checked-unchecked state but can be empty or not empty (showing placeholder text). They can also have a more complex informational state so that error-or-not case can be as complex as neutral-warning-error-success.

Then, on top of that, you should have mandatory or optional indicators along with a clearly defined layout and design for labels, input help, and error text.

And, if you really want to be user friendly, you need pristine-set-dirty states, indicating that the user never provided the data, or the data is already stored, or has been changed but not stored, yet.

What I’m saying is: Designing for interactivity is difficult. And if you want to change what the radio buttons look like, don’t do it glibly with two states.

Just one final point on designing for interactivity: Decide what interaction looks like. Meaning, decide what conventions you’re going to use for interactive elements, and don’t use them on anything else.

No, you’re not allowed to use your primary brand color to indicate links, especially if you’ll use the same solution to accentuate important content!

Designing for Content

The ideal layout of each element filled with lipsum content is good enough for presenting the client with a picture to get an approval on the visual style. But the content design neither begins nor ends there.

Once you have a rough idea of what you want to do with the content layout, remember that you’re working with dynamic content. There are two cases you must check for each piece of content:

• What if there is too much of it?
• What if there is too little of it (or it’s missing entirely)?

Check what happens if the title is ridiculously short or unusually long. What should the content block look like if crucial elements are missing? What if there is no picture?

If there is no content for a page section, do we remove the entire section – title, container and all – or do we keep the section, and display something along the lines of: “No articles yet, check back later?” Even better: “Would you like to be notified when this content arrives? Sign up for our newsletter!”

Make the decisions! Then design those things!

If you’re designing a feed or content loaded from an external or dynamic source, don’t forget to include all the errors and notifications. In fact, design the page notification meta content to show what it looks like globally, then stick with those design conventions to notify the user in case something goes wrong.

Avoid fixed-width buttons, and fixed-height blocks of text. And, if I haven’t said so before, If you think it’s always going to be one line of text, you’re wrong! Now, go check the best way to make it multiline.

Make sure that the same content has the same structure.

If the same title is visible in multiple places, don’t bold one word in one case and another somewhere else!

In fact, try to avoid formatting structures within titles altogether. Similarly, don’t break the text manually in one place, but break it differently in another. In fact, don’t manually break text!

These things might make your design better, but remember that the content will most likely be input through a CMS, and the person inputting it might not see what it looks like until it’s published, or might not even have the tools to manually break, or format the text.

Design with the same restrictions the final content will have – fixed-width text containers and automatic word-wrap. If it looks ugly that way, the design is not good.

Designing for Responsiveness

This has progressed a lot recently. At least in those cases where mobile is actually designed. More and more, we let bootstrap figure it out, and slap Band-Aids on the cracks.

Regardless, there are a few simple principles you must know.

First, the mobile and desktop variants are not separate pages. I know you know this. They are simply reflows of the same page.

Put simply, it is the same as working with left aligned text. The sentence does not change the order of words or letters just because you’ve placed it in a smaller container.

Also, content groups should be shared across all layouts. When you’re adding columns, make sure that the column breaks are consistent.

Also, your conventions should follow the same structure for different versions of the page. Meaning that, if two elements look identical on a desktop, they should be identical on mobile as well.

Oh, and if you want parallax, kindly provide a picture that’s large enough to move around. If you fit, or crop the picture so it looks right on the file you’re showing the client, then i have nothing to move around.

Designing Exceptions

Of course, exceptions are always possible. Moreover, they are necessary for the product to look attractive and effective. However, don’t add them on the first pass box-by-box.

If you find yourself solving the same design problem over and over again this won’t work, especially if you go for a different solution in each instance.

Once you’ve done all of the above, you should get an efficient, stable, and consistent (if somewhat dull) design. Now is the time to spice things up. Looking at a page as a whole, talk to the client to identify the moneyshots – the items that will give them the most bang for their buck.

We’ve been working together for years, and our clients have always been pleased with the end result.

Of course I’ll jump in if you miss a few of these points, and when using a complex design is justified, I’ll go about writing the rendering logic in JavaScript if I need to.

I’ll step in and justify the extra work to the client if necessary. Heck, I’ve been designing forms and interactivity on top of received designs for ages, so this won’t be an issue.

I just hope, that having read this you’ll keep some of these hints in mind next time we work together. I hope they’ll inform your work and provide guidance when you don’t know what to do. I’d like you to understand that our relationship matters to me and that I haven’t written this to hurt you, but to make our relationship better.

With love,

Your front-end developer