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 January 2017


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!
Martynas Martulis
A sad developer, expressing his hatred towards designers... Maybe I should write the same thing about frontenders? Like, you give them 20px padding, they do 12px and say "that's fine, I am too lazy to change default value in bootstrap", or javascripted a simple slide-in which lags on iphone 6? Stop hating, start participating. We need to be f**** professional, guys. Frontender should work with designer, and vice-versa. Frontender should be design-oriented and love design, as well as designer should like to deliver their documents clean and informative. And stop with your stupid sketch - photoshop debate for once and for all. It's not about the tool, it's about the content.
Vedran Aberle Tokić
"... hatred towards designers"? Where did you get that from? And, YES if you think you can, you most definitely should write your pet grievances with developers misimplementing your designs. That is not hating, far from it, that is participating: openly sharing information and opinion, guidance and perspective in a public forum where it is accessible to everyone. It is sincerely out of love for the art we both participate in that I have written this. And I agree completely: "it's not about the tool it's about the content". The tool should be irrelevant to anyone except the person using it, as long as the right content is carried across. It becomes relevant when it becomes a crutch, though. Making it easy to design things that are hard to implement, or hiding information. Anyway, thanks for the comment. (I really can't believe you see it as hatred towards designers)
Spiffy Solar
Graphical is not a word. The proper adjective is "graphic." Pure and simple.
Vedran Aberle Tokić
hmm, my spell checker disagrees. lmgtfy graphical ˈɡrafɪk(ə)l/ adjective 1. relating to or in the form of a graph. "flow charts are graphical presentations" 2. relating to visual art or computer graphics. "a high-resolution graphical display" Though, I presume you're right: it should be "graphic designers". I appologize.
Lucas Antoine
I really don't know how you can stay that polite when describing 99.99% of designers I have been working with in the last decade... These guys are hopeless. They probably never will read your blog, and if they do, they will laugh at your face - did you really think we were going to make an effort for a code monkey? Well, that is the impression that I get every time I tried to politely reach the topic when presented with a psd file that has 200 color codes in it, 20 font size and 30 different font spacing values for the same title.... They are useless and think they are intelligent. They are - with useless managers - the atomic pollution in IT team. If you read my comment - and you are a web designer - I hate you. If you actually write styleguides - I love you - but the probability you are one of these lovely designer is lower than 0.01%. So fuck off and go to hell.
Vedran Aberle Tokić
I'm really surprised at the level of animosity in the last few comments. I actually wrote this as a tongue-in-cheek "harsh" text. I actually really admire designers. The kind of attitude you've presented here is a much bigger issue than any design failure I've come across. If you exaggerate and generalize in this manner you're effectively disqualifying yourself from ever working in teams. This kind of offensive attitude will close many doors for you, and many ears as well. We rely on management, and we rely on design, and (despite the frustration we all sometimes feel) they are first and foremost our colleagues and coworkers. We are on the same side in the battle to produce something of value. If you have an objection or a suggestion that can improve the project, never hesitate to give it. But be cautions that you're not just asking for comfort for yourself. And if you check the article carefully you'll see that a lot of the suggestions would actually make a frontend developer's life more difficult in real-life situations. But, they'd guarantee a better end product. Should you ever come to work for me with that attitude you'd be sent away regardless of any evidence of technical prowess. A true professional NEVER blames his colleagues or tools or circumstance. A professional does the best they can with what they have. They make life easier for those around him. They seek opportunities to enable the team to achieve more instead of just asking for more. And never expects more than is available except from himself. These are not just hallmarks of good management, but a point of professional pride. A true professional can have a team of randomly chosen people with no experience in randomly assigned roles and still make sure that the product is shipped. And finally, a professional should never be impolite.
Spiffy Solar
Historically, anyway, before the computer geeks and pornographers got involved. Languages change, but I'm pretty sure graphical is a rather new occurrence. Thanks
Lucas Antoine
First, I'd like to thank you for your reply, and though you don't seem to consider my values compatible within your professional environment, I respectand understand your position I have been in your position before. I 'm not going to justify my position and language, as I believe the fine line between professionalism and personal values is unique to everyone's personality and needs. ( a worker won't behave the same socially if he has a kid and a mortgage than one with no family and no debts. the second one will more likelly tell what he really think and feels less pressure telling everyone around him what really sucks. And why and bye - I for sure prefer to not work with you - In front of dozens collegue ). I the second type of collegue. This is the value I bring in a business, i believe everything can be told. And from earlier this year, when I was the only FE dev in the middle of 5 designers, all drawing memes all days - I decided that from now on untill the rest of my days are over, no styleguide leads to me saying FU and bye. I get a job offer every week or so anyway. I decided to now stop trying dealing with those type of designers. I tried, I failed, I re-tried and refailed. I know I suck at it, and I hate refactoring psd files. And yes I agree with you. Designers to amazing creative jobs. Actually, there isnt any designer i worked with that did produce a bad looking design spec. They do things I can't do. I do thing they can't do. And no, I dont agree with you. All the advices you give dont make the coder's life harder. A decent design specs allow us to design a correct sass architecture or future theming if needed, or better maintanability. Much easier for us in the long term. This is a great article by the way, and I agree with every point you mention. Every single one of them, I verbally told severall designers about it , and they verbally didnt care. Maybe I not lucky, and dealt with all the vermine around. Maybe the real life is 80/20 not 99/1. Maybe i got unlucky.
Lucas Antoine
He was probably refering to my previous comment. Oh well, in all my carreer, I still havent seen a fe man intentionally putting 12px instead of 20px. And also, maybe you should mention that FE developers dont have eagle eyes. Even god like developer dont have eagle eyes. To us, 20px seems roughly the same as 12px, unless we open pixel.perfect , a ruler or get a designer to notify us. Hence, styleguides utility. Last time I explained that to a designer who did an admirable good looking design with hundreds of similar color codes, and unreliable margin/padding acrooss his hundreds of layers, he look at me, with this attitude in his eyes: I don't give a shit. You are paid to make it look like it, do it and stop complaining, b****. Not the first time, defintively the last time! Better for me to leave business fail with these individuals.
Vedran Aberle Tokić
He wrote this before you posted your comment. It would seem he actually saw the article itself as being hateful. Try not to put so much literal meaning into other peoples lack of response. Annoyance ("oh man, I really don't feel like doing this again") is not the same as hatred ("I don't give a shit. You are paid to make it look like it, do it and stop complaining, b****"). The interpretation of what other people don't say is only in your head, and from personal experience it is worth it to master the skill of assuming the best about people you're working with. It helps teamwork and builds goodwill. We all assume that unspoken things are worse than spoken. So if you're as explicit in what you say as would seem from your comments, imagine what they think you didn't say. And then explain to me, why you think people might not be forthcoming when you tell them to do something for you. Being a developer is 60% about being a good communicator.
Vedran Aberle Tokić
Oh, I wasn't saying you shouldn't say things you think are wrong. Far from it. But, (their base content aside) you can say them in a way that will make someone defensive and resentful, or you can say them in a way that will be heard and appreciated. THAT MATTERS! For communication it is not enough that a message is sent. If you want it to have any impact you need to make sure it is also received, understood and accepted. I don't know if this'll make sense, but there is merit to the functional programming philosophy in communication: If your statements have side-effects than your communication is overall poor, despite each statement being valid on it's own. Resentment begets resentment. It creates a toxic environment that's hard for everyone to work in. If you can work on your own (from idea to accounting) technical skills might be enough (though i fail to see how you'll make sales that way). Otherwise, cooperation and communication are essential skills. It is possible to talk to your designer in a way that'll make him react with "Wow, i didn't know that. Tell me more!"
Lucas Antoine
Your article is not hatefull at all - my first comment is. People never guess what I think, because I very often say what is in my mind. And yes you are right, this is a bad practice in life to interpret silence. Sometimes, someone's face expression can tell a lot about what they internally experience - especially when spending time with this person. And yes, being a good developer is about being a good communicator. But that is not only true for developer, but for every profession I believe. Also, I know many people who went trough lots of psychological trauma by giving a lot to cons and egoistic people who take advantage of what they though is a weakness. Generosity in effort and displaying of truth and feeling , IMO is a great strength - a great value to believe that to build, you must give first to eventually present a sharable knowledge of your weakness or your strength. I met only one designer - who had this virtue. I hope to meet more. Do you agree that there is two type of personalities when meeting a person for the first time ? First one is to assume the person you talk to is intelligent and can teach you something, second one is to assume that this person is probably useless until proven the opposite? I am the first type - so please don't assume than when I go talk to designers, I go like : do what I say ! Listen to me John, you know nothing ! Instead, I spend time explaining how style-guide can make my life and his life easier - and how it can improve general atmosphere in a team. Yet, when presented with the second type of personality described above, as time pass by, I get less patient. I think you are the best writer on this subject in the whole internet blogging world that I know off. This article is *gold* - and should be included in every design school. Thanks !
Lucas Antoine
comments powered by Disqus
The #1 Blog for Engineers
Get the latest content first.
No spam. Just great engineering 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!?"