Team Strategy: Cool Site In a Day
By Christopher Schmitt
Way Back When It Was All General
When Web design started outabout five years agodevelopers had to deal with breaking HTML standards to make their Web pages visually stunning. We used blockquotes to formulate indents. Table structures meant for displaying data were and are still exploited for layout purposes. And for spacing out elements, we used a single pixel transparent GIF.
Web generalists like myself stem from the old do-it-yourself days of Web building. We are individuals who know just enough of each disciplinefrom writing for the Web and information architecture, to graphic design and basic e-business strategiesto put together a Web project. One has to know how all the pieces of the puzzle fit.
Yet, if you took a snapshot of present day Web development means you'd see software applications with the specific purpose of creating for the Web. Thanks to database engineers and long-lasting cookies, we have one-click shopping. We also have vector-based images that aren't from a previously existing image file format (like GIF and JPEG).
A lot has changed. The Web-safe color palettea subject dear to mehas diminished in its strength. Information architecture is amazingly crucial. Usability has come a long way... and so has Flash. Years ago, you'd have a Web developer design the site and then chop up the graphics and write the code. You might also have programmers who wrote CGI scripts for mail forms to the e-commerce backend that handled online credit card transactions. Today, you have different disciplinesmultimedia designers, information architects, user experience gurus, e-commerce engineers, and copywriters geared for the Web. I'm only lightly touching on the many positions and their respective job titles that have cropped up over the years. I'm sure you could come with your own bag of titles.
If you want to build a cool Web site, you can do it by yourself. There's still beauty in cranking out your own dot-com and publishing your material. But to achieve something of solid work, you'll need a group of people with specialized skillsthose who know their area cold, but have enough respect for the other disciplines to bend, not break, when the designer complains to the programmer that the Web form needs to look consistent.
Specialists Are Those People WhoWell, Specialize
On November 2, WebReview.com sponsored the fourth annual Cool Site in a Day contest at the Web2000 Show in San Francisco. To quote WebReview.com's executive editor Molly Holzschlag, "Cool Site in a Day is a grueling event that takes two Web teams and asks them to redesign two Web sites for nonprofit organizations in a single day."
As team leader for one of the competing groups, the first decision I had to make was how to form a team. This made me nervous. Was the site supposed to be about coolas in looking good on the screenor about coolas in a solid Web site that tries to reach its audience as the team sees fit? Would picking a team of generalists and assigning individual roles be better than picking specialists that fit those roles?
It's not rocket science, mind you, but it was a tough call to make. I decided I wanted a solid Web site for the nonprofit. So, I decided to recruit specialists. One person can't see all the viewpoints possible when making decisions. As the proverbial President, I'd just have to trust my "Cabinet" to guide certain aspects of the project with their own judgement.
As I started recruiting, I wanted to know what I was sending both myself and five other individuals into. This isn't to say that I didn't know what the Cool Site in a Day contest wasit's where noted Web designers and developers are invited (honest). I was asked to be on the East Coast team last year, but couldn't make it due to schedule conflicts. But my understanding of the contest wasn't a substitute for research.
With every Web project, there's a discovery phase. Typically, this is when one determines the scope of the project. Items that concern how much work will have to be done on your end and on the client's end are summarized in what is commonly known as a "creative brief" or a contract for further work to be done by the developer.
For Cool Site in a Day, discovery meant scouring the WebReview.com archives and utilizing their search feature for every article they had written about the contest. I even went looking for one they didn't write. This helped me get a mental grasp of the problemand with a clear handle of the problem, you can start to divine a solution.
When you have only eight hours to create a "cool" Web site from scratch, you don't want to fiddle over the design. To beat the clock and have "cool" incorporated into the site the design wasn't going to drive the project. Let me repeat: The gameplan made it painfully obvious that the team's strategy was for the Web site to be sold on a solid foundation, not aesthetics, which are sometimes mistaken for "cool." Sites can be cool looking, but not cool in and of themselves. Finding the right balance between form and function is the art and science of Web design.
|Figure 1 shows Team at the Web2000 Show
My role wasn't only to lead the team, but also to act as the lead designer.
I've critiqued Web design entries for High Five. I've surfed through literally hundreds upon hundreds of sites looking for the ones that have the extra edge that make them stand out. I also know from my experience as a designer how to maximize visual impact without spending too much time creating designs or getting bogged down in the production phase when the need ariseslike when the client wants it two yesterdays ago and there's a new episode of The Simpsons on that night.
With the team secured, I started a mailing list to get communication going. These are the actual notes I made for the design of the site:
- Entry tunnel/splash page should sell visitors on the reason the nonprofit exists (and that they should continue surfing)
- Bold use of photography w/people
- Spotlight the human side
- Give the site an "open" feel, don't "box" graphics or texts
- Be bold in the use of colors; don't use white or black as background color. Paint the canvas first with a foundation color.
- Bring crisp, fresh fonts for "type as graphics" approacha great way to make great looking graphics.
- Tight integration of copy and design
Some notes that didn't fall into the design category that I also shared with my team, I called, "Keys to the Game:"
- The contest is not a time to try something new
- If you have something that's ready-to-roll, that's great!
- Connect with the audience on the first click, if possible.
- The initial review of the client and its strategy will be important.
- Strong writing for the Web. If we do get copy from the nonprofit, more than likely it won't be prepped for an interactive environment.
- Strong user interaction from the first page to the last.
- A team name people will have a hard time pronouncing if they don't know HTML. (Okay, I made that one up.)
The Loose Itinerary
Since the client was a question mark, I couldn't create a schedule or weigh which disciplines would demand more time. I knew that regardless of who the client was, I wanted one and only one solid hour of discussion about the site direction at the start.
In eight hours, you don't have a lot of room to second guess yourself or go back and pick something up that you left behind. So, any questions about where to go or why we would be making decisions in one way or another I wanted raised up front rather than sneaking up on us later.
A component to my teamTeam delivering the site on time was to make sure everyone agreed on the direction. Fortunately, the hour strategy session wrapped up on its own. The first hour was spent, and aside from the group meeting at lunch, the rest of the day became a blur of quick decisions on design, production, copy, pasting, and finesse to meet the immovable deadline.
Even Better Than the Real Thing
The adage in the service industry goes that a project is better off without the client's interference. While it may be true that Web developers know more about the Web than their clients, the clients themselves know more about their business than the Web developers. So, a balance needs to be struck.
The impression I received from past contests was that a member of the nonprofit was actually going to be on standby, watching the festivities and answering any and all rapid-fire questions about their new Web site. I was looking forward to working with the nonprofit throughout the course of the day. Even though we'd be pressed for time, the client would have the chance to see and add input to the shape of the project. This is a way that the client can, in essence, own a part of the project. Through a mutual decision making process, the client becomes proactive in getting their project done in a speedy matter.
For the Cool Site in a Day, we had very little client interaction. In fact, our client contact was flying to LA that day for a meeting. What we had in the client's absence was a wish list of seven items they would like to see us act on, the content from their existing Web site and some new material sent by courier from their headquarters two hours into the competition.
Where did that leave my team? With the absence of the client, the site building project became more academic. We knew what steps it took to build a Web site on our own. Insuring the client's happiness, while a top priority with other Web projects, took a far-flung backseat beside patience and diplomacy. In other words, the deadline and a seven-item wish list became the parameters of the project.
|Figure 2 shows the Center for Prevention of Domestic Violence's Web site before redesign.
One of the notes I made to the team was that a sign of making the deadline would be coasting into the last hour, happily making refinements to our showpiece. What really happened was a mad dash up to the last minute.
There were moments toward the middle of the day that I'll always remember. One was when Brigitte Eaton, the production lead of the group, actually handcoded the site templates in XHTML instead of letting Dreamweaver spit out the code. I'm sure that she didn't notice my jaw drop to the ground.
I'll also never forget the laughter. The team was faced with a fast-approaching deadline. We were feverishly building a site from the ground up and we were all just having a blast hanging out with one anotherlike we'd done this sort of thing a dozen times before.
But the most surprising moment came when I realized that Team was spotting potential problems in the development process and fixing them before they materialized. We played "what if" and came up with a priority list of what needed to be tackled to have a Web site that spoke to the audienceessentially, our understanding of the relationship between the nonprofit and its audience.
At the end of the grueling ordeal, the judges went into overtime trying to decide who had the cool site for the day. True, in a contest like the Cool Site in a Day, there are only winners. But in a real development project, you win by pleasing the client. And you also win big by securing more work from the client in the future.
|Figure 3 shows the Cool Site In a Day winning site.
In the end, the client was happy with our entry and we're currently working towards polishing the redesign for them. It was also a nice pat on the back that the contest judges found our site to be the more ready-to-deliver of the two entrees. It confirmed that the strategy of assigning roles and finding specialists to fill those roles is the winning approach.
Christopher is working on a handful of forthcoming online Web design and development guides. During the day, he works for MindComet as senior design technologist and production lead on various client projects.