It’s time to think about the way we’ll structure our design—so grab your paper and pen and get ready to doodle.
Let’s make the most of our nice paper medium. First, let’s make some loose sketches. And if you end up drawing characters and swirly lines instead of actual diagrams, that’s fine too; if you feel like adorning the page with drawings that come from thoughts about events or events’ web sites, feel free.
Remember, keep it loose.
Once you’ve warmed up your pen (and your brain!) it’s time to start thinking about the way certain parts of our site will work. At this stage, it’s unnecessary to worry about everything fitting neatly together; the idea is that we look at the overall picture before concentrating on precise details.
Some sketches for a recent project
Sitemaps
You might have seen a sitemap on a web site—it’s a list of many of the pages you’ll find on that site. At the design stage, however, we’ll use a sitemap as a way to draw our web site’s structure like a map. But instead of thinking of them like a map that portrays the elements physically (like on an atlas), imagine them as a description of the way the pages link together. It’s good to get a sitemap drawn before leaping into the design, because it gives you an understanding of how the site will work.
Initial Sketches
There are probably a number of ways to go about sketching a sitemap, but you might find it useful to write down the name of a page, draw a circle or rectangle around the word, and then use arrows to link it to other words. In the illustration below, you can see a loose, sketchy sitemap for Web in the Wild.
Getting some ideas down on paper
Web site pages rarely exist in isolation, and so there are often various ways (through different pages) to reach the same page. For instance, on our site’s Schedule page (above), there’ll be a listing of the sessions happening at the event which will include the speakers’ names. Yet to access more information about each speaker, the names will be hyperlinked back to their profiles on the Speakers page. Likewise, there’ll be links from those profiles back to the sessions. This demonstrates that there are more ways to reach the pages than by just using the main navigation bar.
Sitemaps Versus Navigation
One thing I’ve struggled with in the past is the difference between writing down a navigation list and a sitemap. In essence, you might think that they’re similar; after all, a navigation list is a list of pages on the site that the user can reach by clicking on the navigation items’ names.
But what if you have a page like a legal notice that’s pointless to display on your main navigation? Perhaps you might want to just keep it for a footer-based navigation bar? In that case, there’s no way to tell that it’s there unless you start with your sitemap first.
Another scenario is that you might have pages that are superfluous to any kind of navigation bar at all. This might sound strange at first, but imagine you have a sign-up form that allows users to receive your email newsletters. You’ll probably want to have a thanks or success page that appears once they’ve successfully signed up; so that needs to be considered in the sitemap, even though it will never appear in a navigation bar or any kind of sitemap you show to users—this is just a sitemap for you, and for the people planning the project.
If you’re planning out a process that happens without actually moving between pages (for instance, you might have a registration form that updates its contents using Ajax), it’s worth creating separate diagrams to describe these processes, since it’s potentially confusing to draw separate pages for this concept.
The important thing here is that it makes more sense to decide on your sitemap before your navigation, because you need to decide how the site fits together as a whole before deciding how it’s navigated by your users.
Finished Diagrams
Once you’ve sketched through a few ideas and have settled on a sitemap concept you’re happy with, it’s a good idea to tidy it up. You could start by drawing a neater version (if, like me, your early sketches and notes are extremely rough!), or you could use some kind of visual editor to orderly display your ideas.
Applications like Microsoft Visio, OmniGraffle or ConceptDraw MindMap are popular tools to use, or you could simply use whatever tool you’re comfortable with: there’s nothing wrong with producing a sitemap in Photoshop or Illustrator.
I’ve recently started using WriteMaps, a simple online tool for creating and sharing sitemaps. I like it because you can create a reasonably good-looking sitemap in seconds, like the one you see below. Although it lacks the full functionality offered by desktop drawing tools, it more than makes up for it in ease of use. WriteMaps also provides you with a URL for each sitemap you make, which means it’s extremely easy to share them with your clients or colleagues; plus you can export them to XML files if you need them later.
A sitemap created with WriteMaps
A finished sitemap
Some events sites have separate pages for sponsors, social networks, past events, and the like. For the sake of Web in the Wild, we’ll keep it fairly simple and use only a small amount of pages.
Wireframing
Sitemaps deal with the structure of a web site; wireframes deal with the structure of individual pages. In a wireframe, we sketch out each page to try out different visual placements for each element.
One of my initial ideas for a layout
When creating a wireframe, what we’re doing is thinking about how the elements work best on the page. We’re considering which elements should be given prominence and how they best relate to each other.
Ways to Give Weight
There are various ways to make aspects of a web page prominent. Giving weight to an element can often be achieved using contrast (how it stands out from its surrounding elements), style (how it conforms to conventions, such as a certain look for links), and proximity (how it relates to nearby elements). In the illustration above, you can see how I’ve marked out a fat black box in the navigation panel to indicate a highlighted button marked “Buy”—this is where I’d like the Register button to go.
For now we’ll focus simply on the placement of elements on the page. Of course, if you have any ideas right now about which elements ought to stand out, you should point these out in the sketch.
Our Checklist
Before we start sketching out some possible layout ideas, it’ll help to list the elements that are going to appear on our pages.
Global Elements
Some of the most important elements should appear on every page. Let’s make a quick list of these first:
- sponsor logo
- event title
- date
- venue
- navigation
- Register button
We can group all of these elements together in a header area. In fact, we can safely group the date and venue information into a kind of subheading within that header container.
What else should appear on the site? Let’s think about elements that should be on every page for now; that is, elements that will be in every template we design.
- secondary navigation
- contact details
- newsletter sign up
As far as we’re concerned for our site, these are the only aspects that need to appear on all pages. We’ll combine these into a footer area that will appear at the bottom, with the exception of the newsletter sign up: its position will vary from page to page. The reason for this is because we want it to appear on every page to increase the chance of people signing up, but we want to avoid it being shoved in their faces! Moving it around will help keep it looking fresh and prevent users feeling like theyfre experiencing a hard sell.
The Homepage
Like many sites—and in particular, events sites—our homepage will contain very little content. Instead, its focus will be on enticing users into the other areas of the site. It’ll serve as an introduction to the rest of the site and offer bite-size chunks of tantalizing information to the visitor. Underneath the header, we want to advertise these three important elements:
- featured speakers
- a brief introduction to the event
- a bit about the venue
The information below these three boxes is less important (well, depending on your viewpoint, perhaps), so it’s safe to assume that it’ll appear further down the page.
- information about the after party
- sponsor logos
The Schedule Page
- brief introduction
- table showing session schedule
The Speakers Page
- speaker bios and head shots
The Venue Page
- address
- travel info
- accommodation info
- photos of venue
The Party Page
- introduction
- party venue
- travel info
- sponsor details
The Registration and Tickets Page
- ticket types with price breakdown
- option to select ticket type
- contact details for assistance
When you have a clear idea of what needs to be on each page, it’s time to start sketching them out for real.
Other Sites as Wireframe Sketches
If you’re new to wireframing or find it hard to see its relevance, I’d encourage you to sketch rough layouts of your favorite web sites. It’s about stripping off the pretty part of design and taking a look at the relation of elements on a page. For a real-world example, below are a couple of sketches I did of two existing events sites—FOWA Miami 2009 and Drupalcon DC 2009—alongside the finished results. You’ll notice that even though the two sites have very different looks, the basic components—as well as their placement—are quite similar.
A wireframe for FOWA Miami 2009
Drupalcon DC 2009
The Sketches
Label your sketches as you go, as it’s surprisingly easy to forget what your various shaded boxes represent—especially if there’ll be a lot of time between sketching out your first ideas and constructing a firmer wireframe.
Let’s take a look at the illustration below, a sketch of our homepage in rough form.
Our homepage sketch, in rough form
The Basic Template
It’s time to start tidying up a bit and creating a more solid wireframe: one that’s more presentable to clients, clearer to work from, and closer to the final product. Since we need it to be neat and clear, it’s finally okay to sit down with your computer! But take it easy: we’ll still be sticking with plain representations of the layout at this point.
Instead of concerning ourselves with every element on the page, let’s first focus on the core elements of the header and footer. We can use this as a basis for the wireframes for all our other pages. The illustration below shows a tidier wireframe.
A tidy wireframe
The Final Pages
With our basic template sorted, let’s look at how the content area changes with each page. Dimensions and measurements are inexact right now: we’ll finalize them when we start our layout in Photoshop (due to printing constraints, the text is left out of the header and footer areas. The wireframes I’d give to my client would contain the text.)
Mix It Up a Bit
I really dislike web sites that retain the exact same look throughout all of the pages. Sure, consistency is extremely important, but sticking rigidly to a template without any room for customization outside of the main content area can quickly make things seem a little boring. We’re all guilty of doing this to some degree, of course, but for this project I’ve chosen to add a little variety into the mix by varying the layout of the central elements between some of the pages. After all, even with a template system, we can still create a dynamic and interesting site.
The homepage (left) and schedule (right)
Speakers (left) and party (right)
Venue information (left) and registration (right)
What Now?
We’ve constructed a kind of blueprint for the templates we’ll build later in our project. Hopefully you’re feeling much more confident about the creation of the design now that we’ve planned things out with these wireframes. Essentially, we’ve already made some of the toughest decisions. From here on in, it’s going to be about turning the skeletal structures above into a living, breathing design.