I can only think of one for sure sign that you designed your web page well.

When the users do not even notice the design of the web page then you know you designed it well.

This needs some explaining I guess. If the user has to think about the design of a site at all you did a bad job. This is true even if the user thinks, "I like this design". Your design should be so nice and smooth that everything just flows and the user does not even notice the layout or colors or anything visual about the site, except the content.

also...

When a user goes to your web site everything should be where the user expects it to be. In the back of all of our minds when we go to find a button on a web page we all expect it to be in a certain place. This is true even during your first visit to the site. In the history of the Internet certain standards have developed, side toolbars, top toolbars and such. If a user goes to look for a button and can't find it you did a bad job designing your site.
This node isn't for HTML, XHTML, XML, CSS, or any other markup language: it's for advice on what looks pleasant. For example, the fact that bright pink and luminous green aren't a likely combination to be seen worn on the street, due to the fact that most people dislike them when in combination with eachother (or so I've been told.). The same principle applies with web pages: if you happen to use foul colours, fonts, and bad layouts, people don't like it, and that decreases your chances of people visiting your page.

Making pages that're downright hypocritical is bad too. For example, if you were to buy a shirt which has the words “Capitalism sucks” on the front, and yet you shelled out $30 on it, that would defeat the object of the shirt. A similar concept would be making a lovely graphical page to advertise a textual game, such as a Multiple User Dungeon (MUD for short), or a normal Text Adventure (Also known as an “Interactive fictional program”). This would be hypocritical due to the textual nature of the games being advertised by fancy graphics, which have absolutely nothing to do with the content whatsoever. Trying to lock the design in with the content is essential, as this either emphasises the content's message, and is often seen as more friendly than badly formatted tables or slightly off subject graphics – or indeed, badly made graphics.

Colours that're similar are generally good: various shades of blue which go together (usually darker for the background, lighter for the foreground/tables/mouseovers and so on). If you as the designer enjoy just looking at your page, you may well be onto a winner.

Last but not least, however, has to be the markup you use. Invalid markup is awkward for some: sure, maybe the majority of people who will/have viewed your page will use a browser that can handle the occasional tag not ending and so on, but there are always browsers that won't enjoy (I.E., will crash) rendering bad tags. Admittedly this is rarely HTML, but usually Javascript, CSS, or something along those lines, but it does happen. One example I myself have encountered is the problem with opacity on various browsers: Internet Explorer will render opacity and not crash – though it will run badly, it won't crash. On the other hand, Mozilla for example, should it be the “wrong kind” of opacity, will crash upon navigating around a site – as I say, I myself have encountered this problem, so I would know.

Note: to any americans reading this, excuse my British spellings such as “colour” (as opposed to “color”) and so on.

As a web designer and developer, I always enjoying reading articles about how other people start designing or developing. Sometimes I incorporate their advice and methods, other times it's more revolutionary and I'll try their method and come up with something new. So, I thought I'd put some effort into explaining how I, and other designers I've worked with, start designing web sites.

Discovery phase

First of all, I write out what the site has to do, and what it shouldn't do. If the site is for a client, this is something we discuss together. This is the site mission statement, and it helps keep everybody focussed.

Next, I'll look at the content and work out a framework to contain it. Perhaps there will be areas such as Products, Services, etc. Or perhaps it will be more free-fall or interactive. If you've not heard the saying before, here it is; "Content Is King". Anyone that tells you otherwise should be shot.

As with any new product, I'll have a look around the web for competitors and see how they do things. Sometimes you can see weaknesses in their site that you can take advantage of, other times you might see something you've missed. Asking why a competitor has done something a particular way, can be a great help.

By the end of the discovery phase, I'll have a rough framework which I can build on. Some people find this phase the most difficult - a little tip though: if you think about what you want to achieve, and try not to think about the technology involved, your finished design will be much more impressive.

Exploration phase

With the framework taking shape in my head, I open a notebook (yes, that's right, one with paper in it) and scribble for hours - or sometimes even days. Related words, phrases (sometimes I overlay these on images to create part of a sub-header), sketches, concepts, animations - you name it, it all goes in the notebook. I may even note down relevant colours or fonts that I've seen in a magazine, book or on TV. I'll also be considering roll-over effects, formatting, layout, etc. Anything that looks interesting goes in the notebook and until I've finished the exploration phase, that note book doesn't leave my side.

While I'm sketching, I often doodle "web page boxes" - little rectangular boxes which I divide up into parts of a page. Sometimes I make lots of these empty boxes in Word and print them off so I can doodle in them. They're a massive help when trying to visualize headers, footers, columns, gutters, etc. If you've not had any previous experience of designing with these concepts, I'd recommend reading up on them first.

Once I've got some ideas of layouts, I'll start to think about images. Sometimes I'll include these in the header, other times they'll make up part of the page design - although I try to avoid this kind of design because it can detract from the content too much. When choosing images, I almost always edit the image before I use it - just to make sure the overall colour and levels are right, it's sharp (or blurry) enough, and to make sure the file size is nice and tight.

Next, I'll start to put the layout together with some stock Latin text. At this point, I'll go hunting through my archives for some fonts that fit the design. I've got around 12,000 fonts in my archive and a handy little program which helps me browse them, called FontLister. Typography can make or break any piece of design, and it's important to remember the rule that you should never use more than three fonts on one page.

Prototype phase

All of the elements are coming together, so I whip up a couple of small prototype sites. For this, I'll be using Macromedia Dreamweaver (an HTML editor with knobs on), TopStyle (a sexy CSS editor), Adobe Illustrator (Fireworks is just so Microsoft Paint, man) and Adobe Photoshop (because it's a must). While I'm still thinking about how I want style sheets to work with the design, and how I'll be using ASP, ASP.net or PHP to code the site, I'm only building a prototype. Meaning it will be something that looks fantastic, but doesn't work and certainly won't ever be used as a code base for the finished version.

Implementation phase

Once the prototype phase has been signed-off by the client, or I'm happy that I like the way things are going, I'll start building the site for real. Right from the word go, I'll be converting my layout into style sheet structures and testing it on my PC, a Mac and a variety of browsers. When I'm finished (or at least pretty close to finished), I'll hand it over to the developers (or I'll start developing it myself) and then I'll tell them off a thousand times for using HTML tables. Grr.

Conclusion

So, as you can see, a lot of thought and effort goes into designing a web site. And I haven't mentioned anything about clients that don't know their browsers from their arsehole. Or a 14 year old kid in their bedroom - who is, of course, a designer. I hope this writeup is interesting to others and any constructive feedback is welcome.

Log in or register to write something here or to contact authors.