I have looked long and hard for a good process structure for creating a web site – especially one that scales well regardless of the project size. I found that process on A List Apart. It follows the same attention to detail that I encourage. Read the full article or browse the major points below:
Additionally, anyone interested in a web site should be aware of the many factors affecting a good web design. Read Educate Your Stakeholders!, also from A List Apart, for a brief but concise overview of what’s important.
- Who do we want to visit the site? (Target Audience)
- What are we publishing that those visitors will find important?
- Where are our visitors in terms of geography, ambient environment, and client platform?
- When should the site be launched, phased, maintained, and finally taken down or redesigned?
- Why does the sponsor want the site built—what are its business objectives?
- How are we going to build the site—what tools are we using, and what’s the budget?
The Design Process
- Assess objectives and requirements
- Conduct scenarios
- Produce wireframes (and establish site architecture)
- Produce sketches, comps, and (if necessary) prototypes
- Draft the style guide (Read Writing an Interface Style Guide also from A List Apart)
- Produce templates and stylesheets
- Write code
- Test presentation and behavior
- Reconcile test results (if possible)
- Well defined scope: 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: 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: 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: 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.
- Assessment: A formal and detailed assessment of the project allows its scope to be properly defined.
- Personas and Scenarios: Executed with care, scenario roleplaying identifies likely obstacles to positive user experience, which can then be removed from the design prior to signoff.
- Wireframes: The guidelines established by wireframes enforce layout consistency, discouraging the designer from composing everything as if it’s intended for print.
- Style Guide: 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.