It’s a great big (wide) world... but who’s really out there?
So you’ve got your nice shiny XHTML and CSS diploma hanging on the wall, and the prospective clients are ringing your new business line off the hook. Cool, right? Yeah... until you get your first complaint about a bad layout, or a logo that’s just so 1998. So how do you create really beautiful websites and still make sure they satisfy your users? It all begins with good planning. Then you’ve got to write for the Web, know your audience, and, above all else, make sure you’re designing for your users, not yourself.
Jane’s just bought a small web design studio. Red Lantern Design’s been producing small sites for local businesses for several years, and now Jane wants to expand their client-base. But there’s a problem...
The old Red Lantern webmaster used a WYSIWYG editor to create the company’s own site, and now no one can edit the files. Jane’s hired you to build a new site that will bring Red Lantern up to modern web standards and bag the company more lucrative clients.
Well, sure you can. Where do you think you should start?
There’s not a lot that’s good about the existing Red Lantern site—the logo’s nice, but that’s a pretty damning comment on the rest of the design if that’s all there is to like. But if there’s so much wrong, how can we figure out what to work on next? Where would you start?
The fact you’re still asking yourself those questions without opening a text editor is a good sign. The answer to both is, always follow a design process. A design process structures your project so that you stay on task and don’t go off in every different direction all at once without accomplishing anything but stress, stress, and more stress.
A process is really just a workflow that determines the order you do things on a web design project. Imagine you’re building a house for someone. It’s their dream home, they’ve got a ton of ideas on their wishlist, and you also need to include the usual things you’d expect to find in a house: walls, floors roof, kitchen, bedroom, bathroom, living areas...
Now ask yourself where you’d start? Would you build the walls first? Would you pick out fabrics, or draw up a blueprint? Which one is going to pay off two weeks from now? Two months? Two years?
So building a website is a lot like building a house. If you start with a blueprint, you’ll know exactly where you’re headed at every step: foundations, load-bearing walls, and so on. For a website, you use Information Architecture (or IA). IA is the process by which you break your website’s content into chunks and then organize those chunks hierarchically in relation to one another in a way that’s logical.
Most of the time, each chunk of information is content (text, images, etc.) that lives on a single page. IA is also closely linked with building your site’s navigation. So, if you’ve got bad IA, chances are, you’ll have a bad navigation system as well. If your site doesn’t have solid IA, it will feel disorganized and confusing to users. And that will make users go someplace else to get what they’re looking for.
What content do you have for the Red Lantern site? How will you order it? Will you need any more material?
Will that be enough to help your users find their way around the site?
You need to think about navigation twice in the design process? First, you need to think about your navigational elements—yes, things like buttons and nav bars—while you work on the overall layout of the site.
Navigation will show up again when you begin writing the code and building the layout elements that have to do with users finding their way around the site, as well as linking your pages together. But don’t jump the gun, you need to start by organizing your top level navigation.
Information Architecture isn’t just important for organizing your site’s information; it’s a big deal for your navigation as well. So, when it comes to building your site’s navigation, keep your IA diagram close at hand.
Top level navigation is usually the most prominent navigational element—the tabbed nav bar at the top of the page, the vertical nav menu in a secondary column, etc. More often that not, your top level navigation links to those sections one tier below the home page in your IA diagram.
The point of the top level navigation is to show your users where they are within your site’s main structure. We’ll come back to navigation in a lot more detail in Chapter 6, but for now, you need to ask yourself how you’ll style the menu on the Red Lantern site. Time to start thinking about which menu type would suit the site and where it would fit on the page.
Having a clear idea of where you want to put the building blocks on screen saves valuable development time.
It’s much quicker to sketch a few designs on paper and get Jane’s reaction before you start than it is to waste time working up the code for a bunch of designs when she can only pick one...
Your first sketches should be black and white and drawn on paper. That way, Jane will be completely focused on the basic layout of the design (instead of what color the background of the page is or how great her logo looks placed over that image or... you get the picture).
Your designs should show Jane some basic layouts with the content she’s requested in various configurations on the page. The sketches should make Jane ask herself questions like: “Do I want a large image at the top of the page?”, “How many columns do I want?”, “Where should the menu go?”, and so on.
Frank: Nope. We’re going to stick to pen and paper for now. What do you think about adding some color to those sketches?
Jim: Why would I do that? Can’t I just get going with the code and test different colors using CSS stylesheets?
Frank: Well, this way, you get a chance to see how colors interact with one another, how interface and layout elements play off one another once they’re in color, how your navigation system looks in relation to the rest of the layout, and generally whether content’s represented in the best way possible.
Joe: Wow. That sounds like a tall order for one little sketch. Couldn’t we just have shown Jane a few color versions instead of going with the black and white sketches?
Frank: Clients can get distracted by color too early in the process. It’s best to show them something that gives them an idea of the functionality of the site—
Joe: —before we start on the look and feel part of the design process. I get it. The sketches provide us with a painless way to catch any potential design problems before we start coding our design, and they become major obstacles.
Frank: There you go. But we’re not just doing one sketch here, Joe.
Jim: —No. We’re going to do a ton, all in different colors, and show them all to Jane like we did with the first sketches, right?
Frank: Kinda. What we’re actually doing is creating storyboards to test a few variations. We’ll show Jane the best one or two.
Jim: Wait. What?
Frank: Yeah, these are like the storyboards—you know, that sequence of little sketches that look like a comic strip—the film industry uses to test out shots before rolling the cameras. We’re doing the same thing. Here, let me show you a neat trick for creating good storyboards.
Building a prototype in code has some great advantages. First, even though your design might look great on paper, it might not work (technically speaking) when you code it up. The prototype will give you an opportunity to quickly fix anything (code-wise) before you invest too much time in building a polished finished product.
Also, if you’re working with clients, a code prototype gives you something to show them, and just like your storyboards, you can get useful feedback and make iterative changes.
All the awesome design work, storyboarding, and prototyping in the world is not going to save your site if you don’t have any content (or if the way you present your content stinks). So how will you ensure your content’s interesting?
Writing for the web is different than writing for regular print.
Instead of reading your content from left to right, beginning to end, like a book, users scan the text for keywords and concepts—to give them an idea about the contents of the page.
When you combine this with the fact that users generally don’t spend that much time on individual pages, you know you are going to have to write differently. The word of the day is scannability!
So how do the two versions of Jane’s site compare? Every site’s ultimate aim is to communicate something to its users. If your website doesn’t communicate what you want it to, your audience will go to another site looking for the experience or content that you couldn’t give them.
This is known as User-Centered Design. When you build a website, you’re building it for your users, not for you. You design for your user’s strengths and weaknesses. You want to use every technique possible to bring users to your site, help them find what they’re looking for, make sure they have a rewarding experience, and keep them coming back.
The process you followed in this chapter—
Pre-production. using Information Architecture and storyboards to build a blueprint for your site so that you’re as efficient and focused as possible when you go digital.
Navigation. is based on your IA diagram. It’s more than just linking pages together. Navigation helps your users find information.
Layout. uses HTML and CSS to build the site’s interface (which you already came up with on paper back in the pre-production phase).
Writing. “fills” the design up with the scannable content that your visitors come to the site for.
—had just one aim: to produce a great-looking site that tells users all about Red Lantern Design.