Avoid Edge Cases by Designing Up Front
Issue № 228

Avoid Edge Cases by Designing Up Front

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

Article Continues Below

Some sites are steaming heaps of edge cases.

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#section1

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#section2

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:#section3

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

  • Amplified flaws:#section4

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

  • Demanding timelines:#section5

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

  • Complex or mission critical applications:#section6

    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:#section7

    sites intended to publish thousands of documents

  • Expectations of big numbers:#section8

    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:#section9

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

  • Personas and scenarios:#section10

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

  • Wireframes:#section11

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

  • Style guide:#section12

    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#section13

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#section14

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#section15

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#section16

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#section17

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#section18

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:

I realized that the personas were stand-ins for real people. I started using real people and testing and developing with their feedback. Rather than making somebody up, I used the real “Harry” from Engineering who could never find anything on the intranet that was there for engineers.

I used “Harry” for baseline user testing of the existing site, user testing wireframes, testing the interface, and beta testing. Not only did we find that process helpful, but we gained an evangelist for the finished site.

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#section19

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#section20

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:#section21

      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:#section22

      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:#section23

      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#section24

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:#section25

    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:#section26

    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:#section27

    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:#section28

    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#section29

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#section30

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#section31

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

17 Reader Comments

  1. I’m more a software developer than a website designer. In software development we moved from a sequential process (waterfall) to iterative processes many years ago. If projects get more and more complex you simply cannot design everything up front. So you make several iterations of design and implementation, everytime improving quality and also your knowledge about the specific project needs and circumstances.
    So your approach is better than a chaotic one, but for complex sites I would suggest to go iterative.

  2. Andy, you cannot compare a software development projekt with a website. Web designers are creative people, software developers are nerds. So with those different kind of people you want to run the same process? Never ever…

  3. (@Jochen: Not to go too off-topic, but creative people are found in every walk of life, and in every position, including software development. That’s too broad a brush to be painting with…)

    For me, this article made good sense, and seemed like a relatively painless, even fun way to get websites done… in my dreams.

    I truly do wish most shops knocked out projects like this. But I’ve never seen it.

    So does the author have examples of sites that happened under this utopian process, that I may gaze longingly at the fruitful result of their workflows?

    Gotta go – the latest edge case awaits.

  4. Since the best part of my energy here was aimed at _web_ designers and project managers, I deliberately chose not to discuss my ideas in a waterfall-vs.-iterative context. Sorry, but the instant I start jabbering about software engineering, nearly every single art-school-trained reader will _tune out_. That’s the _last_ thing I want.

    However, I also figured that it would be a matter of time before it came time to bring it up in the comments – in this case, on the first page.

    Web projects are going to require a bastardization (in whatever proportions) of the two methods – at once you have project sponsors who often need their documentation delivered at the Dr. Seuss level, while again you’re working with tools that lend themselves quite well to iterative development.

    The idea is _not_ to throw iterative development into the dustbin, but to catch the gotchas that would otherwise increase the time between iterations.

    If I could start over from scratch with the article, I’d’ve probably given examples of the sorts of edge cases at issue – “the sidebars in _this_ section need to have 10px of padding, but the sidebars in _that_ section need to have 12px of padding” would be a good one. It’s best to catch those early in planning and/or iteration, rather than later. In my opinion, The ground rules needed to make those catches are established with – you guessed it! – wireframes and a formally normative style guide.

  5. Do you feel that the ideas presented in this artice are realistic, or pie-in-the-sky?

    What anecdotally common dynamics or personal experience can you share to substantiate your answer?

  6. While the proposed process is very well put together, and great for larger firms with big clients, I currently design mostly for small and medium sized businesses who are not interested in extensive user testing and usability reports. They also are generally unwilling to incur the extra cost that is associated with a longer process. In your article, you mention that it may not be suitable for smaller sites, which is mostly true.

    On a larger site, I think it is valuable and reasonable to expect the level of detail you call for. There’s a book that is out that lays out a very similar process, called “Web Redesign 2.0: Workflow that Works”:”http://www.web-redesign.com” . It certainly helped me understand a thorough design, development, and documentation process (with helpful screenshots).

    Overall, your article is a very helpful resource, thank you!

  7. I think a sequential process for website development is not realistic, since your customer has to LIKE the website you are building. Website building is not a technical and graphical issue alone, it’s also a kind of art. And the website developer will develop some thing that the customer does like and some others that he does not like. So once you get feedback from your customer you’ll have to take some steps back and redefine your previous results.

  8. Dieter, I think the process described in the article is for helping the website developer focus on his own work. Of course there will be customer feedback, but that’s at the end of the process, not after every single step.

  9. Great article. It rehashes much of the stuff I learned in project managing. I have to agree with Zack here and say that the process described is great for larger firms. Although usability testing does not have to break the bank (see Jakob Nielsen’s articles), it’s often a non-issue for smaller businesses.

    From my experiences in large organizations, it’s incredibly important for designing and re-designing that there is an overall project manager with enough authority to keep designers, engineers and higher powers (management, shareholders) in line. Engineers, as well as designers tend to run away with things. Even worse, designers are often confronted with completed (read: half baked) designs made by engineers and vice versa.

    Indeed, the approach you described could elimate a lot of problems. But you have to have all the parties (and stakeholders) on board from a very early stage as well as a project manager who has the authority and tools to lead a project.

  10. I think most web design businesses get into trouble because the conceptual framework to which they view a website is flawed. I website is not a poster, it is a richly styled interface. Any project manager who prioritises a graphic designer’s input over the programmer’s tasks is headed for disaster and probable unemployment.

    The simple truth about website design is: after half an hour of using a website, unless there are serious contrast, layout or typography issues, no-one cares how it looks. All folks care about is site structure and content.

    From my point of view there are basically two ways to develop a website.

    1. Pulled out of your template stack to be styled, content filled and published.

    2. Developed as software using components from your application library to be added onto an expandable architecture designed using the project’s scope.

    While No.1 is quick and dirty for those budget projects, No.2 will guarrentee for your client their website’s economic maintainance and upgradablility indefinately into the future. And, when I say developed as software, I’m talking about no static markup whatsoever even if the website itself is to be published as a static one.

    Finally, two quick points;
    -The choice to develop for browser compatability does not exist for the professional website designer.
    -Development for grandma is priority in an ecommerce site as baby boomers hold the majority of wealth in the world today.

  11. Your assertion that people don’t care what it looks like is one to be taken with a grain of salt. Given two competitors, the one with the more-usable site will win; that factor being equal, the one with the more-attractive site will win.

    “Good will”:http://dictionary.reference.com/search?q=good+will counts for something, sometimes a lot, and acquiring it is cheap in terms of return on investment. Meanwhile, people miss that point because the development of good will is all capital investment, all the time – in the form of better-trained CSR’s, excellent designers, more-skilled project managers, and all of the overhead those talents require. A stakeholder on a cost-cutting mission won’t go there, because the payback develops over time and is difficult-to-impossible to measure.

    At the same time, there are teams that have ineffective project management, and the stakeholder winds up smiling, nodding, and signing off on the engineers’ work – no matter how craptacular it may be with regard to usability – because he doesn’t know any better.

    There are two extremes to the problem. I ignored the extreme at the engineering end of the scale because it was out of scope – I was following up on a well-defined problem laid out in my previous article.

    Meanwhile…

    Obviously, a place like Amazon needs to hew to the LCD. ThinkGeek does not. This is simply one of the more stark contrasts, but there are others like it.

    “E-commerce needs to be usable by everyone” is not automatically a true statement.

    That said, there are usability concepts in e-commerce that benefit all potential users:

    # Minimize steps and obstacles between the start of the session and the purchase. (Yes, this can be done across multiple user objectives and session scenarios.)
    # Ensure that the visitor’s shopping cart is visible at all times.
    # Allow removals and additions to be conducted with a mouse alone.
    # Respect the customer’s intelligence, but don’t assume they’re a genius, either.
    # Ensure that all content is quickly legible, within reason (a subnotebook such as the machine on which I’m writing this comment can easily be declared an edge case, for example).

    These are not respected without attention to specific aspects of user experience; template-filling, this is not!

  12. We’re a small shop (three people) but are taking all of January off to build our own internal project management system. We’ve spent a year developing the ideas (many of them mirrored in the article and your comments.) Why? Well, we figured that as a small shop we needed the ability to scale up the work we did (so we could make more cash, obviously,) but found that the more jobs we took on, the more time we spent on the phone dealing with irate customers.

    Man, we all know the cliche – work smarter, not harder – and that’s what it’s about. Systemised workflow is gold for small businesses – it puts us on a more even footing with our bigger competitors.

    I also respect the comments about authority – although in our case, because our jobs are at the smaller end of the scale and developed using a more intimate process than larger firms, it’s as important to maintain some sort of authority over the client. Our biggest workflow problems are in keeping clients to our tight development schedules.

    As an aside, I find point four above hard to accept. Oh, and our process is always iterative 😛

  13. Hi Ben! Thanks for reading the article translation! I´d appreciate your help, but I think we really can´t translate your exact idea on that topic to Portuguese. That´s why I tried to translate de idea instead of the lyteral words.

    Contact me for anything!

  14. I work on “LUDO(LUDO Productora Multimedia)”:http://www.ludo.com.uy , a small design studio in Uruguay. We produce multimedia web-based applications.
    Last semester, we have been working on a web product which consists of a limited backend to manage personal work, aimed at artists and graphic professionals, while the frontend is totally customizable, adapted to the client’s identity.
    We are a four-member team; and at first glance, we estimated a three-month work for the completion of the project.
    Nop.
    We are still testing and correcting it.
    I (we) should have read your article earlier, in order to realize that no matter how small a project could be, the same cutbacks would keep on coming.
    Even if the time spent planning the project takes more than expected, it will surely save future cutbacks in the production process, because any project has them, and we all know they are _unpleasant_.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA