[IgorPartola]

Rant to follow:

So I have done a fair share of PSD to HTML, PSD to WordPress theme, PSD to application web GUI, etc. rewrites. I generally have no problem with the concept of this, and got quite good at this. However, there are some real pet peeves that keep coming up in this workflow, that are really driving me crazy. If you are a designer working with a developer, and you happen to read this, at least please consider it the next time you produce a PSD:

First, PSD's that assume text length. For example, if you have three call-out boxes with a title and some text to follow, don't assume that the title will always be one line and the text will always be the same length. Instead, figure out what this will all look like when you do have very uneven amounts of text. Do we center it vertically? Do we abbreviate it?

Second, PSD's that don't assume a responsive design. Sure, working directly in the medium (HTML/CSS) would solve this, but you can still provide some direction here. Tell me how the columns should be laid out. Which parts of the site should expand/collapse with size, which parts can be hidden, etc.

Third, and this goes without saying, but clean up the PSD layer names and groupings. Layer 1, Layer 2, etc. is not a great convention for this.

Fourth, show me the unusual cases. I know the clients always want to focus on the prominent pages, like the home page, the product listing, etc. Those are important, give me those. But also give me what a form submission error looks like. Or what a 404 page looks like. Or an empty shopping cart. Or pagination. Or a table that's wider than the viewport would normally allow.

Fifth, consistency. It sucks for the developer, and I'd argue it sucks for the user, to have every page use a slightly different set of CSS rules for headers, paragraphs, lists, etc. Best case scenario here is to give me a style guide I can trust. I know it's two different documents you now need to maintain, but honestly this is the biggest help you can give me.

Sixth, show or describe to me the interactions and workflows. A simple shopping cart can become a giant minefield of interpretations of what the design is supposed to convey.

Seventh, and this is a bit meta, but don't walk away from the design before a single line of HTML/CSS is written. This is bad because there will be questions about interactions, etc. If first I have to email your boss's boss to try to see I can ask you a simple question, the process is broken and I will not recommend working with you again.

Eighth, if you do promise to deliver sample HTML/CSS, for the love of good, do this well. I have recently had the misfortune of having HTML/CSS/JavaScript delivered to me for a large site redesign by a big name web design agency. I was very excited about this, especially since these guys said they would use Bootstrap as the foundation for this so that we would have all the benefits of that framework built right in. I got the files, opened them and OMG. It did include Bootstrap, but in name only. After that declaration, it instead included a completely custom column system that was just slightly incompatible in sizes with Bootstrap's. It also used none of the same class names even where it made sense, etc. Needless to say, I had to re-write all of their CSS from scratch, and re-adjust lots of the Bootstrap variables to accommodate their column system.

</rant>

Great designers are worth their weight in gold. The above highlights that the waterfall process of design -> develop does not work. Instead it should be design -> develop/design/develop. If you cannot step outside of Photoshop that's fine, but if you want to be efficient, you must know the final medium, which is the web.

[wonderyak]

Just to belabor your well made point, here is an example of a final PSD I received from a 'professional agency': (from psdgrade.com)

https://cloudup.com/c5RmHN8t1QZ

https://cloudup.com/cmpmBEYg93c

Thats 27 different font sizes for ONE PAGE of a site. I bet most of this was done through scaling layers to 'fit' into spaces.

There were also 42 layers named some verson of <shape>-n.

[grey-area]

Would you normally expect a psd to contain exactly specified type sizes?

I don't use psd comps myself, but I'd treat them as more sketches and guidelines as to actual style and placement, rather than some sort of specification document, because it's a different medium and text handling in ps is pretty basic - it's really not suited to extensive text layout.

[IgorPartola]

To pile onto wonderyak's point, I am a developer, not a designer. I wish I was also a designer, but due to where my talents and experience lies, I cannot do both well at this point. The problem is that I cannot tell what is and what is not important in a design that is handed to me. I have had conversations with designers where I inadvertently change a margin on a callout box by +/- 10% and the designer notices and explains that they arrived at the exact margin by a long research process, and by the way it matches all other places where the margin is exactly 40 pixels and not 36, etc. There are changes that are not consequential and there are changes that completely undermine the message the designer was trying to send. This is not an ego trip. This is a professional telling me that they've thought through the problem and I trust they know much more about the problem domain than I do.

Ideally, I try not to change the design if possible. However, unless the designer is very good, it does require lots of tweaking here and there, which introduces delays and compromises the vision for the finished product. If a designer has long since walked away, it can become a huge problem.

[grey-area]

As a designer and a developer (I often do both), I think I see where you're coming from, however I feel this is more a sign of a breakdown in the relationship between the developer and designer than a shortcoming of the tools. Design isn't so scary - I think a lot more developers should try to pick up a little, just as designers should know at least a little about the final medium for their work, and in an ideal workplace there should be at least a handover with plenty of chance for feedback on things like text styles, not just throwing something (PSDs in this case) over the wall from designer to developer.

I would never accept a photoshop comp as a developer or send one as a designer and expect it to be reproduced exactly, because it's in the wrong medium, and it's a terrible way to specify things like text sizes or column widths except as a general indication. There has to be some give and take (and a lot of feedback) in a process going from something static and done without grids like a sketch (e.g. a psd or pencil sketch) to a final website, so what you describe in your feedback from the designer is a normal process I think and to be welcomed, it's inevitable in the translation to HTML. The design will change as it has content added and goes into templates, adaptations will have to be made, and the design must be flexible enough to deal with that, and your designer should be around to help with it - if they're not they're not doing their job properly.

I guess what I'm trying to say is that dealing with change is part of the job in design, and your designer should gracefully do so, in which case it is no problem if they gave you a vague psd - it should be vague at the early stage before implementation, because there will be changes, and additionally, html is just not a medium which allows us to specify layouts which are exactly the same in all conditions - browsers, text sizes, fonts, scripts, proxy servers mangling images, user stylesheets all affect layouts, so you have to accept that not all users will see content at exactly the same sizes or with the same fonts or even the images as you intended them (if they're on a mobile network, a proxy might have downsampled the images).

[IgorPartola]

So this works really well when you are working with the designer. When I can walk into your office and say "hey, can you pull up the dev site and take a look at page X? I think we need to figure out a better way to display this" I am very happy. Even mediocre designers can deal well with this modus operandi and produce much better than mediocre results.

Where we run into a problem is when a client hires a design firm, works with them for months on a new site or application look and feel, gets invested in it, pays the designer and maybe even starts development with a few days' overlap with the dev shop. Another example is when you deal with extremely low budget jobs (less than $1k), where you are simply trying to minimize hours spent on a project. I have done WordPress themes off good, clean PSD's only in less than 8 hours. I have also spent close to 80 hours on some where the PSD's were super detailed, but lacked any kind of direction. When the designer or the developer is not in-house, communication is key, but is often a place where costs are cut.

[grey-area]

I truly believe both design and development must be ongoing and collaborative processes, and the problems you've identified above are all down to trying to divide work at points where it cannot usefully be divided - the first scenario you mentioned is the only way to produce good design IMHO - as a collaboration with the client and any other parties like developers.

[wonderyak]

I agree with everything you're stating here, I just wish it was that easy in practice.

Some of the problems with deliverables is managing client expectations, they expect or have gotten used to seeing output of a PSD that counts as 'what their site will look like'. The creation of a PSD as a deliverable for the 'final design' is boilerplate for every agency I've ever worked with.

Responsive design has finally started nailing the coffin though; it becomes too cumbersome for designers to create renderings of different viewports, let alone understand the intricacies of how media queries work or how assets are delivered to different devices.

There has been a lot of creative thinking about deliverables (Style Tiles, Atomic Design) which is helping us get over the hump.

I would hazard a guess that most of the sites in the SMB space are either WordPress templates or custom designs that were then handed off to a service or an outside developer to make into functional websites. Sometimes, the developer doesn't get to see anything until the client has signed off on the design. I see this happening with large companies which do multiple millions of dollars a year in agency work.

[wonderyak]

Yes, since there is an implicit agreement beforehand that the PSD should be converted to HTML/CSS.

For example, if I missed a border on an element or margin spacing between text areas this would be something I would be expected to fix. The designer would most likely point this out. Many designers I've worked with get very upset if you change anything in this regard without some sort of discussion.

The point you bring up about text handling is true as well, which is another reason that PS is not a great way to design for the web. AI might be a little better, but not by much.

[grey-area]

Yes, since there is an implicit agreement beforehand that the PSD should be converted to HTML/CSS.

I see why it'd be a pain for you, but feel like this process of handing over a supposedly pixel-perfect design is inherently broken - without collaboration the design will be dead as handed over - it should be changing constantly as you encounter difficulties, first in translation to templates, then in putting in content.

Specifying text sizes in a PSD is insane! It doesn't even have styles so I see why the designer hadn't bothered. I think I'd honestly prefer to receive a hand-drawn image with scribbles for the different text sizes.

[wonderyak]

Oh, the process (as normally done for the past decade) is completely broken. Thats one of the reasons that the groupthink behind "PSD to HTML is Dead" is important in spite of how hyperbolic the statement is.

There is always an adjustment period throughout development, however just a simple understanding of the medium would eliminate all but the toughest of these problems.

For as long as I've done this I have mostly worked with designers that started in print, have zero to very little experience in working with the web and do not care to learn.

It is not just the designers who hold blame here though as the instituions which employ them do not require anything more than they've done their whole careers.

Combine that with the fact that a lot of these designers are expected to design for both print and screen, it creates a situation where you cannot expect someone to know all of the nuances of both mediums. When this happens, things like declared text sizing is important in the PSD because thats how they set up their print files too. Everything is implicit.

[johnjlocke]

So developers actually have to know quite a bit of Photoshop in order to translate designs into authentic representations of a mockup.

[evunveot]

This kind of work has been a large part of my job for a long time, and I definitely recognize all of those frustrations. This may be obvious, but the problem is usually not a lack of communication but rather that the designer/client/manager isn't able or willing to think through the design fully. As such, when you seek clarification on something, you're really asking the stakeholder(s) to figure it out for the first time.

I've learned that a good strategy is simply to figure it out for them and hand it back complete. Not only does this eliminate communication overhead, it allows me to pick a solution that strikes a good balance between quality and my own time and effort, as opposed to having to push back against some half-baked, unrealistic idea.

The vast majority of the time, whatever I come up with is accepted either without comment, with minor requests for tweaks, or with elation. In the rare instance that something needs to be redone from scratch, I've at least gotten the ball rolling and given the stakeholder(s) some idea of what's possible.

It's kind of like turning a waterfall process into an iterative one by doing the first iteration yourself.

[yogo]

I think the first point is an issue common in print designers designing for the web. A real web designer designs knowing the limitations of the web, and with the understanding that text flows. Whenever a comp has regions with height constraints (something I believe should be avoided on the web), 9 out of 10 times it will fall apart in practice because a client will dump a bunch of text in a box and cause the other areas to create gaps.

[johnjlocke]

I do a lot of front end development for agencies, but also a good amount for my own projects. I only present mockups to clients, so we are all on the same page.

What I do with the PSDs for my own projects is use Layer Properties to name the color (and if applicable, the font, weight, and pt size). That way, when I go to do the build, I can glance at the layer and get that information quickly.

Many PSD designers group layers, but don't put extra effort into naming layers. Little things like that make a huge difference in time.

[nebtune]

As a designer, I love hearing what developers want. I always hope the process is going to be a two-way conversation. It helps me a great deal to hear what the developer wants. I also agree that if you're going to design for the web, in PS, you had better at least have a basic understanding of how HTML works and how a web page is put together.

[wonderyak]

The best PSD I ever recieved had a layer exclusively reserved for annotating margins and spacing. I didn't have to dig into the PSD and check the toolbar, all of the figures I needed were right there.

It even came with a PDF style guide outlining line spacing, font size, colors in hex and margins/padding.

I've never been so elated to get a PSD.

[IgorPartola]

Thanks for understanding. I was really hoping that the original comment wouldn't come through as a rant about designers in general, but more as a list of things that good designers should avoid. I think most dev shops can do very well to hire at least one competent designer instead of trying to separate the design phase and the development phase and outsource the design.

[nebtune]

It may have been a rant, but there was some great info in there. Being a designer, I didn't take offense at all. Many designers don't want to "get there hands dirty" with html, but I think that's changing, especially as there are newer designers that have never designed for print entering the market.

[Quarrelsome]

> But also give me what a form submission error looks like.

I've been waiting over three months now for my designer to give me this. I mention it every time I see them and it never gets done.

Do they like my awful pink error boxes or just avoid errors when demoing???

[IgorPartola]

My favorite was this nice redesign I did where the form fields had no labels. Instead the designer cleverly used placeholders on input elements to identify them. Moreover they had a great deal of customization for each form to make them look nice and compact. At first glance this looked fantastic, until you try to add an error message to it.

I pointed this out to them, and their first inclination was to highlight the border of the errored out elements in red. Great, except for the large minority of users who are color blind. Also, this doesn't indicate what the error is, just that there is one. On top of that, form-wide (vs field-specific) errors still don't have a place.

This drives me crazy, because it's not like I can logically extend their design and say "let's put the errors here. What do you think?" Their design was so tight (in a good way I suppose) that it left no room for this kind of thing.

My suggestion is to make your version so ugly that it cannot be overlooked. Put the errors in size 72 font in neon green right over the fields. No way for it to go into production that way.

[Quarrelsome]

you're describing my exact scenario here.

[debt]

Is there a known method for documenting an interaction in a design mockup?

[wonderyak]

Using HTML and JS works great and provides exactly the same interaction you'd see on the final product. I think trying to do anything else (unless you're extremely good at video processing) is insane.

[debt]

I hear Framer(http://www.framerjs.com/) is pretty sweet.

[IgorPartola]

Not easily. Adding a few layer groups that show different states often works well for simple things. HTML/CSS + JavaScript are great if the designer knows how to do this. The next best thing is something like Balsamiq workflows with a detailed textual description.

[whatusername]

've heard of but haven't used: http://keynotopia.com/