Avoid Edge Cases by Designing Up Front

In my last A List Apart article, I called attention to the following problem:

I then went further and complained that these edge cases are owed to a lack of planning. In the absence of careful pre-design preparation, site builders are powerless to stop designers (and other team members) from demanding an endless stream of tweaks and exceptions that will invariably result in needlessly convoluted markup and style sheets.

This article is meant to offer a solution to my earlier complaints by offering a brief explanation of the process steps—already familiar to information architects and the teams that employ them—which lead to effective scoping and wireframes, along with others that can ease the ongoing maintenance of a site.

In the context of web standards, the most significant product of the additional steps is a style guide, which strikes at the problem of ad hoc changes by tying the site’s structure directly to its graphic design.

The problem:  leaping before looking#section2

On many projects, I see the following process followed, and willingly follow it myself:

1. Acknowledge objectives
2. Design
3. Produce templates and stylesheets
4. Write code
5. Test presentation and behavior
6. Publish

Does this process look solid to you?  For small projects handled by experienced people, it is.

However, it has been my experience that too often, a graphic designer will begin a project by building composites or prototypes with the goal of creating an attractive site.  While there’s nothing wrong with attractiveness, the look and behavior of a site need to be driven by its objectives.

For “brochure” sites, an emphasis on aesthetic value is probably acceptable, because many brochure-site sponsors are reluctant to pay for an extensive project-planning phase. Their reluctance isn’t unfair, since most brochure sites have the same business objective: to provide a basic yet attractive web presence for the client, without requiring much in the way of application functionality or other components which require keen attention to the details of the user experience.

However, if the demands of the project go beyond the scope of a brochure, it’s wise to do some assessment and planning before anyone opens their tools.  The six steps outlined above might be adequate for simple sites, but…not every site is simple.

When you need to take more care with planning#section3

There are a number of circumstances that require the thoughtful development team to undertake more deliberation.  Several of these circumstances are listed below, followed by projects in which they might be encountered.

• Broad/large audiences:#section4

  ubiquitous brands, sites with national or international (instead of regional) focus, entertainment products, public service sites

• Amplified flaws:#section5

  online-only commerce projects, advertisement link destinations, event promotion sites

• Demanding timelines:#section6

  projects in which stakeholder expectations don’t relate to project challenges

• Complex or mission critical applications:#section7

  financial transaction applications, time-management, supply-chain, or customer-management applications, custom content management systems, systems that include user-generated content or extensive personalization

• Large infosystems:#section8

  sites intended to publish thousands of documents

• Expectations of big numbers:#section9

  projects whose stakeholders believe they will be the Next Big Thing

The preceding list is neither comprehensive nor universally applicable, but covers most situations.

Circumstances like those just described beg the addition of the following steps to the basic site-development process.

• Assessment:#section10

  A formal and detailed assessment of the project allows its scope to be properly defined.

• Personas and scenarios:#section11

  Executed with care, scenario roleplaying identifies likely obstacles to positive user experience, which can then be removed from the design prior to signoff.

• Wireframes:#section12

  The guidelines established by wireframes enforce layout consistency, discouraging the designer from composing everything as if it’s intended for print.

• Style guide:#section13

  Adoption of a style guide allows collaboration between all team members to the end of finalizing the site’s design.  Even clumsy execution of a style guide requires the graphic designer to “think out loud,” allowing needless edge cases to be caught and stopped before work begins on the prototypes of the work that will actually be put into production.

Project assessment made simple#section14

When the time arrives to assess a project, I borrow from the fundamentals…that I learned in grade school.

No, really.

The six words that guide the assessment process are learned by schoolchildren the world over.  In English they’re called the interrogatives:  Who? What? Where? Why? When? How?

When asked during a sitebuilding project, these questions might read as follows:

• Who do we want to visit the site?
• What are we publishing that those visitors will find important?
• Where are our visitors in terms of geography, ambient environment, and client platform?
• Why does the sponsor want the site built—what are its business objectives?
• When should the site be launched, phased, maintained, and finally taken down or redesigned?
• How are we going to build the site—what tools are we using, and what’s the budget?

Consideration will reveal that the answers to the six preceding questions, once properly expanded, tell a site’s designers and developers everything about how the site ought to be built—and all of those answers affect the site’s final presentation.

The value of establishing browser support guidelines in advance#section15

The role of most of these questions in the assessment process is self-evident.  Meanwhile, a meaningful and complete answer to “where?” can save a lot of time and embarrassment, because that answer defines which browsers the site should support in full (while most of the others are still usable by virtue of progressive enhancement).

Developers who have settled into a comfortable role or market niche can actually forget the need to establish browser-support guidelines as part of the assessment process, but when such developers assume a new job or role, their forgetfulness may result in a painful lesson.

The browser support framework used at Yahoo! is one approach to browser support that can be scaled down to the requirements and capabilities of anyone who wants to avoid that pain.

This time, it’s not a game:  scenarios, personas and roleplaying#section16

Armed with a detailed draft assessment, the team will know enough about the site to roleplay likely visitor sessions. Roleplaying will come naturally to some, and for the rest, it’s easy to explain.

Create at least one imaginary friend who bears a strong resemblance to the visitors you want to see on the site. Then create another imaginary friend (or two) whom you think would be likely to visit the site.  If you want to be thorough, create one last imaginary friend whom you desperately hope will not visit, but who would still be in a position to influence others’ opinions of the sponsor if they did visit.

Since the assessment will have offered some hint of visitors’ likely goals, you can then roleplay visitor sessions.  With each iteration of this process, you change different factors:  user objectives, interface/architecture elements, common external obstacles, color use, themes, layouts, content weights, and so on.

Done properly, this step will establish the human factors of the design that will best suit the sponsor’s expectations.  However, it can be expensive; effective scenario work generally consumes a dozen or so man-hours for a relatively simple site.

Don’t worry too much about Grandma unless she’s part of your target audience#section17

While it can be useful to conduct a scenario with a user you don’t want on the site, the goal of that scenario should be to identify design decisions that will intimidate users and lead them to criticize the sponsor’s business.

Efforts to tune the user experience to the needs of visitors whom you neither want nor expect to use your site can be considered noble, but will either reduce the design to the lowest common denominator, or offer a dubious return on investment.  Don’t forget that you can’t please all the people, all the time.

Wireframes and layout modularization#section18

Wireframes identify and locate all of a site’s significant elements, such as page headings, navigation, primary content, sidebars, and application interfaces.  A single wireframe should be used to describe the basic layout of the entire site, but you should also create wireframes for section indexes and application interfaces.

Wireframes protect project participants from unpleasant surprises.  They also provide the information needed to define the relationships between elements of site content, and the ways in which those relationships will be described in the site’s stylesheets.

Effective wireframes can also provide a focus for discussing the behavior of the site’s layout and interface, leading to resolution of any fixed-vs.-proportional, Ajax-vs.-static, and typography questions that remain open after scenarios are played out.

An alternative to scenarios:  hallway usability testing#section19

If you translate wireframes into plain pages that merely position elements of your layout, you can test with real users instead of imaginary ones.  In advocating this approach, fellow WaSP Thomas Vander Wal offered the following wisdom:

If you’re working with a client who has the necessary resources, you can find internal testers who are similar to your intended visitors.  Apart from the benefits Vander Wal describes, you can interview the test subjects and gain background information that will aid in the creation of future personas.

The style guide:  documenting a site’s true face#section20

If you have experience collaborating with information architects, it’s likely that you’ve worked with wireframes before, and grown fond of them.  However, the information left out of the wireframes out can be put into a leg’s-length list of specifications that should be established in a style guide.

Before the style guide comes together, a design sketch will usually need approval from the client.  The sketch incorporates the layout described by the wireframes, but includes most of the other elements under the control of the art director or designer:  colors, typography, illustration, photography, and composition details that are important at the section or element level.  Smaller details—tweaks, if you will—can wait for later discussion, but the approved sketch should be complete enough to begin a style guide.

These elements should be discussed in the style guide with the entire life cycle of the site in mind.  Instead of letting the designer compose layouts as if they were meant for print, a style guide explains how a given situation should be handled—for example, the treatment of blockquotes, how much whitespace should exist between sidebar sections, the desired aspect ratio of inline graphics, or what icons should be used for list item bullets…even on lists that haven’t been thought up yet.

Some projects may require approval of final composites in lieu of design sketches.  When this happens, the greater share of the work on the style guide won’t be done until the comps are approved.  Ideally, in this situation the stylist and the designer will work together to ensure that the comps are composed for the web, rather than for print; meanwhile, the designer should be given sufficient leeway to meet the sponsor’s expectations of embellishment.  When this collaboration is undertaken with open minds, both comps and the style guide stand an excellent chance of satisfying everyone’s priorities.

Effective style guides provide context-specific guidance to designers and stylists that will be literally worth its weight in gold (in a costly market).  The best kind of style guide will also explain the rationale for each recommendation or rule it lays out.

Under no circumstances should designers be ordered simply to hop-to-it-already, because they will micromanage their own work product to an extent that will result in seemingly interminable problems.  Never forget that perfectionism is too common in the design trades to gracefully bear parody…

Wireframes and the styleguide:  not a replacement for composites#section21

The more daring among you might be thinking that with wireframes and a style guide to tie everything together, comps become superfluous.

In fact, nothing could be farther from the truth.

Comps are all of the following:

• Fully detailed snapshots:#section22

    For all their benefits, wireframes and style guides still need the benefit of a trained audience to realize their full potential.  A composite can be attached to an e-mail without qualification and sent to a sponsor, even an untrained one, for approval.

• Lossless archives of project assets:#section23

    Most of the shops I’ve worked with produce comps as Photoshop documents which are not only used to create the flat snapshot images presented to the project sponsor, but are also delivered as-is to the site producers.  The power of Photoshop’s user interface makes it easy for designers to compose and describe the visual aspect of a site’s layout, while simultaneously providing any photography, rendered type, or artwork that constitute the project assets.  I could say even more here, but Adobe’s not paying me to write this article.

• Deliverable by the designer alone:#section24

    Every member of the team has a deliverable for which they’re responsible, and a team that eschews comps also deprives its designer of demonstrable credit for the success of a well-executed project.  Additionally, a composite is the best platform for assessing design quality in a single glance, which is something the designer needs in order to do his job well.

The wireframes and style guide explain why and how things are to be done, but it’s the composites that do the best job of explaining what the site is, from end to end.  Compared to the dry, technical nature of the rest of the project documentation, comps are colorful, approachable, and salable…and thus assets with which great care should be taken.

Revised process: a fresh look and new benefits#section25

Once revised, the process outlined near the beginning of this article appears as follows:

1. Assess objectives and requirements
2. Conduct scenarios
3. Produce wireframes (and establish site architecture)
4. Produce sketches, comps, and (if necessary) prototypes
5. Draft the style guide
6. Produce templates and stylesheets
7. Write code
8. Test presentation and behavior
9. Reconcile test results, if possible
10. Publish

Some eyebrows might elevate at my “if possible” qualification for reconciling test results. However, there’s a good chance that some problems won’t be showstoppers, while still requiring time-consuming fixes that cannot be undertaken prior to launch without overrunning deadlines (…or overrunning deadlines even more).

While the additional steps consume more time, they offer the following benefits:

• Well defined scope:#section26

  Since the assessment defines exactly what needs to be built and the resources that will be made available to build it, time and progress management are made easier.

• Earlier identification of user experience issues:#section27

  Scenarios probably won’t catch all of the possible UX flaws in a site or application, but they will reveal many of the flaws likely to force multiple production iterations—before design, much less production, even starts.

• Context and purpose are well-established:#section28

  The wireframes ultimately define where everything goes.  Armed with this knowledge, the developers can devote their energy to implementation and production, rather than dithering with edge cases or internal disagreements.

• Team members become fairly accountable for all of their own decisions:#section29

  Each member of a development team makes decisions that affect the timeline.  The stakeholder lays out the work for the engineer.  The engineer scopes the work of the producer.  The producer defines the online toolset of the designer.  The designer’s work informs the schedule of the stylist.  The fortunate stylist needs the other team members to normalize their work product in ways that minimize exposure to browser bugs and junk markup.  A style guide makes all of these interactions predictable, and encourages dialogue between team members about problems that otherwise would remain invisible until the site goes into production.

Though generally good, the outcomes described above are especially beneficial to standards-friendly site development.  The nature of the web platform demands that in a project setting, issues such as scope and objectives be defined well before production starts.  The process steps introduced in this article offer a straightforward way to supply those definitions in a timely fashion.

You might be the clever reader out there who’s probably wondering: why spend all of this extra time?

It gets paid back.  The time requirements for maintenance and extension are greatly reduced—even before the site is launched—and time spent planning the project usually saves time iterating production prior to launch.  Finally, the beefed-up process is imperative for teams that actually have lives outside of work: teams that can’t accurately measure their progress rarely get full weekends off, much less earn the unqualified confidence of their sponsors.

When setting guidelines, stress the affirmative over the negative#section30

Well-managed projects and the trouble they save are inherently wonderful, but executing them requires more than a faithful-yet-thoughtless adherence to rules or process steps.

When given a choice between describing what should be done instead of what shouldn’t be done, reach for the positive advice and an equally positive rationale.  Given a goal to achieve, a team can work together constructively and sympathetically; given a pitfall to avoid, members of the team will adopt an attitude based more upon fear of failure.  Which sentiment do you want permeating your workspace and headspace?

In conclusion#section31

I leave it up to the reader to decide if the transparency created by the added process steps described in this article will be worth the time they require.  While the investment would be unjustifiable on most small projects, larger or more-complex projects are more likely to launch on time and on budget, since the added steps remove many of the surprises that turn up at the most inopportune times.

The value of the added steps is amplified by adherence to web standards, because a standards-driven project has the best chance of succeeding when site structure and purpose are accounted for through effective assessment, testing, and project documentation.  Finally, don’t forget that web standards offer the best hope of minimizing the share of labor in a site’s total cost of ownership.  The enforced consistency afforded by a style guide allows a site to be maintained with ease in the spirit of web standards, as opposed to relying on duct tape, baling wire, and impulsive judgements that may later collapse.

Acknowledgments#section32

The author would like to thank Steph Troeth and Thomas Vander Wal for their help with whipping this article into its current shape.