How to communicate web design mockup specifications to front-end developers?

Question

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?

Answer 1

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.

Answer 2

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!

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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?

Answer 7

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 :)

...

Answer 8

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.