Wednesday, February 21, 2007

Creating a Wireframe

After sketching a site structure, my next step was to create a wireframe to fit everything needed into each page. A wireframe is sketch that shows the basic form of a product. In engineering and product design, it might be a computer-generated 3-d model. In web design, it is a sketch of the pages that shows the major elements, such as navigation links, content, and any logos or brand elements.

Here's a snapshot of the first wireframe, which I drew with a basic drawing program:


By sketching out a typical page, I formed a sense for the visual hierarchy. "Visual hierarchy" basically means focusing attention so that important things are the most noticeable and less important ones aren't as obvious.

In developing the wireframe, I carefully considered how the parts of the page would be positioned. I tried to create clearly defined areas for navigation and content that would be easy to skim. (Studies of web use show that most people quickly scan pages to see what interests them, rather than reading every word.) I planned the site navigation to leave room for subsections along the left side of the screen. (Using left side for subsections gives a lot of flexibility for future growth of the site because it's easier to add items to a vertical list than it is to add to a horizontal list--scrolling horizontally is a very bad thing in web design.) I also placed a search box at the top of every page just in case people felt lost.

The sidebar on the right side also serves a purpose. First, it narrows the main content area so pages with a lot of text won't seem as text-heavy and hard to read. Second, it gives buffer for people who's screens are smaller than average so they won't have to scroll horizontally to read the main content. (Horizontal scrolling = Very Bad!) Finally, it gives another area of the page for special types of information--if something needs to be said but doesn't fit the flow of the main content, there's room in the sidebar.

Based on the wireframe, the decision makers in my group had an idea of my plan for the web site and approved it, and I could build a web version of the wireframe in HTML. Web wireframe comes in handy for exploring page interaction and performing basic usability testing, which I'll talk about in my next posting.

Thursday, February 15, 2007

Designing a New Site Structure

After doing research on what people hoped to see in the new site, my focus turned to site structure.

My goal was to produce a drawing of the new site's pages--the sections and subsections and how they would be arranged. (Structural drawings can show how deeply buried important information is, as well as show if some sections are too cumbersome and need to be split into subsections. They also act as visual aids to make it easier to describe site ideas to other people.)

From surveys I had learned that people wanted easier navigation in the new site. Their comments showed that they weren't finding things where they expected them in the existing site. (This wasn't surprising -- a structural drawing of the existing site suggested it would be hard to find some important pages, and some of pages in the main navigation weren't important.)

One specific problem seemed to be too many categories that weren't different enough from one another. For example, the existing site navigation includes links to Services as well as to Grants (which we offer) and eLearning (which is what we support). Site visitors sometimes had to click through all three to see how we could help them.

Another trouble spot was the Resources section, which provides online information related to eLearning and technology. Over time, it had grown to be several linked pages without a central organizing theme. Site visitors who visited Resources had to work had to locate the information they wanted or, more likely, they gave up.

After examining the content we had and comparing it to the suggestions from the surveys, I created a structural drawing that organized the pages of the site. Here's a snapshot:


This structural diagram was just a starting point. My ideas for site structure changed over time as I tested it with people inside my group and people who come to my group for services. (I'll discuss how it changed as a result of user testing later on.)

Wednesday, February 7, 2007

Assessing the Old Site

Most of the web projects I've worked on have been redesigns of previous sites. My first step is always to carefully examine the existing site to see what is or isn't working for the web site's owner.

When I examined the existing site for my current project, I could see that the web site didn't match my group's goals. The content was a bit outdated and the section navigation didn't reflect what we do here. It was hard to find information on our current projects, which was frustrating to people outside our group who used the site as a reference.

After I examined the old site myself, I surveyed other people about what they thought should be in the new website and what they valued in the existing site. I included both people inside my group and people who come to my group for services. The list of suggestions was long, and some of the items were not practical -- but there were also suggestions that a lot of people gave, such as:

  • a clear list of our services
  • a showcase to highlight projects and new technologies at OSU
  • easier navigation
  • more online resources
  • an RSS feed of our news and events
In developing the new site, I based my decisions about content and features on this information.

What I've Been Working On

Sorry for the slow start on this blog. I've been hard at work on a web site redesign for the group I work with at Ohio State.

This project has been underway for several months now, and we're planning to launch the finished site in mid-March. In my next several posts, I'll share information about the steps my group has worked through in the site development, including

  • assessing the old site
  • designing a new site structure
  • creating a "wireframe" of the page layout
  • testing for usability
  • collecting and editing content
  • working with visual designers
  • coding the final site
  • testing on browsers
In the last post, I hope to unveil the final site. But I have a lot of work to do for that to happen--so time to get back to work!