So, your boss has come in and asked you to design a great big new web
site.
Yikes, what to do?
In our web
design methodology at Sun, the first step we start with is
"Discovery" -- which is basically all about figuring out what you're
doing on a web site or subsite and who you're doing it for. Here
are the questions I recommend always asking when you're starting a
project. These should happen in the first part of the "discovery" phase
of designing your site:
What are the business objectives? "Be a really cool site" is fun, but usually not a good business objective. Instead, you should be looking to things that relate to revenue, attracting new customers, serving existing customers and product owners, saving money through new efficiencies online. You may need a "really cool site" to attract the new customers or entice people to use your online services and thus save you money... but start with the basics first. Even though they don't seem like "design" they're the most important thing you can understand.
Who are the users? This is
another really, really important thing to
know. At Sun, we have a lot of different kinds of visitors to our
sites: Consumers (especially java.com
and the StarOffice area),
Developers, System Administrators, IT Professionals, Purchasing
Managers, Journalists, Analysts, Students, Professors, etc. The needs
and browsing behaviors are different for Consumers vs, say, Sys Admins.
But fortunately, all humans have certain characteristics in common so
we can have certain principles be true across all of our pages. And
certain areas of our web space are devoted to specific audiences (such
as SunSolve and BigAdmin which mostly support
people doing system
administration). If you're lucky, you have fewer user types than
we do... but even so you will probably find segments of users you're
designing for. It's important to think about the design of the
site in their terms -- and not your terms. (More on audience and
customer segments in a future post.)
What are the users' goals, tasks, and
missions? A couple of years ago we did an
inventory of all of the important kinds of things customers do on the
Sun web sites and were alarmed to discover there were over 400 really
important user tasks. We were shocked and somewhat overwhelmed.
We kept that list, but in practice worked from a list of 25 or so short
scenarios that describe a specific customer and some mission they're on
at sun.com. This is what we use when we're checking out new site
navigation ideas or doing major site revamps.
Who are the buyers, and do they use
the site? Sometimes you'll find that you are designing for
individual users, but are losing sight of what's actually making the
buying decisions. The buyers at your site are as important as the end
users (and vice-versa, btw). A number of my friends at other
business-to-business web sites mention this issue to me... it's easy to
get wrapped up in designing just
for buyers and decision makers or just
for end users, but neither will get you an effective site. You need to
design for both, and for the whole of the buying and ownership process,
no matter how simple or complex it may be.
What's Critical to Quality for you,
the customers, and users? At Sun, we use Six Sigma
practices to identify critical to quality factors (CTQs) which are
basically the very top requirements that customers have for a given
product (or in our case, the web site). Good CTQs have associated
measures, so also understand how you're going to measure success for
your customers' top requirements. I'll post more in the future
about Six Sigma and how it relates to web design (and also how it
doesn't), but the bottom line is that before you start a big new web
design you need to understand the key requirements of your customers
and business.
What existing discovery work has already been done? If you're organized, or lucky, you may have a lot of data already around user segments, user goals, business objectives, etc. Even if you only have partial information, do yourself a favor and collect it all in one place so you have a beginning research backgrounder for your design team or design vendor.
Where are the resources coming from? This is a mundane question, but an important one. You need to know before you start not only who is footing the bill for creating the design and doing the engineering, but also whether there is adequate budget to maintaining the site after you launch.
Who's playing what roles in the
project? I'll post more details in the future, but on a big
project you should have a project manager, plus "workstream" leads for
each key discipline in the project (visual design, IA, usability).
The Strategic Brief...
Once we understand all these things above, we create a Strategic Brief (which is pretty
much a typical 'design brief' format, but with two dashes more business
focus.) The
Strategic Brief is a great document to give to vendors who are working
on your project.. but we also use them even if we are doing the work
internally. The Brief defines what we are doing with the project and
why. It should include:
- Current situation overview
- Business objectives
- Audiences
- Customer objectives
- Scope & deliverables
- Constraints & touchpoints
- Research and background docs available to the project
(And yes, I'll include a more detailed explanation of what should be
in a strategic brief in a future posting!)
If you have done all of this, you'll be in good shape to start
your design project. And notice we haven't even fired up
Photoshop or Dreamweaver yet!
