29

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?

migrated from webdesign.stackexchange.com Oct 4 '14 at 22:24

  • I don't understand how it would be "easier" @Andy. Changing a CSS gradient is pretty easy, altering 5+ image files with the gradient is far from easier. (...and now this comment seems out of place due to the deletion of Andy's comment). – Scott Sep 23 '14 at 22:25
  • Sorry dude i was going to reword it! haha. Just personal preference really, I struggle to actually design with code. I much prefer designing in Photoshop, and then coding. Keeping it all separate. I know how easy it is to change it in code, but equally linked layer styles in PS is 2 clicks and changed – Andy Holmes Sep 23 '14 at 22:30
17

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

  • Labor division absolutely makes sense and I had considered that. I was thinking more of technical reasons to not build straight to HTML hand in hand with image editing (provided one is comfortable with the image editing and basic front end construction). – Scott Sep 23 '14 at 22:36
  • There are no technical reasons why you shouldn't use something like Photoshop. It's a work/efficiency issue, not a technical one – Zach Saucier Sep 23 '14 at 22:44
  • I like that you kept this non-subjective. A good breakdown of how it affects the designer/developer! +1 – Möoz Sep 29 '14 at 2:32
  • 1
    This is also a disadvantage, though. Just an an architect that lacks real world construction knowledge can often design solutions that are prohibitively expensive or impractical, so can designers who design web sites 'and not know anything about how it is created'. So, I'd argue that is the often argued benefit, but in reality, it's not nearly the benefit as many think it is. – DA01 Nov 5 '14 at 6:30
7
+150

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.

  1. 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.

  1. 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.

  1. 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.

  • I have to say i mostly agree with this. The only reason i advocate a mockup is to avoid doing things that are easy to do as opposed to doing things that are what you meant to do. But this is as much a argument for and against a full mockup. As photoshop also suffers from this problem as do pen and paper. Point being these are all tradeoffs. – joojaa Nov 5 '14 at 6:50
5

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.

  • 2
    And it's not just understanding the limitations, but also the capabilities. Code is simply a different medium. – DA01 Nov 5 '14 at 6:32
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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