The process of designing websites

I am not posting a question, just an observation that I found learning web design.

I’ve been designing websites on Photoshop and then coding it to CSS. But usually I would do about 80% of the design and then code it and then go back and add the remaining pieces and then code etc.

But I have found that it took much longer to finish a design and it never really turned out right. I just realized that you should complete the entire design including the inner pages in PS before you even try to code. Everything should be in the design - the forms, the email links etc.

Thanks.

That’s not the only way of looking at it. Check out this article, for example:

personally, I don’t like using Photoshop or image editing software to create mockups.

but I do use photoshop to make buttons, backgrounds, prepare images for web publishing etc.

in creating a mockup, the first thing I do is use this colour scheme generator to generate the main colours and their relationships with each other and then use html and css to create the mockup. the mockup won’t include any javascript functionality - just the front end layout.

this way, once the client approves the mockup, most of the html/css coding is already done.

Well yes, that’s one way of doing it. If the visual design is more important than the content and usability then it’s probably the right way to go. But if you want a flexible website that is user-friendly, works on different systems and setups, and has a good content structure, then it’s usually not a good way.

We get a huge number of queries on SPF from people who have either designed a website as a PSD or, in many cases, been given a flat PSD to use as a design, and tried to code back from that. Invariably they run into huge problems trying to create a pixel-perfect representation of a fixed-size image in a dynamic environment.

Although CSS Zen Garden is a bit old-hat by now, it illustrates very well how well-structured code can be adapted to pretty much any visual layout and graphic design. If you write the HTML code and contents first, you can then style it as appropriate, and build up the styles from scratch. If you start off by drawing pretty pictures, you’re likely to end up with a layout that has too many fixed dimensions that put unhelpful constraints on the content and flexibility, which makes it much harder to turn into a good quality web page.

The designs created in this article look just fantastic. I will try this approach.

I think you’ll find that the quality of the designs in that article has nothing to do with the way they created their mock-ups…

In most cases it is enough to design the landing page and couple of aggregates. From there normally the look and feel established in those can be applied throughout the entire design, using CSS avoiding separate mock-ups for every single page. Though, there are cases that it may be necessary to design mock-ups for pages that have a high level of contrast to that pf the mock-ups created. The best thing to do is create design for pages that have a high amount of contrast in the content. Content dictates design so pages with similar content will most likely take on a similar design, or something close. The most important design is always the wrapper that encompasses the requested content. The wrapper can sometimes be enough in itself, supplying general look and feel, location of constant menus, rails, etc common to every page.

In my experience, a complete static mock-up always results in less time writing front-end technologies to achieve the design goal. The more guess work that eliminated the better. Guessing takes time. When something is not accounted for in a design mock-up that is time the person writing the front-end technology has to take to go through a process of trial and error. When most, if not all major visual decisions have been resolved in the mock-up its just a matter of recreating it than playing designer.

Also, as much as people would like to believe design is completely separate from HTML, that isn’t quite true. There are always situations that require modifications of HTML given a certain design goal due to limitations with CSS, always. Especially if your working with designers who share the same passion for design as you do programming. In the case of delivering work that doesn’t look like all the other crap out there.

That isn’t to say its not good to start with the HTML first, but its always more efficient to have an idea of what the end design will look like to account for any possible edge cases, that CSS it is not entirely adequate for down to support for IE6/IE7. That is one of the big ones. Modern technology does make many things possible with only CSS that once were not. The issue becomes judgment call at that point – whether to modify HTML to account for older-browsers or degrade. Its always a tough issue ion the real world, of non-static, fully dynamic web applications.

I highly encourage mock-ups. To me mock-ups are equivalent to that of sketching for a logo – absolutely necessary. Especially if the people developing a site don’t have a creative bone on their body. The less guess work eliminated, the more developers will like the designer. The road block always comes when I have to take time out of development and make some actual decision designs, that were not accounted for. Its to be expected, considering the medium but like is always easier when design decisions are eliminated and its just a matter of recreating a supplied visual top to bottom.

To that end the mock-up should really be the final design. Think of as exactly what a single page of the website will end up looking like. If your not satisfied with it redo it until you are. Bad things always happen when you start with a mock-up that isn’t fully complete, like wasting countless hours changing colors, fixing spacing in CSS, or god forbid on change getting the creative juices flowing that result in heavy modification of the initial layout. All of which are much easier to go through a trial and error process in a design program than CSS.

Design work is fun sometimes but as a front/back-end developer I rather not deal with it. being supplied complete mock-up(s) makes that mostly possible.

That isn’t an issue with the process but a lack of understanding. You can’t say starting from all static mock-ups is bad because people who obviously don’t know what they are doing in the first place can’t replicate a static image. It just comes down to knowing what you are doing. Like anything if you don’t know what are doing in the first place than its going to be tough to do it.

However, I can agree with what you saying for beginners. Avoiding a design program forces someone to learn the technology and its limitations. With that I can agree but its not the correct process of designing a production level web application. Its just a good way for people just beginning to learn and move-on to being able to replicate any given static mock-up.

To me drawing some goof-assed picture in a paint program is putting the cart before the horse, and the end result is most always not just an accessibility /FAIL/ but over time ends up little more than shoe-horning content into a design it was never meant for.

The IDEAL design process IMHO is as follows:

  1. write up the content as plaintext

  2. Apply semantic markup to the content with ZERO concern for the end ‘screen’ appearance. Semantic markup should give you a usable/accessible document even when CSS is not present.

  3. Bend the markup to your will using CSS for your screen layout… and your print layout (kill colors and hide stuff that’s useless for print users like menus), and your handheld layout (FaC and some alignments only).

  4. THEN and ONLY THEN do you start up your paint program (Photoshop, GIMP, PSP, doesn’t matter) to create graphics to hang on the layout.

It’s called “progressive enhancement” – and when practiced properly the resulting page ends up with “graceful degradation”.

But then I am willing to swallow the bitter pill that people do not visit websites for the goofy graphics you put AROUND the layout, they visit for the CONTENT – which is why content goes FIRST.

In fact said graphics can often DETRACT from the user experience instead of enhancing it much like most of the garbage people use jquery and other scripting for. There’s a reason after all the major success websites are as a rule NOT a visual tour-de-force. Google? Amazon? E-Bay? You REALLY think they have a PSD jockey designing their layouts? OF COURSE NOT!

WHEN I’m in the situation of working with one of the PSD first nutjobs – and I do consider it a truly nutzo approach – I will generally end up saying “where’s some actual page content” and telling them that “this image can’t be done as the page should be able to expand it’s width as at least semi-fluid”, “this gradient is garbage since it prevents this box from being able to have a dynamic height”, etc, etc, etc… Usually by the end throwing out everything they’ve done since I end up having to create new images anyways since none of their ‘layers’ can be properly ‘sliced’ for things like sliding-doors, eight-corners, two-d states, etc, etc…

In fact I have rarely if ever seen a PSD first developed website that wasn’t total CRAP in terms of broken layouts for large font users, crappy little stripe fixed width layouts, content blowing out of fixed height images, and overall a miserable accessibility failure… Usually they’re 100% bloated garbage that the “designer” should be embarrassed to even admit association with.

But I’m willing to kick a client to the curb if the only thing they know is what they want the site to look like and not what they actually want on it for content.

If you want a good working design for a website, then you can’t replicate a static image, full stop, period, end of. Because a good website design is not a static design. It has to be able to adapt to different contents. It has to flex and bend and work with different window sizes, different font sizes, different OS settings. It should interact with the user. It’s hard to get all that across with a static design. Maybe you’re a very special kind of PSD operative who actually can convey all that information, but pretty much every other designer out there will produce a flat image that doesn’t give any information on what dimensions are fixed, elastic, fluid or fill; they assume that the contents will be a fixed length and fixed text size; and then the HTML/CSS guy does have to guess, because he hasn’t been told what the page should do in different situations, just what it should look like in one particular scenario.

And even if you are that one special person who does include all that information in the design, it’s still a backwards way of doing it. Yes, by all means sketch out a rough layout, so you’ve got a feel for the main content blocks on the page and what order it will be easiest to deal with them in, so you’ve got a starting point for your HTML. But it is much easier to layer CSS onto a structure, and then tweak it until it looks “right”, than to start with a pixel-perfect goal that you then tie yourself in knots trying to recreate.

There, fixed.

I guess I don’t think it should be the designers responsibility to account for those things in a mock-up. Yes, it is something that should be considered. However, I’ve never come across a mock-up were its been an issue translating it to something with dynamic font, screen, etc sizes. That is normally something that can done after on the development side considering some level of consideration on the designers end. Though in the end a well designed, complete static mock-up is normally enough to make the other, technical decisions regarding window sizes, different font sizes, different OS settings. In the case that there is an issue than I just modify the design a little myself to account for said requirements. I haven’t really worked with anyone were it has been a major issue. I’m sure it could be if your not working with the right people though, I guess.

“pixel perfect” is probably the wrong term for it, though commonly used like “div based” or “tableless”. The goal is never pixel perfect replication but consistent proximity, colors overall look and feel given the viewing environment. I’m sure we all know that, but “pixel perfect” is the term everyone seems to use, job ads love it!

Which is the point of contention – if they don’t take those into account in the design, how are you supposed to implement them later without destroying the design completely.

It’s like the people who are PSD geniuses but at the same time brag about “knowing nothing about HTML, CSS, WCAG, etc” (and there are some photoshop sexperts who actually BRAG about that)-- which basically boils down to "then what the blue blazes business do you have ‘designing’ a website?

pfft… designers. It’s like having an artist draw a picture of a building then handing it off to an architect and saying “make it look like that”… when the architect comes back with “we’ll have to use exotics, you’ve got a 30 story building that can only hold 20 people, and you’ll be lucky if the structure stands for ten years and doesn’t light the building next door on fire”.

See that artsy museum (texas I think) with the convex mirrored walls. Yeah, that’s just brilliant. Too much artisanship and not enough engineering and craftsmanship.

Great software follows patterns, but patterns are design cliches – its a struggle.

I never start a design with an image program because I alway have a basic CSS outline in mind and the mock-up very rarely suits it. I treat webpage’s like jigsaw puzzles, you have areas of a website that are (usually) always present so I design graphics to suit those areas and not the other way around.

Graphic Designers are lazy ppl who often send a flat image with no idea how they will be placed within the site. It has to be flexible, it should start with a backbone.

DOH, no sleep in 30 hours. CONCAVE mirrored walls. CONCAVE…