Web design is both art and engineering, and you must attend to both disciplines to create successful Web sites. If a site is gorgeous but unusable or broken, then it will not be used. If a site is useful but dull, it will not be used except by the most dull of people (unless you have a captive audience). The right balance between style and substance will vary, depending on what kind of site you are building.
This section describes different aspects of the Web site design process, including:
- Approaches to Design : describes some different ways of going about the design process.
- Design Principles : discusses some useful design principles.
- Designing and Building a Web Site : how to go from an idea to a working Web site.
- Gathering Requirements: figuring out why you want to build it, who will use it, and what the site must do to be successful.
- Designing a Site: creating the look-and-feel and specifying the necessary functions of your site.
- Building a Site: turning your design into a tangible site.
Approaches to Design
Designing a Web page is very similar to designing software in certain ways. Many different approaches can work, and so you may have to experiment to see what works best for you. There are many ways to accomplish the same effects, and so there is room for personal preference and style in how you build Web sites. These definitions of different design methodologies are not hard and fast, but they are practical. Most likely, the end result will be a mix of these techniques!
- Storyboards and Wireframes: A purely informational, architectural schematic that shows major content placement, primary and secondary navigation, and light functionality. By putting all page elements down on paper, you can see what you’re designing before you start the visual design phase. Plus, looking at wireframes in relation to each other (interactive wireframes) gives you an idea of page flow. A Firefox extension called Pencil allows you to create user interface diagrams and drawings, and save them as images. I have not tried it, but it might be useful.
- Outlines: Hierarchical decomposition of the domain. This kind of categorization is more about analysis than design, but it will guide the design process:
- Makes finding info faster and easier.
- Divides info into smaller, easier to digest chunks.
- Emphasizes the similarities between info, and therefore helps point out the differences between info.
- Provides “paths” to information.
- Another approach is Mind-Mapping. This visual outlining approach appeals to visual thinkers more than a typical outline, but it is conceptually the same. Look at the free tool Freemind to see if this approach would be good for you. Mind42.com has a Web-based Mind-mapping tool.
- Rapid prototyping: Create a rough design for the site. Hack out some variations, then iterate over the promising approaches. Continue until you’re happy or you run out of time (the most likely scenario).
- Incremental development (design and implementation) as methodology. The Web is not like paper: everything can—and will—be changed after it is first published. The basic idea is to rough out the pieces of the site, and then systematically expand the various sections until you’re done. You can easily change a page or a style sheet or a template, and simply update whatever has changed.
- Create an “impression” of something you like as a drawing, possibly combining things you like from different sites as a starting point. Develop the site from that point using whatever methodology suits you.
You don’t have to design the entire thing before creating anything. As you gain experience, you’ll develop a design methodology that works for you. In the beginning, it will be helpful to be as structured as possible: write out the layouts, color choices, page names, etc in your design for reference as you design and build your site.
Starting with a Blank Page
Here is a process for systematically going from a blank page to a Web page. All Web development is incremental, so you start with the blank page and keep adding stuff until it looks like what you need. I encourage beginners to keep checking your work after making baby steps, instead of doing a bunch and then checking. If you check it often, you’ll catch errors before they cause other things to break.
- Design your desired page layout, and decide what the main boxes are that make up that layout.
- Create the starting HTML page by copying the Canonical Page template.
- Define the main boxes for your page layout, such as header, navigation, content, and footer.
- Define classes in the <style> section for each of those boxes. Each class is assigned a name that you make up, based on what the box is going to contain. Make the style definitions empty initially, using the curly braces. To make it easier to see what you’re doing, you can apply a background-color and a border to each DIV, so that you can clearly see where they are.
- Define DIVs in the BODY section for each of your boxes, and assign the class names you’ve chosen for each box.
- For each box in your layout:
- Insert the "raw" content into each of the boxes.
- Begin to apply CSS styling to your boxes using the class names you’ve already defined.
- Position your boxes where you want them to appear on the screen.
Starting with a Template
Another way to get started is to pick an example layout from the many examples I’ve given you. Start with a template where the main boxes are laid out the same way as called for in your design. Simply change the names of the classes to match how you’re going to use them, take out any styling that you don’t want, and add the styling that you do want. Since the boxes will already have the basic positioning, you can simply add your own content to the boxes, and tweak the positioning to be exactly what you need.
WYSIWYG vs Code View
Web pages are just text files, so you can use a plain text editor. All of the HTML formatting is created with textual markups of the underlying text, but the markup is itself text. The cleanest code you’ll ever see is hand-written in a text editor — most HTML code generated by WYSIWYG (What You See Is What You Get) systems is bloated and poorly formatted. A text editor knows little or nothing about the domain, though, and so can do little to assist you (highlighting HTML syntax; validating your code) with creating HTML code.
- Macintosh: TextEdit comes with current versions of OS X. If you don’t find it in the Dock, look in Finder > Applications. It can open and display PC docs such as MS Word. It can save files in these formats: rtf html doc xml.
- PC: Notepad or Wordpad can be used to edit all text files, including HTML files.
Here are some design principles that you can use to guide your own design process.
- Design for the target audience, not yourself. Consider such factors as age, sex, experience level, and user expectations when you design your site. You must also consider which Web browsers will be used by your target audience, so that you can manage the differences gracefully.
- The Web is not Paper! Embrace the differences, and go with the flow. Basically, you will find the easiest flow if you specify the widths of things, and allow the heights to be determined by the Web browser. Be aware that users can override many of your design decisions, too, which suggests the need for flexibility that is not needed on paper. The browser and computer environments for users vary so widely that you must take this into account. There is NO reason that a site can’t work well with all browsers. Pixel-perfection leads to madness.
- Create a clear visual hierarchy. In virtually all cases, the choices should be instantly apparent to people. People have expectations about what happens when they browse the Web, so don’t break conventions lightly. If you are determined to “break the rules”, at least understand them first. Do preliminary designs using a grid. Consider the white space as an element. Treat text as a graphical element.
- Take away the boxes. While the underlying layout is composed of a group of rectangular boxes, your layout does not have to look like it. You can make portions of images transparent. You can use images as backgrounds for any HTML element in the BODY of an HTML page. Use gradients to minimize blocks of smooth color. Don’t use high-contrast backgrounds unless you want the block to stand out. Minimize the use of borders around boxes, since they emphasize the blockiness. Use rounded corners on boxes to smooth things out. Don’t position all of your elements on a symmetric grid (but there’s a fine line between looking artsy and looking amateurish or dumb, so be careful).
- Organize logically for the domain (not for historical reasons; your visitors will probably know the domain, but are unlikely to know the history): alphabetical; chronological; geographical; task-oriented; topical (hierarchy of topics); visitor-specific (i.e., men vs women); numerical (such as pricing data); continuum (according to a value scale or rank); existing standards (like ISBN).
- Pay attention to Navigation. Make your navigation consistent and visible (but not overwhelmingly so). Keep people oriented using breadcrumbs, site maps, descriptive links, titles, or whatever works—it’s easy to get “Lost in Hyperspace”!
- Usability: What will the intended users expect?
- Follow conventions where it makes sense—don’t intentionally break common practice without reason.
- Make it easy to read and scan.
- Avoid long line lengths—no longer than 50-60 characters per line.
- The most common layout on the Web today is a fixed-width box (usually 780-980 pixels wide) that is centered on the page.
- Use the 7 plus-minus 2 principle, or not.
- Minimize (visual) noise (in most cases). Omit (unnecessary) words.
- Resist specifying heights. You’re almost always better off planning the horizontal space carefully, and letting vertical space expand or contract as needed. Fixing heights leads to errors when the content overflows the expected size (such as when the user enlarges the font size in their Web browser beyond what you expected). If you must specify the height, then specify what happens if the contents overflow the box (truncate; add scrollbars; overflow).
- Pay attention to use of Color. Colors have symbolic associations that contribute to the "feel" of a site. Some people are color-blind. Many color associations have a cultural basis, and the typical associations listed here probably reflect a Western bias.
- Red: Vibrant, passionate, love, war. A very strong and attention-grabbing color, red is charged with emotions.
- Violet: regal, sacred, sensual. In deep shades, violet is luxurious. When lightly tinted, it is aromatic and spiritual.
- Blue: Cool, dependable, sophisticated, sky, water. Blue is full of depth, constant yet dynamic.
- Green: Fresh, relaxing, earth. Green is very balanced and calm, a natural color.
- Yellow: Sun, energy, warmth. Yellow is welcoming and full of life, a happy color.
- Orange: Strong, vital, hot. Orange is the warmest of colors, a healing and playful hue.
- Symbolic meanings are attached to shapes (from Molly Holzschlag).
- Rectangle: rectangles and squares typically represent authority, stability, and strength. Many designs attempting to convey reliability and consistency will use lines, rectangles, and squares.
- Circle: circles and curves typically represent community, fluid movement, and the feminine.
- Triangle: triangles represent action, movement, and direction, and are associated with the masculine.
Regardless of the size of your site or the design methodology you use, the process of creating a Web site can be broken down into several discrete phases:
- Gather Requirements: in the first phase, you seek to understand why the site is going to be created, who will be using, and what kinds of functionality are required.
- Design the Site: in the second phase, you turn the requirements into an actual design that covers the functionality and look-and-feel of the site.
- Build the Site: in the third phase, you turn the design into an actual Web site.
The design process for commercial Web sites follows the basic model here, but it includes a lot more detail about design choices, and puts more emphasis on what happens after you launch the site.
Gathering Functional Requirements
Here is where you answer the big questions about your site: What’s the point? Who’s it for? What must it do? This is the process of gathering functional requirements—analyzing your goals for the site, and determining what is required to achieve those goals. Write this down!
- Why are you building the site? What’s the purpose? Are there multiple reasons for building the site? Do these reasons conflict?
- Who is your audience? What kinds of tasks will they perform on your site? What experience level do they need? What is their typical viewing platform? Define your typical audience: young, mature, male, female, rich, American, educated, liberal, religious, whatever.
- What functionality do you need? Figure out anything needed beyond the static display of HTML pages. Can you actually build what your design describes?
- What kind of content will your site need? Where will you get it?
- What kind of look do you want?
- Look & Feel: color palette, layout (width; fixed vs fluid), fonts, images.
- Identity / Branding: headers and footers. Common look-and-feel across entire site. Common graphic elements.
- Navigation Style: Menus / Tabs / Buttons / Words / Imagemaps. Home page can be different from rest of site.
- What is the intended (emotional) feel of the site? Prestigious, Friendly, Fun, Elegant, Corporate, Forward-thinking, Innovative, Cutting Edge, Classic, Familiar, Sophisticated, Elegant, Casual, Serene, Subdued, Edgy, Flashy, Formal, Powerful, Romantic, Sensual, Clean, Professional, High-tech.
The better you understand the answers to these questions, the more likely that the site you build will meet your goals.
Design/Development emphasis is a personal choice. Look, style, functionality, breadth vs depth—these are your decisions, and there are no wrong answers.
Creating the Design
This is where you actually create the design for your site: how it is laid out, what it looks like, what functionality it provides to viewers. Here are factors you must consider in your design:
- What is the overall layout? Define the top-level conceptual boxes for the page: header, footer, content, sidebar, menus, whatever. What is the target width? Is the design fluid or fixed? Centered or justified?
- How does the navigation work? How do people get from one page to another? How do they know where they are at all times? How will you create the navigational mechanism?
- What is the Look-and-Feel of the site? Overall emotional feel; colors; fonts; relative sizes of elements; amount of white space; animation. Consider product or customer branding. Mock up your ideas, whether on paper or in a graphics program or in HTML. Create your palette of colors, and look at them on the screen. Is the look-and-feel appropriate for the audience and the site goals?
- What graphics are needed for the site? This includes images, backgrounds, icons, and favicons. Will you create or acquire these graphics? How?
- How do you address the Functional Needs that were identified in the requirements phase? Does your design rely on providing functionality beyond standard HTML? Examples: accepting payments; collecting email addresses for a newsletter; user forums; viewer comments; auctions. Make sure that your design can actually be built.
- Will your pages be static HTML, or will they have to be dynamically generated? Example: blogs (like WordPress and Tyepad) create HTML pages on the fly by formatting data that comes out of a database. E-commerce systems create product pages by reading product data out of a database, and then creating the HTML to display it. I strongly urge people to build a static site for their project; don’t get in over your head unless you know what you are doing. 🙂
- Does the site need to reflect product or company branding?
- Where will you get the content? Identify the sources before you start, to make sure you can actually get what you want.
- Map out all of the pages on the site. Do this in a way that lets you keep track of the status of individual pages. Identify the purpose and content of each page.
- Plan out the task of building your site. Assign priorities and time estimates to your top-level tasks.
You can capture the answers to these questions in a variety of methodologies; see the discussion here for some choices. If you define the answers well, the process of building the site will be much easier. That is not to say that you must design everything before you can build anything! Regardless of how well you design, you will usually end up adapting or modifying the design before you finish (because something didn’t work, or because you don’t like it after seeing it, or because you can’t actually build what you designed). Some of this is OK, but it can really slow you down to rethink or rework everything as you go. Design time is not wasted!
Building the Site
This is where you actually turn your design into a real site—where the rubber meets the road, as it were.
- Lay out the main boxes of the page using CSS to determine position.
You can either do this from scratch, or you can use an example layout as a starting point.
- Starting from Scratch: Clone the Canonical HTML file. Create boxes (DIVs) that represent the main content areas of your site’s pages. Create a wireframe layout that shows the content boxes, using CSS to position the main boxes. Once you have a workable cross-browser design, then shift your CSS declarations to an external file. Finally, embody your HTML in a template that provides a starting point for creating all of the content pages specified in your design.
- Clone a Particular Layout: identify one of the many examples of CSS-based layouts. When you find one where the main blocks are similar to your proposed design, clone that HTML and any associated CSS. Since many of the examples are loose about adherence to standards (even using antique doctypes), your best bet is to clone the canonical HTML file, and then fold in the HTML and CSS from your preferred layout. Once you have a workable cross-browser design, then shift your CSS declarations to an external file. Finally, embody your HTML in a template that provides a starting point for creating all of the content pages specified in your design.
- Create the site stylesheet based on your layout, color palette, and other design decisions.
- Create any necessary graphics using the chosen colors: buttons, backgrounds, and ambient pictures.
- Identify the answers to all functional needs. This may include the need to import content from an older version of the site.
- Gather all content for the site.
- Create individual pages using the template, and add the content to the pages.
- Test your pages in multiple browsers. All browsers have variations in how they interpret the standards. The least observant browsers are the different versions of Internet Explorer, but these also comprise the majority of browsers in use. Therein lies the rub. If you don’t have access to the major browsers for testing, you can use a service like Browsershots.org to see how your design renders in a huge array of browsers and versions.
- Test everything—not just browsers! Are your graphics the right sizes and colors? Are there gaps between elements? Do elements overlap? Is there enough contrast in your colors for reading text? Is the spelling correct? Do all your links work?
- Register your domain name, and locate an ISP for hosting the site. Arrange for any services you need, such as PHP or MySQL.
- Prepare your site for the search engines:
- Structure your code properly.
- Fix any broken links or images.
- Implement some flavor of Web analytics.
- Create and register a sitemap.
- Register your new site with the main search engines.