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?

  • I have very successfully used Zeplin (zeplin.io), to communicate the design specifics to the developers. It integrates wonderfully with Sketch (and now beta in PS too), so do check it out. It saves lot of time, as the developers get the graphic assets individually, the padding, spacing, fonts, sizes etc - and sharing the exact styling is a breeze.
    – Amit Jain
    Commented Sep 13, 2016 at 17:16

8 Answers 8


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.

  • 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.
    – Haze
    Commented Apr 2, 2013 at 5:05

I have found the best way is to build out the front end in whatever tools the front end engineers are using. In our case, that's Angular Material.

So I built out a style guide using Angular Material (which I learned as I went) that shows the various elements that comprise most of our applications: lists, buttons, form elements, tables, etc. I used off-the-shelf Angular Material elements as much as possible with minimal overrides to accommodate branding or specific uses. The front end-team is encouraged to copy my HTML and CSS. If I mark something up as a table, for example, there's a good usability reason for that, and it shouldn't just be built with a bunch of divs to approximate the look of a table.

Now I generally only need high-res comps to "sell" features to stakeholders in formal presentations or for quick-and-dirty user testing, and then detail functionality and various states in low-res wireframes for the front-end engineers.

I also will sometimes do high-res comps for the front-end team if there is a slight modification needed to an element or if there's an entirely new one-off element that doesn't need to be in the style guide. This also helps in showing how some elements combine because I find the front-end team sometimes doesn't quite get how to combine style guide elements (too little/too much space between) or there's some additional element (lines, different background to set something apart, etc.). needed.

If it's a new application or complex feature, I will also sometimes do a high-res HTML prototype to communicate transitions and animations (happy path only). If I get some actual formal user-testing time (all too rare!), I will also build a happy-path HTML prototype. The engineering team finds this extremely helpful and they would like me to build a prototype for everything!

  • Great answer. Specifically around building HTML prototypes which the engineering team find helpful, I believe this is where a lot of web designers/ui designers will have to focus their attentions to. Providing dozens of exported PNG's from Sketch/Photoshop is not an efficient means of communicating design. Especially for the web which is rich with micro-interactions.
    – philip
    Commented Jul 24, 2017 at 23:04

Having considered my experiences from more recent projects, I believe that adopting or creating a design/development framework is the most efficient and effective way of communication design specifications with front end developers.

I think the popularity of bootstrap related development frameworks, and the emergence of Google Material Design related development frameworks is an indication that these approaches are beginning to solve a lot of communication problems for designers and developers.


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.

  • 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
    Commented Apr 1, 2013 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
    Commented Apr 1, 2013 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
    Commented Apr 1, 2013 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
    Commented Apr 7, 2013 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
    Commented Apr 7, 2013 at 0:16

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.


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?


When the front-end developer does the "slicing" aka converting to html/css (to not be confused with the old slicing that will never ever ever be done on any modern developer workflow, well maybe sometimes), he will need the .psd files. From there he will be measuring everything using the built in tools. For design Photoshop is a better tool instead of Illustrator, unless we are needing some vectorial shapes that need's to be exported as svg files.

What you need from them, is to ask what frameworks they will use for the project, because that will change considerably how they build stuff.

eg: if they use bootstrap (99% use it), then you need to take that in consideration

text1 text2

the container has 15px padding on left and right the row has -15px margin left and right the col-* will have 15px padding left and right

which will mean, that the content starts from left at 15px and in bettween text1 and text2, you have 30px distance...

if you follow this measures I'm sure the front-end dev will love you :), because they don't need to work against the framework

if they go custom all the way, a good practice if they need really fast sites, they even better, unleash your creativity :)



A live style guide is the best approach, however if you've designed without a grid system in mind then nothing you do really matters as the developer will be constantly battling back and forth with pixel perfection. Same is said for if you designed desktop first and then mobile, ads development happens mobile first.

The best approach is to talk to the developers and see what they would like as a reference, and keep yourself open to them, don't just hand off the project.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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