Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Looking for best practices for communicating website design specifications to front-end developers for slicing.

Knowing that the developers will need more information than a visual representation of the design, I am looking for useful ways to communicate detailed design specifications of our graphical mockups, for example, the pixels and padding between various elements of the design, so that they can be effectively sliced into HTML and CSS. I am using Adobe Illustrator CS5 to create the graphical mockups. We have a working relationship with our front-end developers.

The question: what in your experience are good ways, or best practices that you follow, to clearly communicate web design specifications to developers for execution on the web?

share|improve this question
add comment

4 Answers

I consider myself a web designer / front end designer, or maybe front end developer as you'd say? (basically 90% of the time my work takes place between photoshop, css, html, and js/jquery)

Because I've never used illustrator to convew web layouts, explaining the exact padding / margins in pixels has never been too difficult of an issue. In the past when I've worked on designs while someone else is doing the css, I would generally slice the psd myself, hand images to the developer one by one, and explain where it should go, what heights, width, and other specifications were needed, and some sort of strategy for implementing it, if it was something a little fancier than your typical css.

That said, I get the impression that this was an unusual case, where if it were a larger organization, not a two man company, I would've just been coding it myself instead of trying to split up the work because our skillsets overlapped.

As far as interaction such as hover states, you really just need to annotate it, or explain it sepparately to the developer. I would at least have a sepparate layer clearly labeled hover state if you're handing off a psd, but if you're slicing images yourself and handing off an image sprite, it should be pretty obvious what to do.

There doesn't seem to be one standard process. I think each organization divides up work a little differently based on the skillsets of the people in the office.

On a side note, is there any benefit to using illustrator to mock up websites?

share|improve this answer
add comment

The best practice is to build the front end. UX teams should be able to provide the presentation layer as part of their deliverables. Interactive design is, by nature, interactive so can't easily be fully annotated in static documents.

Granted, due to staff, corporate politics, or budgets, that's not always doable. So, barring that, it's going to take some work. One option is various amounts of documentation. But that is documentation that serves no purpose other than to translate one type of document (PSD or wireframe) into another set of documents (HTML, CSS and JS) that, in the end, is usually tossed out anyways.

As such, I'd suggest skipping that whole extra layer of documentation. Have your UX team work closely and tightly with your front end development team. Daily stand-ups are a great way to handle this. Developers can work off of your primitives and as interactions and visual details are refined, the UX team can jump in with tweaks and suggestions as needed.

share|improve this answer
add comment

I find that the best way is to annotate your PSD files with the design specifications. This has two advantages: Firstly, the designers get to see exactly what the design looks like, and secondly they can also get the CSS directly annotated on your design specification (or in whichever way is most convenient for the designer and developer). Then you can just export the file into a smaller sized image and stick it into a style guide, which can then be referenced by other designers or developers working on the project now or later.

share|improve this answer
1  
While this is common, I've never seen this work smoothly. The catch is a PSD is static, so doesn't take into account browser discrepancies, device discrepancies, or any of the actual interactive aspects of the UI. As such, it tends to make a heavy document (PSD) even heavier and much more cumbersome to maintain. –  DA01 Apr 1 '13 at 7:52
    
The idea is for the style guide to set out the design considerations and rationale, and I would typically provide a wireframe that illustrates the design and use the PSD as an example of the implementation. Compared to designers and developers maintaining their own documents, I find it easier for the UX designer to bring the two together so that everyone is talking the same design. –  Michael Lai Apr 1 '13 at 21:34
1  
I understand, and have done that. It's typical. I just find that it's 'never enough' as static documents can't communicate all of the intricacies of an interaction (IE6 vs. chrome, responsive layouts, keyboard vs. mouse vs. touch, etc.) –  DA01 Apr 1 '13 at 22:21
    
There is a perfect solution because a lot of it comes down to what the best mode of communication is between the designer and the developer (and the UX person as well). A major problem with a 'dynamic' document is that things change too much and people have problem working out what it is that has been changed or they focus too much on the interactions rather than the design. Having said that, it does work for some people, but in general I would think that being able to separate the layout from the interaction and also being able to define specific versions makes static documents attractive. –  Michael Lai Apr 7 '13 at 0:13
    
"things change too much" = I'd argue that's not the problem with a dynamic document, but the benefit. ;) The problem is that as designed on static wireframes/PSDs, rarely does the final site match for a number of reasons. Designing and building a web site is always going to be a dynamic process, hence my aversion to completely static documentation. All that said, I do concede that sometimes that's just the way it has to be. Things like off-shore development pretty much demand static documents. –  DA01 Apr 7 '13 at 0:16
show 1 more comment

Personally, I love Balsamiq because it allows you to focus on the information and interaction, and not needless details. This is right level for functional design that has to be passed around and agreed upon.

However, this has to be translated into detailed specific layout. This is best done by the actual developer, and possibly with an agile review cycle with someone more specialized in visual design. I have never seen it work well by creating a detailed pixel-level design up front abstractly from the actual code -- it is too much work and there is not enough gain. It is better to have the visual designer sit next to the programmer with a basic implementation, and tweak the detailed layout until it is visually appealing, with REAL data in it.

All that being said I have worked with visual designers who use Adobe to make example layouts early in the project. These are helpful to get a general idea, but they NEVER help in the detail work, because you simply can't know enough about the detailed interaction between different requirements. We ALWAYS throw those away, and get the visual designer directly involved in the code.

More at my blog post UI Guideline Resources.

share|improve this answer
1  
AgilePro, I agree with you. BALSAMIC is an awesome software with all the wonderful features it provides and linking of the components/screens/buttons etc.. is the best part of it. Also, it provides the different formats for exporting the screen flow, out of which PDF is the most easy and clear which I find useful personally. Dan can easily creae the whole project dummy in it with side-notes, arrows, colors to show the minute details. –  komalh Apr 2 '13 at 5:05
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.