Recently, we worked with a graphic designer (arranged by the client) to provide the skin for a Django+Bootstrap application we had built. The designer provided a series of static images of the new layout, along with a document describing some technical attributes (font sizes, colours, a few dimensions etc).

It turned out to be incredibly time consuming to implement this. Although the whole site was basically a front page, an index page, and half a dozen detail pages, I spent at least 5 days just implementing the CSS and HTML changes. So I'll go out on a limb and call this The Wrong Way.

My basic approach was:

  1. Compare the static image and current rendering, and notice a difference.
  2. Guess what change would be need in the CSS/HTML
  3. Make that change
  4. Go to step 1.

Some of the particular issues were me not understanding that the design included a change from 8 columns to 12, some images provided in the wrong format (.png's can render differently on different browser/platform combinations), hassles trying to undo Bootstrap's styling, the usual CSS wrestling to achieve pixel perfect rendering etc. And occasionally I had to reorganise the HTML templates to get a certain behaviour.

What's the right way?

  • 2
    Seems to me like you need a better designer. Someone that understands the web.
    – boatcoder
    Commented May 30, 2013 at 20:32

6 Answers 6


In my company, there are a few people specialized in this job.

They are designers. And they know HTML. They can be a bridge between the designers and the front-end engineers; which they usually are. This way, we just have to integrate their HTML.

This is a hard job. There's a reason sites like "PSD to HTML in 24h" work well. The solution in our company is to have people specialized in doing this. For us, working with the HTML is a breeze.

There's no silver bullet.

  • Interesting - mypsdtohtml.com . Wonder what the HTML is like - and whether they can handle things like Django templatetags. Commented May 29, 2013 at 13:17
  • 1
    @SteveBennett they have a portfolio :) Why do you want them to handle django template tags? They have a PSD, they give you an HTML. I don't see what more they'd do. You don't expect them to integrate your code, do you? ;) Commented May 29, 2013 at 13:23
  • 1
    Ha, do you put your average quality work in your portfolio? :) Anyway, if they converted a bunch of static images into a bunch of static HTML pages...it's still a fair bit of work to turn those into dynamically generated pages, decomposing them into nested templates etc. I wonder what kinds of sites this process would actually be useful for. Commented May 29, 2013 at 13:26
  • 1
    @SteveBennett, I feel like decomposing fully-build html pages into dynamic templates and partials would be relatively easy -- it's essentially a straightforward code refactor. For most designs, I think would be a much easier job from the standpoint of a programmer than building up the html/css directly from the psds.
    – Ben Lee
    Commented Jun 3, 2013 at 18:27

I'm not sure there is a "right way", but a reasonably effective way of cooperating with a designer is to first build an unstyled system that uses templates and allows for the easy interchange of all templates. Then, once you have a functional-but-unstyled (or minimally styled) interface, you hand the results over to the designer for styling.

A decent example of this sort of design pattern would be jQueryUI (http://jqueryui.com/)

  • 1
    Yeah, one mistake we made was building unhelpful layers of skins. 1 Raw bootstrap, then 2 minor tweaks, then 3 a fairly rough skin for a demo, then 4 the professional skin - which looked absolutely nothing like step 3. Some of that extra CSS really started to get in the way. Commented May 29, 2013 at 7:17
  • mistakes get made, just make sure you learn from them, in general, try to keep things as simple as possible while staying modular :)
    – Eva
    Commented May 29, 2013 at 7:29

First, I have to admit that I never have worked with web front ends so far.

But I think it might be good practice for you and the designer to write prose of how the final design should look like. That way you can be more sure it is consistent, because it would smell if you were describing different tables for every page. Prose can make your implementation easier, because you are actually writing code, which is closer to your implementation than images.

Also try to make the designer focus on components, not whole pages. If you get the components of a page right, then composing them to the whole page is a much easier step.

  • +1 for "focus on components, not whole pages". Good idea. Commented May 29, 2013 at 7:20

I have been develloping HTML/CSS with several designers and as already stated, there is no "silver bullet". The designers I have worked with didn't know much (nothing) about html/css. Some of them had some experience in webdesigning and I must say when they have that knowledge, it always ends up with easier to develop and "better website" especialy when responsiveness an UX is involved.

I guess what some companies looking for a website don't know/ignore is : anybody can say he is a graphic designer/webdevelopper/webdesigner/UI designer with basic knowledge (or even none, yes I have seen that) in either. Whereas "real ones" can go the extra mile and produce maintainable, effective websites. I try to "educate" the client and explain that Webdesigning involves skills that "print only" graphic designers don't have. When this works I usualy send the client towards designers I have already worked with and have a common workflow with.

This said, it often happens for many reasons that you end up building websites with people that have graphic skills and no webdesigning skills. In this situation, the best way I have found to save coding time and not end up with a undevellopable layouts is to be involved in the design process and communicate with the designer and explain what you can/cannot do and what would be simpler/better from your point of view.

Although this can be difficult to organize in some situations, it is capital to explain to the client and the designer that "if you think webdesigning form the bigining of a web project you end up saving time, money and headeachs" and that you will be happy to take part in the designing process to save that time money and headeachs.

This is the worflow I try to follow in most projects :

  1. The designer builds graphic standards if they don't exist (I usualy don't get involved here. I just try to hint the designer towards web compliant fonts ex: google fonts)
  2. Mokup made by the designer. I get involved here and work with the designer to build web compliant layouts (especialy for responsive ones) before the client sees it.
  3. client validates mokup
  4. I code the mokup

The time I have spend communicating and working with the designer is saved during the coding process and this ends up with simpler, more maintainable and neatter code.

This doesn't save you from a happy designer calling you on friday evening with a very pretty mokup that the client has seen and now wants with this sentence : "Hey pall, could you code this for me, deadline is ... yesterday!" Then the whole theory falls apart and if you are looking for work at that moment, you're good for a headeach all week end.

Conclusion :

I don't think this is very different than any code related on not project, the best way to work with other people is to communicate with them.


As a graphic designer turned full stack web developer, for me this has so far been the easy part. I find that a lot of times there is a communication gap between a UX design team and the developers that implement the product. Sure, documents help, but the process can begin to feel a lot more natural once some face to face conversations about strategy occur. Also, I know that time is scarce for everyone, but try to get involved during the design and layout phase. This can help tremendously when communication is needed between a designer and developer. The project takes on more of a unified team effort and less of a "Well, I'm done my part, over the wall it goes" scenario. I have found it to be very beneficial to have the design and development work happening in parallel, encourage the design team to supply you with wireframes early in the process. That way, you can do one style pass that deals solely with layout and positioning. Then, as the deaigns become more rich and complete. Take another CSS pass for appearance and other style attributes. At least this keeps you from having to focus on everything at once.

  • 1
    this post is rather hard to read (wall of text). Would you mind editing it into a better shape?
    – gnat
    Commented Aug 17, 2015 at 12:36

I am facing a similar problem. i have the idea that tools like Greasemonkey or Tampermonkey can be used for that purpose. Just last week, i asked for comments about this idea: How to outsource the UI of a dynamic Web application?, but didn't get satisfactory responses.

With these tools you can inject CSS, HTML and Javascript to a page. In my idea, you give the URL of the working site to the designer and expect Greasemonkey scripts in return. Theoretically you should be able to integrate those very quickly to the existing site. This way, it will be the designer's job to write the HTML and CSS and make the site actually work. This requires much more programming skills on the designer side though.

I know that this idea requires much elaboration. But I haven't tried that yet and don't know if anyone else is doing this. There may be some problems with the implementation.

  • 3
    Sorry to generalise, but a lot of 'graphic designers' don't know HTML and CSS, they know Photoshop, Corel/Illustrator, InDesign, Quark, etc. This is backed up by the OP saying the design was delivered as a 'series of static images'. If they did know HTML and CSS, they would be 'front-end developers'.
    – Dhaust
    Commented May 29, 2013 at 6:21
  • In this case, the designer claimed to know a bit of CSS and HTML, and expressed parts of the design that way (eg, #abc colours) but not enough to make a big difference. And some of the terms (eg, "padding") ended up being ambiguous - not their CSS meanings. Commented May 29, 2013 at 7:19

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