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.

Designers have to properly document all assets.

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.

Designing for technology.

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 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.

Designing for interactivity

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.

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.

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.

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

About the author

Vedran Aberle Tokić, Croatia
member since June 9, 2015
Vedran is a JavaScript based front-end developer with a broad experience in many areas that always end up going back to what he loves doing most: problem solving user interfaces. He's addicted to hearing the reaction, "It can do that!?" [click to continue...]
Hiring? Meet the Top 10 Freelance Front-End Developers for Hire in December 2016


Shawn Hoglund
I think you've had the misfortune of working with some very out of touch designers or transitional designers who have had little crossover and dialog with developers. The use of Photoshop in itself would be a red flag for me in the current design world. I agree with many of your grievances but I'd also point out that many of those problems don't just affect you, they affect other designers that have to work with poorly structured files. If you have to use Photoshop there are many tools such as layer labels (use them people), layer comps and layer comp selections within smart objects, pixel grid and layout grid. Control and use of just a few of those tools will help ensure consistency in alignment, placement and interactive object states if used properly. Most importantly having designers get some code time and learn a bit of css/HTML will go a long way to informing design choices and appreciation for what can and cannot be done. Best of luck!
Vedran Aberle Tokić
Good point, though even from latest experience i'd say 90% is still vanilla Photoshop. And a lot of graphical designers switching over to web design. Hence the article. Hopefully it helps. Whats your standard setup lately?
Sketch, mostly.
Shawn Hoglund
Very much in Sketch as well. I suppose its regional too. Most of my work is in New York and I'd say right now with agencies its probably 70/30 Sketch/Photoshop but definitely flip flopped when talking about client side workflow. I think Adobe is making some cool innovations with cloud based libraries and more web-centric tools for photoshop but it may be a little late since many of the add-ons are merely steps to keep up with Sketch. I think you made a very good point about Photoshop maybe having too many options that don't apply to web design (they're terrible 3D tools are a perfect example)
Neil Pearce
Very good post. However I live and work in a world where designers know how to code. Over the last seven years I've worked for several small web agencies, who only have 3-6 employees. We always had one guy doing all the backend stuff (PHP) and the one sales guy. But the rest of us had to see through the whole project cycle, from design mock-ups to front-end development. I prefer it this way, as i enjoy making my designs come to life. Taking that away from me is like telling Dr Frankenstein he can't pull the lever and see his creation come to life lol. (not sure if that's a good analogy or not??) I don't see the problem with using Photoshop. It's only a tool after all, a tool that "web designers" have been using since the beginning. Fireworks and Sketch are just tools too, and they do the job well. But the problem is not the tool but the skill-set of designers. All large agencies seem to put people into teams/groups. I think that's a complete waste when HTML and CSS are some of the easiest things to learn! So i completely agree with Shawn, every designer should know at least HTML/CSS. Thanks, Neil
Shawn Hoglund
Good points Neil, I totally agree with your view on large agencies. The sad part about that is those teams tend to rob designers especially younger/junior designers from the opportunity to truly build their own experiences and learn from their labor.
I've worked on both sides of this "aisle", and had many times when Creative Directors would roll their eyes as I designed worrying about "how will this be built". In their eyes, they believe I'm not "pushing the limits" or "thinking outside of the box", but in my eyes I'm trying to make something feasible and within budget. I honestly grow tired of management who only know print and TV seemingly trying to dismiss the notion that I study code and how to build websites and such. A lot of these companies who say "we know digital" need to start putting staff in place that actually know digital.
Goran Ramljak
From designers perspective, I strongly believe no matter which tool designer uses he needs to have the process. From the very beginning to the folder/layer structure and naming convention. If there is no "pattern" or system, at some point the design won't simply work because that case wasn't covered back in the days when a designer actually designed that. Business has processed, development has its own process (pattern or system how they develop stuff) so the designers should have and be able to produce meaningful process and rules for the websites. This is especially important if you need to cooperate between teams and with more than one person.
Sasha Pavlovic
Great article! Someone had to say it :)
Patryk Pawłowski
Great article! Working as a both designer and front-end dev, I see those problems even magnified. Most of the designes I get from my clients for front-end jobs are totally lacking any consistency and afterwards I need to restyle each heading or paragraph within different (yet similar) sections... Thanks for writing this, I'll be sending it all over to my client-designers ;)
Justin Avery
I'd suggest send the designers you work with over to and check out the book about RWD designing by Dan Rose. The good news is it has been a while since I worked with designers that aren't going the extra mile to make the whole process more collaborative.
Vedran Aberle Tokić
In those situations, the question is "are you sure you're focusing our efforts on the thing that'll bring most value to the project". Sure, there are cases where bleeding edge is justified, but if the budget (in time and resources) isn't there to cover the costs, we'll essentially be making a lot of pretty pictures for a s****y end result. The issue with "pushing the limits" is not the zeal of the designers or the developers. Heck, I'm sure we all adore the stuff and can't get enough of it. It's the strange idea that arises from asking "can we build this bran new, never-before-seen thing on the limits of technology" and following it up with "OK, how many hours will it take?". In the past few years I've simply started asking if the client is willing to pay for the research, and if they're prepared to come to terms with the possibility that the result of the research might be "this is not feasible". If so, I'm happy to spend any and all hours paid on pushing the limit. As I've said, I love doing stuff like that. That's the best part of the job for me, and I'll surely put my private time into it as well. But that's a completely separate job to either development or design (and this might spawn a separate article in itself).
Vedran Aberle Tokić
There was a lot of discussion whether or not designers need to know how to code lately. And I almost can't believe that this is even a question. It's like saying that an architect doesn't need to know about building materials or plumbing. You don't need to be a professional coder, you don't need to be a developer on top of being a designer. But if you don't know the materials you're designing with than you're not a designer.
Danijel Bošnjak
I consider my self more of a designer these days, but i think these are some excellent points. Back in '2001 and up until '2006/07, i was doing everything by myself. Both the PSD and after that HTML/CSS etc.. I would let myself go but later found myself going back to Photoshop to change things up a bit and not cause myself any further headaches :) I learned quickly to control myself and avoid the crazy layout schemes and shapes impossible to code, let alone render consistently across browsers. The screen is not a static piece of paper.
Vedran Aberle Tokić
"The screen is not a static piece of paper." This is something that I'm sure every designer knows and understands. But it's really hard to keep this in mind when actually designing something. And I find that when I do dabble in design a very easily slip to the dark side and start approaching things with an attitude: "I know HTML doesn't work like this but wouldn't it be awesome if I did it this way?" That way lies madness, especially on production projects.
Thomas Calhoun
Vedran, My feedback: Good ideas, informative and well articulated, but not very kindly communicated. This article is condescending toward designers, and because of that, not as effective. I'm sorry that it's been a frustrating experience for you; I think a set of standards or a style-sheet template/checklist —developed in tandem with a trusted designer — would not take that much time to create, and could be the best tool to further your goal of better collaboration. Communication (listening and speaking/acting kindly) is always the best way my wife has taught me! The handoff and collaboration between design and development is something we are all constantly working on (including the guys making the software we use (eg: Craft Sync for Sketch)...ever evolving. Thanks for all of your knowledge and thoughts! Take care, Thomas
Vedran Aberle Tokić
Hi Thomas, I understand your concern, and trust me I've been battling with that issue a lot while writing and later during the editorial process. In the end I chose to be human and personal about it. I agree that a concise, technical spreadsheet of points and a comprehensive template are the best tool once someone is determined to follow such guidelines. And while I may at some point try to create one, previous attempts have turned into attempting to create a comprehensive cheatsheet overlapping the entirety of contemporary web-design and web-development. An impossible task. If you seem to think that it would not take much time I invite you to try it. Should you succeed we'll all benefit greatly. Besides, such a thing already exists The W3C recommendation documents for HTML and CSS. Another point: The experience of working with designers is not frustrating to me, on the contrary, it is rather joyous. Especially when working with inexperienced, wide-eyed people who haven yet grown cynical, despite that causing most of of the errors described. In this article I just wanted to list those issues that I personally frequently run into. And I wanted to do it in a way that would portrait both designers and developers as humans. I know it's stylized, and tacky and controversial, but I think it's a more palatable read on the whole for it. This is an article, not documentation. It's intended to start a conversation not solve the issue on its own. Get me?
I agree. I wouldn't study code and focus efforts if I didn't think it would bring value. It's why my focus has been on front end. I'm not someone who will "color within the lines", but more to fight for "why can't you customize this?" and show how I'd do it to a developer who is clearly trying to duck out of the work. Now if it's blowing the budget, then I'll back off. I also agree pushing envelopes is wonderful if it serves a real purpose and value to the project. Unfortunately, I've seen many times when one wants limits pushed, but merely for the hope of a Lion, Awwward, or FWA. I can understand the prestige, but if I'm asking "how does this help the client?" then there's an issue. Beyond that, I think it's fun to push envelopes on free time, and create concepts that could later be applied and solid to clients if the need arose.
Michelle Wong
I think communication helps too in building a strong team of designers and developers. I am lucky that in my current job, I work with a great team of developers and I am not a expert in coding but I understand them, communicate with the team and ask questions. It also helps when involving designers and developers in the process and not just focus on design first then give the product to devs. #teamwork :]
Iva Stastny Brosig
Dear Vedran, thank you for this article. As a designer, I find it "tough love", but very useful to hear and enhance issues that other side of team has with our designs. As designer, I'd like to add that most of the time we are in position to communicate with "hard" client and it is hard to say "no" all the time. We are also asked to "draw pink line with blue pen". As we all always stream to move boundaries, and in this process we often lose a structure of our layout. My main problem in communicating with programmers is lack of flexibility in communication and considering design part of work as "some colors here and there". We are often treated as part of team that makes production harder, than to see that all of us are here to serve a client and give best service we can in reasonable time and budget. I know we seam to you unorganized, strange, messy, silly... but this is who we are, and it is just as it should be. Of course, my experience is: if I'm sending something to print - I will ask printing office if my design is possible before I present it to client. Same thing with all other media and production. Just less tensions - more communication - more flexibility - and more fun! Kind regards, Iva
Vedran Aberle Tokić
Hi Iva, Great to hear feedback from a designer, and thanks for an open mind. A lot of the issues I talked about ultimately simmer down from the client. There were numerous situations in physical meetings where the client would be presented a first draft design to a client and the client would just glance at it and say "this is OK" and hand it of to the development team for production. And both teams would just facepalm and then gently try to explain what a "first draft" is and how much work the designer still has before we get to actually develop it. I guess another point of view (possibly for some future article) could be: we need to band together as professionals and work together to convince the clients that we know what we're doing and why it needs to be done if they want a good product, and that insisting on skipping steps and not following the recommendations will inevitably result in a poor one.
Vedran Aberle Tokić
Another thing though. From my understanding, "colors here and there" is a graphics artist (not to demean them in any way, I cannot do what they do despite my aspirations and decades of trying, my sense of aesthetics is just not as articulated). A designer (in any field) is much more and is (in many ways) a superior position in the hierarchy both to the frontend developer and the graphics artist. A designer has to be able to encompass aesthetics, content presentation, functionality and gets to make real decisions on how to create an experience (hence the UI/UX specialties). A developer is in some ways just a tech who implements (and sometimes gets to comment on) the design. It is true that we sometimes view you as wide-eyed sensitive artists (as you said: "...messy, silly...") and relish in bitching about the minutia (this article is a prime example). But on the other hand I am very often blown by the fact that a semi-experienced designer can take a concept I've been laboring for weeks on and make it look stunning and instinctive in hours. And finally, while the tone of the article is (tongue-in-cheek) tough my actual experience is that a lot of designers get very interested when you give them information of the kind this article hopefully gives.. I never thought to imply that those issues are due to anyone not caring. I just thought it'd be a fun way to dispense all of it at once.
Funny you Vedran, your reply was indeed another letter. LOL.
Vedran Aberle Tokić
They say brevity is a virtue. Sadly it is a virtue I do not posses. Though, I do admire those that can be both clear and concise at the same time. But it would be a shame to miss out on the discussion just for lack of such virtue.
Anton VS
Great article, thanks.
Michael Craig
Sketch + Craft + InVision Inspect = Developer Rejoice!
comments powered by Disqus
The #1 Blog for Engineers
Get the latest content first.
No spam. Just great engineering and design posts.
The #1 Blog for Engineers
Get the latest content first.
Thank you for subscribing!
You can edit your subscription preferences here.
Trending articles
Relevant technologies
About the author
Vedran Aberle Tokić
JavaScript Developer
Vedran is a JavaScript based front-end developer with a broad experience in many areas that always end up going back to what he loves doing most: problem solving user interfaces. He's addicted to hearing the reaction, "It can do that!?"