Chapter 3

PLANNING AND HIGH-LEVEL DESIGN

It's entirely by design that we spent the better part of the previous chapter discouraging too much up-front planning. Don't call us hypocrites now that we're offering you an entire chapter covering the planning and pre-project process. The reality of the situation is that it can be to your advantage to do a little work up front before digging into the development stage. Every project you embark on isn't going to be crystal clear; you will more than likely end up working outside your comfort zone on more than one occasion. Although it's easy to get a general feel for most projects, there will undoubtedly be specialized areas in which you will need to consult a subject-matter expert. Your clients may or may not have some idea of what they're looking for, and even then, after talking it over with them, you may come to the realization that their vision of what they want makes absolutely no sense for their end users. Although the temptation is there to simply do what the client wants, collect your paycheck, and walk away, it's far more fulfilling to work on projects where you can see the value that will be produced and where people will actual use the product you produce.

Disagreement with your client, particularly in the early stages of a project, can be really stressful. You want to get along and work collaboratively to produce something great, not just to have to fight over every point. The tools and exercises we'll present to you in this chapter will help you strike that collaborative note with your clients. We hope that by working through some of these sections together, you can draw similar conclusions and move forward as a united front. And remember, although you're an expert in your field and your instincts for what's good and what's bad are probably better than the average Joe, your clients are the experts in their field. They know their customers, employees, partners, and business processes better than you, so if they're adamant about a particular point, don't automatically assume they're wrong. Arrogance is not a productive working methodology.

If you happen to find yourself working as part of a larger team, as opposed to freelancing, it's likely that a number of the activities described in this chapter will be done by the person responsible for client relations. That individual could hold any number of titles; on very large teams, they're either the producer, the account manager, or occasionally the project manager. In smaller groups, it may be a designer or developer (or a designer/developer) who works closely with the client. Regardless, it never hurts to have an understanding of how things work, even if you aren't directly involved in them.

The toolbox

All the activities described in this chapter are optional. Just like our discussion of project management in the previous chapter, you have to do what feels right for you and your client. We suggest that the only activity that isn't optional is the first one; you need to have a discussion with the stakeholders on a project in order to determine your starting point. Most important, you need to know and agree upon what that finish line looks like.

If you need to get things straight in your head, you can do some of these activities without your client. Others are better to work through with your client so that you're both on the same page. If you feel strongly about something, be prepared to defend your position. If your client insists on using the Comic Sans font throughout their entire website, you're going to need a better argument than "No, it's ugly and unprofessional" to dissuade them (even though we all agree with you). Just consider this a little advance warning.

Goals and objectives discussion

The first order of business, once you've landed a project, is to sit down with everybody involved and have a quick discussion about some of the basics of the project. This is often called the project kickoff meeting. In addition to hashing out the details of a timeline and a budget, there are a few key questions that are helpful to have answered. A lot of these questions overlap in some way; that's OK. Sometimes it helps if people think about them differently and phrase their answers accordingly. You can handle this step remotely if you need to by forwarding a "questionnaire" to your clients, but it's generally faster and easier to schedule a one-hour meeting with everyone involved in order to answer these questions:

• What is the goal of this project? The answer to this question should be a little more specific than "to build a website." Why are you building a website? What is the purpose of the website? Are you trying to sell something? Are you trying to provide better customer/technical support to your customers? Goals are often difficult to identify because they're sometimes really nebulous. Another good way to phrase this question is, "If I told you that no matter what your budget and no matter what your timeline, I can build only one thing for you, what would that be? Would it be a set of pages where products can be purchased? Would it be a blog?" This generally gets people focusing on what the biggest problem is that you're trying to solve by building this website. Most websites should have no more than one or two goals; anything more, and you're probably looking at something that's too complex for a single project.
• What are the objectives of this project? Again, keep it general. (Note there is a difference between general and vague; these objectives will help you define scope, so lay them out in such a way as to be able to "check them off" a list. Try to identify specific user groups for each.) Things like "Give the media a place to get information about our company" and "Provide our agency with a professional online presence" are the level you want to stay at. If you're meeting with a group from your client's company, this is the stage where every department can have their say. Sales, PR, customer support, and even the CEO may have some input as to what objectives they want to accomplish. Again, to re-phrase the question, try asking "What sorts of things can we do to accomplish the goal we've identified?"
• Can you provide a short description of this project? This should be a couple of lines long, maximum. Ideally this is the answer you would give if the company CEO ambushes you in the elevator and she asks you what you're working on. You get bonus points if the answer is in language that's simple enough for you to use to explain to your family at reunions. Wouldn't it be nice, for once, to be able to explain to your Uncle Irv that you do something more than just "make websites?"
• What are the benefits of doing this project? Will it save the organization money in the long run? Is it a good recruiting tool for prospective employees? Will it help the sales team move more products? This is the "dream big" section where everyone can pitch in their two cents about their biggest problems and how they're hoping this project will solve them.
• What's the scope of this project? This is usually one of the hardest questions to answer, because it's not entirely clear at the outset. Regardless, everyone will have some idea of what the end product will look like; it's good to get that out here.
• What are the deliverables? This can also be phrased as "How will we measure success?" The answer to this question may be as simple as "a completed website with supporting documentation," or it might be something a little more abstract like "an increase in our Google search ranking." Make sure that what emerges from this question is something realistic and attainable. If your client responds "to improve customer satisfaction," don't accept that at face value. How is customer satisfaction currently measured? Maybe it's the number of phone calls to customer support. If you decrease that number, have you improved customer satisfaction? How much does that number need to decrease? By at least 25 percent? If there's no existing measure of customer satisfaction, suggest coming up with some way to assess that before your project launches and then after. Maybe a customer survey is a good way to go.

We suggest sending these questions out a week in advance of your scheduled meeting. That gives everyone a chance to think about and jot down their ideas so that you can have a really productive discussion. It's OK to have debates and disagreements at the project kickoff meeting, and they may turn ugly, but it's better to get it out of the way at this point rather than on the day you go to launch. Your role at this meeting will be to mediate it. Draw on your background, and try to propose solutions that will accommodate everybody.

Brainstorming

The term brainstorming is often abused in the business community and has gotten a pretty bad reputation as a result. There is a right and a wrong way to brainstorm, though, and doing it properly is an extremely useful tool for getting a flood of ideas. To brainstorm properly, you'll need a few things: a bunch of sticky notes (or index cards), some pencils or pens, and a countdown timer (Figure 3-1).

Figure 3-1. Pile of index cards generated from a brainstorming session on "ways to sell more widgets." This pile now gets organized and grouped.

Clearly outline what you're working on so that everyone is on the same page. It may be a broad topic such as "technical/functional features of our new website," or it might be something specific such as "ways we can promote the launch of our new service." Tell everyone in the group that the next minute is just about getting ideas out there; it's not about discussion (that will follow). Everyone should write their idea on a sticky note (one idea per note) and call it out as they are writing it. No idea is stupid at this point, and it doesn't have to be completely clear what the idea is—just something memorable so that the thought won't be lost.

Set the timer for one minute, and tell everyone to start. As the leader of this activity, you shouldn't participate; rather, you should "police" the activity. Make sure people don't start talking about the merits of an idea while the timer is running. There should not be any judgments being made on ideas at this stage, so "That's dumb" or "Forget about that" should be strongly discouraged.

Calling out ideas will reduce the amount of duplication you get out of this activity, but inevitably you'll still get some duplicate ideas. It also serves to spark ideas in others, so if one person calls out "professional product photos," then that may spark the idea of "multiple product angles" in someone else. Once the timer runs out, get everyone to sit back, and collect all of the index cards. Read each idea to the group while you have everyone's undivided attention, and if anything is a little ambiguous, ask the contributor of that idea to clarify their thinking (write it down). At this stage, weed out any duplication of ideas that may have occurred as well.

Once the list has been pared down, start grouping ideas. So if you look at our "ways to promote our new service" topic, you might group the ideas by "cost money" and "free." Then you might further break them down into "online" and "offline" media. It's at this stage that ideas can be discussed and the advantages and disadvantages of each can be explored (see Figure 3-2).

Figure 3-2. Once the brainstorming session is complete, take some time to group similar ideas together and give them some structure. Eliminate any ideas that are clearly bad (as a group, make a judgment call) or impossible to implement, and feel free to add anything new that comes up.

User stories and user personas

User stories and user personas are similar in that they call for you to get inside the head of your end user and describe what they need or what they're thinking or doing at any given moment. A user persona involves creating a fictional character, which you envision is one of the target users of your website. You then create a profile and background information for this person, describing their age, occupation, technical background, and likes and dislikes. The biggest benefit to developing user personas is that they're great at serving as a reminder that you're not (necessarily) developing a particular website for yourself. Because of this, create your personas in such as way that they can serve as a constant reminder to the project team throughout the entire design and development phase. If you construct personas and then file them away, they aren't going to do anyone any good.

We think that there's a fundamental problem with personas, though, in that you're inventing a fictional character to deal with a real-world situation. If you're a 29-year-old male, you probably can't imagine what on Earth an 18-year-old female would think of a website you created. If you have a background in computers, you might have a tough time seeing what a website would look like to someone with little or no computer experience (such as your grandmother). Trying to determine fact based on fiction just seems counterintuitive. If the target user group of your product will be someone outside your realm of understanding, then we recommend involving someone from that target market in your project team. You don't have to bring them in immediately, but once you have something they can interact with, if even in a limited capacity, have them take a spin around your website and give you some feedback.

User stories (sometimes called use cases) look at individual needs of a user or features of the website you intend to produce. This is another great activity to complete as a group, and it's an even better activity if you can involve individuals from your target audience.

Start with a stack of index cards and ask everyone to start writing down features or functions of the website that they see as essential. They need to be really concrete, such as "a five-star product rating system" or "people who purchased product X also bought product Y." Things such as "an easy-to-navigate website" are too broad. If the title alone isn't sufficient, ask people to write a short paragraph of what they mean/envision; drawing diagrams is OK too. The real purpose is to clearly capture any and all ideas.

Give your group 20 minutes or so to produce their stack of cards and then come together as a group to discuss what everyone has come up with. Eliminate duplicates (if applicable), and then discuss the priority of each story (high, medium, or low). If there are disagreements over the priority of a particular story, the person who wrote the story gets to decide.

After you leave the meeting, assign an ID number to each story, and estimate how long it would take to develop this feature (see Figure 3-3). It could be something like three days or one hour. You can now look through your stack of stories and quickly see what's really important but really easy to do, what's really important but really hard to do, and what's not so important but easy or hard to do.

Figure 3-3. Completed user story indicating ID number (57), priority (high), and effort (3 days)

We find that user stories help us answer the question of "What's next?" We talked about taking care of the core of the website first; that is the single thing that the website needs in order to function. What do you work on after that? Start tackling your high-priority stories, starting with the least time-consuming ones and proceeding through to the more time-consuming. Then attack the medium-priority stuff and finally the low-priority stuff.

It's normal to add user stories throughout the life of an agile project or to make revisions to the priority or effort (maybe implementing the user database for the forums has made single-click checkout really easy to implement). Feel free to keep revisiting your stack and making additions and updates as required.

Feature/unfeature list

Brainstorming and user stories are a great way to get the creative juices flowing with everyone, but all of the ideas generated may not be what's best for your website. Also, although it's important to know what the competition is doing, you shouldn't let it dictate your work. Just because your biggest competitor has introduced live video chat on its website doesn't mean you should do the same. Heck, let your competition do the market research on it and spend the money figuring out whether it's a killer feature. What you're producing should stay focused on your end user and what they need. Keep it simple; you can always add things later.

The feature/unfeature list is exactly that: a list of what you must include in your project to make it useful and successful and a list of what you aren't going to include. Although that seems like a silly notion, why should you bother creating a list of what you're not going to do? It can really help to define what you're working toward. It can also really help with scope definition and in determining the budget and timeline for a website. If you can get everyone to agree up front that you're not looking to develop a music player, when that pesky VP of marketing all of a sudden decides to get involved with your project and asks where the music playback controls are, you'll be able to point to your unfeature list and say that it hasn't been overlooked but was discounted earlier in the process.

For example, say you've been asked to create a social application that focuses on music. Your feature/unfeature list might look like Table Table 3-1.

Table 3-1. Example Feature/Unfeature List

This project is...	This project is not...
A stand-alone web application	A Facebook application
A place where fans can come to discuss their favorite bands	A place where fans can come to trade audio files of their favorite bands
A news resource for upcoming CD releases and concert dates	A news site providing interviews and general information about bands
Meant for individuals who are at least 18 years of age	Meant to be a hangout for pre-teens to discuss the latest American Idol
About the music, the artists, and the fans	About the money (as long as we break even)
A place for discussion	A file-sharing outlet

This list gives you some clear direction as to what the project team wants to avoid and what it expects the end product to look like.

Wireframes

You can think of wireframes as the thumbnail sketches of the web world. Wireframes are outlines of your pages using lines and boxes to represent where various elements will be placed (see Figure 3-4). Their primary purpose is to get the team focusing on content, functionality, and navigation (or flow), not on appearance. They are extremely quick to construct; in fact, a number of designers we know don't even bother using a computer. They'll simply sketch them on a piece of paper, which they will then scan and send off to a client for feedback.

Figure 3-4. Basic wireframe showing the various parts of a page. A number of great templates are available on the Web for constructing wireframes.

If you mock up a page in Adobe Photoshop using stock photos and placeholder graphics, we guarantee you that the majority of the comments you will receive will focus on the images you selected or the shade of yellow you used for your highlights. We once did a mockup using "Lorum Ipsum" text, only to have it returned from the client with the comment that their website will need to be in English. Go ahead and roll your eyes, we did. It can be really frustrating when, despite your best efforts, your client still focuses on the wrong thing entirely. Do what you need to do to center their attention. If it means removing all text and replacing it with dashes, or replacing images with gray boxes, do it.

In removing graphics, colors, and text, you force individuals to focus on the layout and content of a page. This activity is designed to get people thinking about what placement leads to the best interface for your pages and the nature of the content they will contain. Questions such as "Does it really make a lot of sense to split the navigation between a horizontal bar along the top and several vertical columns of links?" will come up at this stage. It's also common to hear remarks that the company's logo isn't prominent enough or that the content area doesn't have enough space.

The biggest drawback to producing wireframes is that it's difficult to display interactive elements. If you have a box that will expand and collapse, it's tough to represent that in a simple sketch. As Ajax becomes used in more and more places online, the notion of a "static mockup" of a page will be less and less useful.

Wireframes are really only useful in larger groups where you're trying to get everyone to focus on one thing at a time. If you're working one on one with a client, don't even bother with wireframes; cut right to the prototype. Let them see and work with the website in a browser; they'll be able to gain a deeper understanding of the right way of doing things.

Mock-ups

Several designers will still produce Photoshop mock-ups of a website for their client ahead of time. Some will even produce two or three variations so that their client can pick the one they like best. As you may have gathered, we think this is largely a waste of time.

For starters, only one of the variations you've produced will be selected, and then all the time and effort you put into the others will go into the great digital landfill. Why divide your time amongst several options? Produce one design, and make it the absolute best you can. Get everything pixel-perfect!

And then present it to your client in XHTML/CSS. We understand that Photoshop is ingrained in the designer's thought process. If you're one of those folks who need to start with a blank canvas in order to get your creative juices flowing, so be it. But take it only as far as you need. As soon as you have that vision in your head, start realizing it in a real-life web page.

Similar to wireframes, Photoshop is terrible at exhibiting dynamic content. You can flip layers on and off, we guess, but why spend the time? It's just as fast to code it and then make small changes to the code as needed. Going to code gets you thinking about the best way to produce a page, instead of the best way to replicate your Photoshop mock-up.

The best-case scenario is that designers can write code and coders can design like artists, but that's rarely ever the case. Chances are that if you're working in an organization that's big enough to have both designers and developers, the existing workflow will incorporate mock-ups. In cases like that, just make sure that once you have the mockups "converted" to something interactive that you work closely with your designer to review what you've done and whether it matches the direction they had envisioned.

Information architecture

Your goal with this activity is to lay out the site map of the website and also to come up with the nomenclature and taxonomy you'll be using (you haven't suddenly slipped into a biology textbook, don't worry). Will you be calling the page containing company "Contact Information," "Contact Us," or simply "Contact"? Maybe you'll go with the more casual "Drop Us a Line" or perhaps "Feedback." There's no right answer here; it depends on a number of factors.

If you're developing a new website, your best bet may be to surf around a bit and see what other people are using for their naming. Go to some of the biggest websites and try to draw parallels between their pages and yours. We're not suggesting here that "the big players" are always right; it's just that a great deal of people have been exposed to those websites before, so their naming schemes have caught on.

If you're redesigning an existing website, it might make sense to keep the existing labels for things. The existing user base has already invested the time to learn that when they click "Dude, hook me up," it means take them to the online store. It's a judgment call that will be guided by the goals and objectives of the website. If your client is hoping to rope in new customers, it might be smart to rename your links in order to lower the bar for entry. Deciding on navigation is one of the key decisions for the success of your website. Once you think you have it figured out, ask a neutral third party to see whether they "get it" too. On the other hand, if the main goal is simply an update in the look along with a dose of increasing sales to existing users, don't go hog-wild. Existing users are existing users because they like the site as it is. Don't risk alienating them with sweeping changes for the sake of change.

A typical site map is just a series of boxes labeled with page names (see Figure 3-5). If you find that your website is oozing Web 2.0 machismo and you have more Ajax than you have images, then number each of the pages on your site map and provide a paragraph or two describing some of the functionality and interactions on that page.

Figure 3-5. A typical site map showing the names of pages and their relationship to one another

Prototype

But that's not a tool, that's actual production work! It's crazy, we know, but getting to a working product is the single best design tool available. In a working product, there are no miscommunications or misconceptions. It's just the first step toward finishing a project. Sure, you may get absolutely everything wrong in the first version and have to change it all, but at least you know what not to do now. We want to pause for a second and just remind you that we're not presenting these tools to you in a particular order, but rather, as a collection from which you can pick and choose. The reason you should have this thought current in your mind is because skipping every step except the prototype can produce a successful project. We've launched a lot of wildly successful projects that had no up-front planning except for preliminary discussions and a prototype that eventually evolved into the final deliverable.

Start simple; don't even worry about the design for the first little while. White backgrounds and black text with simple text links are just fine for laying out a product and getting a feel for how things go together. Create some basic pages with titles (and content if available), and start building the hierarchy (see Figure 3-6).

Figure 3-6. A prototype doesn't have to be fancy. Start simple, and add to it as you go along. Separating presentation from content (using XHTML and CSS) will let you make changes to the look quickly.

Elaborate as you go along. Drop the company logo into the corner of the page; let your client tell you whether it's too big, too small, or the wrong shade of purple. Keep a list of the changes requested so that you don't let anything slip through the cracks. Better yet, let your client make the list for you. Tools such as Basecamp or Trac (which we discussed in the previous chapter) will let you add to-dos or tickets to keep track of what has been requested and what has been accomplished.

Let's go to an example

Hey, congratulations! We heard you just landed a contract with this hot new startup in Silicon Valley to produce a sales website for its hot new Web 2.0 product that it's launching in a couple of months. That's awesome!

You're a little freaked out? This is your first major project besides that softball website you put together for your Uncle in Cleveland last month? Don't worry about it; let's walk through the initial stages together.

OK, so you already know that the startup has scheduled the launch of its service to take place in two months (60 days). Being the entrepreneurs that they are, they're still on a bit of a tight budget, but they've managed to scrape together $2,000 for the project. You're just starting out in your career anyhow, so you're charging your standard rate of $20 an hour. You're reasonably confident that you're going to be the only one working on this project, and it doesn't sound like they need anything too complex (in fact, "simple" came up 35 times in your initial conversation with them!).

So, where do you start? Well, this book you read once suggested that the best way to start a project is with a project kickoff meeting. It's lucky for you that you're taking a vacation to the Silicon Valley area next week, and you've already set up a time to swing by their offices. (Man, this project is just one lucky coincidence after another!) What on Earth will you talk about, though?

First things first. You've been talking exclusively with the CEO and VP of marketing. You fire off a quick message to them thanking them for their business and confirming the date and time of the meeting. In this message, ask them who you will be meeting with, and suggest that they include anyone who may have a stake in the project. At this stage, leave it wide open; it may be useful to have some of the folks who actually developed the product on hand. Along with this e-mail, you forward the six questions outlined in the "Goals and objectives discussion" section. Ask them to take some time to think about them in advance and jot down a few ideas. Also request that they forward these questions to anyone who will be in attendance.

Fast-forward one week, and you're on-site with your clients. After brief introductions, you jump right into the meeting. Luckily, everyone is well prepared, and you're able to zip through the six questions with little disagreement or conflict. Something interesting does emerge from the discussion, however. The management team is concerned about how they are going to receive feedback from their customers and suggestions for improvement so that they can continue to improve their product.

It's the perfect time to break out the second weapon from your arsenal and engage everyone in a brainstorming session. You set your timer for one minute, hand out a pad of sticky notes and a pen to everyone in the room, and remind them to focus on their customers. Who are they? What is their level of expertise? And go!

Ideas start flying back and forth, and everything from "a toll-free hotline" to "a user discussion forum" to "a wiki" are tossed onto the table. Time runs out, and you collect all the notes and head over to the wall to start grouping them.

One by one, you read each idea aloud, asking for clarification when necessary. You group them by level of technical knowledge required, ranging from "little to none," as is the case with the toll-free phone number, to "advanced," as with the wiki.

There is something intriguing about the wiki idea, however. People in the room start to talk about it and thinking out loud that it could enable the company to drastically reduce support costs, allowing "pro" users to help out new customers. Company staff would need to swing by only occasionally to answer the "dead-end" questions.

You sit back for a minute and reflect that it's not completely unreasonable to include this in the original project. There's already a bunch of really great wikis out there; it would really just be a few hours of work to integrate one into your client's website. You know that they have a hard $2,000 budget limit, but you're pretty sure that you can shuffle some things around. You pipe up telling them that you'll take care of it, no additional cost.

You've set the right tone for the project. You've established that you care about your client and their success and that you're willing to do what needs doing to produce the best possible finished product. You leave the meeting feeling great about the way things went and with a promise to get back to your client soon with something for them to see.

Two weeks later (remember, you were on vacation), you send your client a link to a prototype you've put up on your testing server. They immediately start clicking through it and sending you comments about what they like and dislike.

Summary: achieving balance

Your goal in the planning stage is to get a better idea of what the finished product will look like. Don't expect a photograph right out of the gates, but an abstract sketch is a good objective. The tools outlined earlier are really nothing more than a few standard ways of communicating with clients that may help you to get thoughts across. If you feel the need, you can repeat any of these exercises at any point during project development. It may prove interesting to see how things have progressed over the course of a project.

Don't feel obliged to run through everything outlined here as if it's a road map to project bliss. Before you begin any of these activities, ask yourself whether you (or anyone on the project team) will ever look at the output of these activities ever again. What is the point of developing an information architecture/site map if it's going to be completely ignored when you produce your prototype?

A really important point to note is that none of the output of these activities should be considered "locked-in" material. The agile project dictates iterations and changes once more information has been discovered. If someone creates a user story outlining the need for a discussion forum and it later becomes evident that nobody is interested in using a discussion forum, ax it.

Profiling Professions: Daniel Burka

Daniel Burka is well known throughout the web community as a pioneer in Web 2.0 design. His exceptional implementation of a clean and simple design for the wildly popular community news website, Digg.com, as well as his ongoing efforts to incorporate community feedback in order to constantly improve and evolve Digg, have made him a sought-after designer and speaker.

His latest endeavor, Pownce, is another hit by offering users an extremely easy-to-use interface to share files, links, and events within a network of friends.

Lane: Give us a rundown of what you're working on these days.

Burka: By day, I'm the creative director at Digg, and by night (and in all my spare time) I design the user interface for Pownce. Being the creative director at Digg means that I manage a small team of designers who handle all of the user interface tasks on the site. I work closely with Kevin Rose, Digg's founder, to spec out concepts, determine how features will be incorporated into the interface, and generally defend all things related to the user experience. The role I play at Pownce is similar, though we have a tiny little team, and I spend a lot more time developing new things than refining existing features.

Lane: Tell us a bit about your background: things like education and work experience that led you to your work in web design.

Burka: I luckily stumbled into web design when I was in high school. My twin brother and some friends were experimenting with graphic design tools, and I joined in. We then discovered we could make some easy money in the summers doing government-sponsored web projects through a Canadian government program. Over a few years, that group of friends coalesced, and we formed a company called silverorange that eventually evolved into a very strong web development shop. I actually studied history at university and eventually (eight years in!) got a BA with a minor in art history. I think this academic education helped me in many ways, but I learned most practical design practices through trial and error with my friends at silver-orange.

Lane: Step us through the process you went through when you were designing Digg.com. Where did your initial ideas come from?

Burka: Starting Digg was actually somewhat intimidating because it was a very large project already at the outset. Instead of tackling the whole thing at the beginning, I tried to identify the core component that made Digg unique, which were the story items on the home page. I isolated that one part and spent several days breaking it down, reorganizing the pieces, and developing a visual language. This groundwork established many ideas that percolated through the rest of the site as we increased our scope.

Lane: What are some of your favorite websites and why?

Burka: A List Apart: fantastic content that's well organized in a layout that happens to be very attractive. Those attributes are important in precisely that order. Apple: Apple's ability to keep the home page as a single focused element is impressive. CNN: I don't agree with every design decision on CNN's site, but the evolution of the CNN website has been impressive over time.

Lane: What advice do you have for people just getting started in working with the Web today?

Burka: I'd advise people to find a tight group of like-minded people to work with. Whether you're attending a design school or starting out with a small business, finding a group of people that you can bounce ideas off of, receive critiques on your work, and generally have fun learning together is an invaluable resource. It's certainly possible to learn web design on your own, but I doubt it's as productive or as much fun. Oh, and take Jeffrey Zeldman's advice—get half your money up front.

Lane: What tools do you use when designing a website?

Burka: Start with a whiteboard, move on to Photoshop, jump into the code in Coda. I can't draw with a pen and paper to save my life.

Lane: Web technology progresses pretty quickly. What are some of the ways you use to keep up on the latest trends in design and technology?

Burka: RSS feeds and talking to the right people. One of the great things about working on the Web is that almost all of the discussions happen online. I spent the first seven years of my web design career in eastern Canada, and we had no trouble keeping up with changes in the industry. Bloggers and sites like A List Apart really keep you in the loop.

Lane: If there were one thing you could completely change about the Web (or add/get rid of), what would it be?

Burka: Obviously, it'd be a fundamental shift, but getting rid of the statelessness of the Web would make a huge difference. Being able to haphazardly jump back and forth through a website using browser controls makes us do all kinds of weird design decisions that we don't even think about much of the time.

Lane: Where do you see things going with the Web in the next couple of years? What are you excited about?

Burka: I'm excited about the renewed potential of the mobile Web. People have been predicting the rise of mobile for years, and it's finally starting to show some promise. And, the best part is that, with devices like the iPhone, the gap between mobile and standard web experiences is narrowed.

Lane: What can new web designers/developers do to get their names out there and get noticed?

Burka: Seriously, the first thing is just to do really good work. A long time ago, I was speaking to one of the best graphic designers no one has ever heard of, and he told me that if you do good work, everything else will work itself out. It was very good advice.

Better short-term advice is that you shouldn't sit around waiting for good work to arrive. If you have any extra time, develop fictional projects and experiments. The 37signals early conceptual redesigns of banking, shipping, and payment sites are great examples. This will help you build out an impressive portfolio even if you don't have impressive clients yet.