Because it never really ends, does it.

Chris Lawson

PSAC National

Workshop Introductions

Workshop outline

Expectations and limitations

Why redesign

One dog year is supposed to be the equivalent of seven human years. Websites age like that too.

And the internet, our use of it, and our expectations of what our web presence will do for us, is evolving at that speed. Web usability guru Jakob Nielsen says people form their expectations of your website on other people's websites.

So you’re almost compelled to redesign.

Depending on what your current situation is, the longer you leave it the harder it can get.

If you're going to redesign your site, it's really important to do it right, because the better the job, the more time will elapse before people will start feeling “the itch” to do it again.

And you’re looking for payback. You’ve been working on this thing for lord knows how long and you’d like to see something for it.

Think beyond the decoration

A lot times the impetus for a redesign comes from stakeholders feeling that the site needs “freshening up” or a “new look.” But it’s important to explore that feeling beyond just what the site’s sponsor thinks. Because after all, a lot of design preference is pretty subjective and just redecorating the place may piss off as many people as it pleases. And it will still cost you in time and or money. So go big or go home, I say. And as Jeffrey Zeldman says, Design without content is decoration.

Information architecture: what goes where and what you call it. Do it well, and people will be able to find stuff on your site without searching. Do it badly and any hope of using your site to answer routine questions and fulfil common requests will evaporate faster than you can type ‘check our website’. Information architecture includes the site’s navigation.

User experience: a broader topic for consideration. Includes everything from how applications on your site work (like shopping carts, search functions, mailing list sign-ups) to how you interact with your visitors (those who send you email, comment on your content, order stuff from your store, sign up for conferences, etc)

Content strategy: a tasty buzzword encompasses not only what sorts of topics your website covers, but also how: text, audio, video, presentation or interactive, and how that stuff gets onto the site, whether by you, your users or some combination of the two.

Functionality: in what ways can your members use your site to get their union work done? Is it a brochure? Are there ways you can move beyond that? How does your website relate to other parts of your web presence? A lot of what you determine in the first three departments will condition what sorts of functionality your site requires.

Do your homework

How much time and or money you spend on this varies widely and wildly. But anything you can manage is well worth doing.

Stakeholder interviews:

Can be structured or free floating, but it's important to know from your leadership, your employer and anyone else who counts as the 'publisher' of the site or parts of it what it is they expect the site should do, and what they think it's not doing now, as well as what they want to change and what they want to keep.

Why? At the most basic, utilitarian or dare I say, cynical level, think sign off. And if you have any big plans, they need to hear about them so that they can be made to believe it was their idea in the first place.

But more optimistically, by talking to everyone who has some involvement with the union and its web presence you may discover need that need meeting or opportunities to help the union do a better job.

If your site uses a content management system and some form of distributed publishing system, make sure that you also include the people doing the posting as stakeholders.

User needs analysis:

This one is a bit more complicated. And not all of this may be do-able or relevant. But it's probably a much more fruitful source of inspiration for the direction your redesign takes.

The data you gather can come from:

  • Interviews with website visitors
  • Online surveys
  • Website analytics
  • Search statistics

Be prepared. Your ideas about what the website should be doing and how well it's doing that may... ah... vary dramatically from those of your users.

Non-user needs analysis

Your analytics application can tell you a lot about what pages/functions people are using on your site. But if they're finding it, and using it, it's mission accomplished, isn't it?

The more significant stuff - where you really find room for improvement - won't be found in Google Analytics because it's stuff that isn't on the website at all.

Keep a log of what people phone about.

Ensure that emails from the 'Contact us' page get stored and categorized.

Keep track of what the union is still faxing or mailing out in hard copy.

What of that could be handled by a web page or application?

Different picture emerges of the site: we think it's all about the bits of text we put up with slavish devotion and almost diagnosable efficiency.

But in fact, our content may be of very little interest to most of the people who come to the site.

Maybe instead of putting up bits of text with dear leader's latest good words, we would do better by our users if we hooked them up with their servicing rep in under six hours?

We can't sort out everyone's problems with a web page. But maybe a chat application.

Baseline numbers/goals

Having baseline numbers and goals for your redesign helps take the decision of whether or not the project was a success out of the realm of the subjective.

Vists: if you're adding new content and functionality this can be a reasonable measure of how much uptake there's been on your new effort

Pagerank: is one of your concerns your invisibility on search engines? Measure it before you make moves so you can tell if your content/on-page search engine optimization efforts made a difference.

Bounce rates: a bit iffy, but if you're trying to see if people engage more with your site, bounce rate tells you how many people leave after they see your site.

Conversions: measures how usable your form-driven applications are: conference signups, online actions, change-of-address etc etc.

Task completion: there are ways of doing usability testing that don't require thousands of dollars in consulting fees. Pick tasks that will need to be done after the redesign too.

I have some ambivalence about this as a baseline. A lot of times the usability problems are well-known and spending time testing what we know to be broken is wasteful. But I include it as a consideration in case your situation warrants it.

If you are putting together some kind of requirements document - to make part of a contract with a developer, whatever goals you come up with should be in that document somewhere.

The content inventory

Your website may have been around for over a decade.

If you add new content weekly, that means you have 520 pages/units of content to think about and possibly move around. You might have thousands of pages. What are you going to do with them?

This question is a particularly thorny one if you're also changing the modality of how your site is published. Say you use Contribute, Dreamweaver or some other desktop page editor and you're moving to a web-based self-publishing system.

Did my heart rate just go up a bit there?

Now before you say ‘we need it all moved over’ consider what that’s going to look like. Yahoo Site Explorer will make you a list of the first 1000 pages of your site that it has in its search index. You can then download that as a CSV file that can be easily opened in a spreadsheet.

But uh make sure you're sitting down when you do it. Dealing with all that can be pretty daunting/disheartening/terrifying.

The other possibility is to do as Lieutentant Ripley suggested in Aliens and "take off and nuke the entire site from orbit." One often - and possibly more politely - refers to this as a “building blocks” approach to doing a redesign. Presume nothing, examine your user and stakeholder research and design a website.

The other compelling argument for doing it this way is that if you stare too long at that list of your current content, you're going to get sucked in by the old structure, old architecture and may end up reproducing all the mistakes you expected to correct by doing this redesign.

Of course it may not be possible to just nuke the old site. Your site sponsors (aka the union's leadership) may forbit it. Ask them to consider the time it takes to move all that content over. Say you've got those 520 pages and you assume that screen scraping the content and pasting it into Drupal or Wordpress or whatever CMS you're moving to takes five minutes a page. That's about 44 hours of work - five or six days if you work more or less solid for eight hours a day. With pee breaks. Maybe.

But there's more work on top of that. You have to figure out where to put the old stuff within whatever IA you come up with. And you have to make sure that you map your old URLs to the new.

So a compromise: use Google Analytics to determine your year over year top 100 pages in terms of page views and port those. Fill in the content gaps using the building blocks approach and keep the rest of the old site handy near line.

Or, say you'll transfer over any page that gets more than 1 per cent of your site's annual page views. Or over a certain number.

Next step: more bureaucracy

Even if you're a volunteer doing this as a labour of love or because you've been voluntold, it's really important to nail down just what it is that you're going to be doing.

Because otherwise you will never be finished. Or the site will never launch. Or both. Everyone who puts together a website experiences scope creep. Statements that begin with "oh I just thought of something" are to be feared and avoided.

That's easier to do for outside consultants because of course the meter is running and they can enforce the original ground rules by charging more. But what do you do if you're on staff or a volunteer? Phrases you can use include:

  • That'll be in Phase two
  • Let's see how that shakes out in usability testing
  • I love the fact that web development is an iterative process. Let's get through the first iteration before we talk about adding potentially confusing functionality

Or just cry uncontrollably.

This is designed to preserve your sanity and not punish people who step up to do important union work.

If you're contracting with a designer or a design company they will no doubt insist on something like this as part of the contract. They will also include the words "this contract is subject to change" which means you can change your mind, or add things, but if it involves more time, you'll be charged for it.

They need to do this so they don't lose money trying to hit an ever-changing target that is your development project.

What goes in a statement of work

Some people might want to call this a specification. It's not really. Specifications are much more exhaustively detailed.

But you do have to spell out exactly what the site will do. Do not forget the obvious. Contact-us forms, search functions seem to go without saying but nothing should go without saying.

What is to be your reference platform? Aka what browser on what OS? What screen resolution? Flash? HTML5 or XHTML 1.0? No clue? Again Google Analytics can be of use here. If you don't have to worry about MSIE 6, don't. All concerned will be much happier.

What level of accessibility to you require?

Design stages

Your mileage may vary and if you're doing this as a volunteer, you may want to skip some of these stages. It is possible to overthink this stuff.

The creative brief is an explanation of what the site is supposed to do, the reaction it's supposed to evoke, a listing of sites you like the look of, of 'competitor' sites, etc, as well as a sense of what's wrong about the current site.

Persona are a kind of substitute for a full user needs analysis. You imagine a typical website visitor, imagine what interests them (based on your knowledge of how people use your site and how they interact with the union around stuff that's not on your site.

Wireframes are line drawings of categories of pages on your site that indicate placement, priority and labelling of content and site elements.

Design direction is a composite image or images of how the site will appear. This is the part where it gets fun.

There's usually a whole other process for testing and signing off on whatever content management system is part of the package. If indeed one is. Otherwise your final deliverable may be a template of sorts.

Your designer/developer may not work this way. And you may not chose to. But I would like to make a pitch for separating out the work of redesigning your site into these stages.

It's often helpful to limit conversations to particular aspects of the project so that all aspects get the needed attention. Also, if one stage is done badly or doesn't meet expectations, less work will need to be redone since each stage builds on the previous one.

If you are doing usability testing, it's usually done at the wireframe stage, again because if something fails badly, there's less work to be redone.

Usability testing

This can cost in the multiple tens of thousands of dollars.

Or, you can do it yourself.

Or you can use a DIY service.

You as the publisher identify tasks that site visitors need to peform if you're to meet the redesign's objectives. You find a small (five people?) group of uninitiated people who are typical of your audience's age, education, web savviness.

You get them to try to perform the tasks while you film them or take copious notes. You ask them to think out loud while they're doing it.

Then you rate the tasks as performed easily performed with difficulty or unable to perform. You're aiming for all your tasks in the 'performed easily' category, FIY.

Parking lot

Further reading and resources

  • My Delicious links tagged 'webdesign'
  • The Zen of CSS design, Dave Shea, Molly Holzschlag
  • Web Standards Solutions: the Markup and Style Handbook, Dan Cederholm
  • Designing with Web Standards, Jeffrey Zeldman
  • Building Findable Websites: Web Standards, SEO and Beyond, Aaron Walter
  • Building Accessible Websites, Joe Clark