Is there an advantage to doing a full image mock-up versus diving straight into writing the HTML/CSS?

Question

In the past, many companies and web designers had a workflow that was two or three parts, minimum -- design, markup, backend. These are generalizing and the lines may blur a bit... but I'm sure you get my gist.

Often the web designer was "visual only" and would only be responsible for constructing a very detailed mockup in image editing software, such as Photoshop or Fireworks. The mockup(s) would show every possible aspect of a web page from colors and type choices, to backgrounds, icons, photos and other images to be used. But the "designer" was never concerned with actual live construction and implementation. They were solely focused on the appearance.

Once the design was approved (by reviewing these image files) stage two was undertaken - transitioning the image file(s) to live HTML/CSS.

• In a single-seat or freelance environment, the web designer may have used slices and exported to HTML via some internal application options. On rare occasions the designer may construct basic HTML/CSS page frames.

• In some corporate environments, these mockups would remain in the form of a layered image file (.psd, .png [for Fireworks]) for the web designer and the designer would never worry about implementing any markup or code. The "designer" never had to concern themselves with how to construct HTML or CSS in order to implement this image mockup they created. Image files were/are handed off to a "developer" who is then responsible for constructing HTML/CSS which matches the image file.

I imagine some still very much work this way. However, with the advances in markup languages, namely CSS3, and browser support improvements -- in many cases the time spend carefully constructing a raster representation of a full web page can be largely useless in many cases.

With current mark up it's very easy to implement many web design needs directly via HTML/CSS and use of image application is limited to generating small image assets or photographs which may be needed. (Libraries and/or templates such as Bootstrap have further pushed this notion.)

In my own workflow I've notably moved away from full page mockups unless they are specifically requested. I do this in order to improve design speed and ensure that what is approved is close to what will be finally rendered in browsers. In fact, I haven't created a full page mockup in a number of years. But I am aware there are still workflows using this method.

Is there any real benefit to constructing full page mockups in image editing application prior to diving right into HTML/CSS for design construction?

Answer 1

The benefit of constructing full page mockups is the division of labor.

In larger companies which have both a designer and a (front end) developer, the job of the designer is to design and the job of the developer is to write code.

Having this division allows the designer to spend all of their time working on the look, feel, and interface for the website and not have to know anything about how it is created. They can create higher quality design and think through decisions for longer precisely because they are not working on getting the code to do what they want at the same time.

It also lets the developer write more code by not having to think about how any of it will look including the small details and varying states. They implement the design as best as they can in the time given and can move on to another project.

---

If the designer is the developer as well, I think most people more or less are starting to side with you in that they create a more rough product and iterate quickly to test things out. This allows ideas to be tested quickly as opposed to creating a pixel perfect photoshop document.

However, rough, iterative design without code is also a valid and incredibly useful approach especially for layouts and work flow. Markup languages and new technology didn't invent working quickly with rough ideas :)

Answer 2

I'm going to pick on Guffa with this answer. To be clear, I'm not trying to single Guffa out, but rather, the bulleted points are very common ones I hear. I'd like to offer some counter-points as well. I'm not saying Guffa is wrong and I'm right. I'm merely offering a counterpoint.

1. The creative part of the design process suffers if time is spent trying to figure out how to do different things in HTML and CSS.

This is true if one doesn't consider code equally as creative. Photoshop and HTML/CSS/JS are both mediums for an artist to work in. Just as a paint is as creative as charcoal, so can Photoshop be as creative of an medium as HTML/CSS/JS.

And the big benefit of working directly in HTML/CSS/JS is the multi-dimensionality of it. Photoshop, at the end of the day, is a flat canvas. HTML/CSS/JS is a dynamic canvas with fluidity, interaction, animation, etc.

Bottom line, I'd argue code is the more creative medium in this case.

2. When the designers and coders are different people, even if the designers is pretty good at HTML and CSS, they are rarely really good at coding. The result would be (in varying degrees) inefficient code that is bloated and difficult to maintain.

The counter point to this, sadly, is something I run into all-to-often: Most developers working in dedicated roles work in larger organization (where dedicated roles are more the norm) and, due to a lack of cross-discipline knowledge (and often a total lack of presentation layer code) make some of the most bloated an difficult to maintain front-end code I've ever seen.

Point being, I wouldn't consider one's visual design abilities any indication of their coding abilities. I'd go a step further and argue that a talented generalist that knows design and coding--even if they aren't the best designer or best coder, can often create a better overall product than the highly segregated team simply due to the fact that they can see the bigger picture as they create. A lot less is lost in translation.

3. If you start to write the code before you have a clear view of what the design should look like, you make uninformed choices about how to construct the code. The risk is that it will make the code worse, and limit the possibilities for the design.

But designing in code doesn't mean that's your production code. I've worked on projects where most of the code we created was purely for completely the design and then doing some prototyping. Once finished, we'd then do a clean rewrite. This had the added benefit of us being able to find a lot of 'gotchas' in the first round of coding.

4. The HTML and CSS code can change pretty much with small changes in the design, which would make the design process more static. You risk limiting yourself to only the changes that are easy to make in the code.

The counter argument to that is the designer is limiting themselves to only the changes that are easy to make in Photoshop. It's not a very good argument either way.

Answer 3

The only reason not to do a Photoshop mockup first is if the designer doesn't understand the limitations of the code. You don't ever want to give the client a comp of something s/he can't have in the final.

As long as the PSD represents something which can be pretty closely replicated in CSS/HTML (given cross-browser and cross-media limitations), I would do it in Photoshop (or InDesign — I know a few designers who comp in that). It's quicker and much easier to manipulate images. Mocking up in CSS to me would be coding before I was coding, if that makes sense.

Answer 4

There are several reasons for keeping the design element separate from the code generation element, for example:

• The creative part of the design process suffers if time is spent trying to figure out how to do different things in HTML and CSS.

• When the designers and coders are different people, even if the designers is pretty good at HTML and CSS, they are rarely really good at coding. The result would be (in varying degrees) inefficient code that is bloated and difficult to maintain.

• If you start to write the code before you have a clear view of what the design should look like, you make uninformed choices about how to construct the code. The risk is that it will make the code worse, and limit the possibilities for the design.

• The HTML and CSS code can change pretty much with small changes in the design, which would make the design process more static. You risk limiting yourself to only the changes that are easy to make in the code.