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. But please don’t call us hypocrites now that we’re offering you an entire chapter that covers 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. The temptation might be there to simply do what the client wants, collect your paycheck, and walk away; however, it’s far more fulfilling to work on projects where you can see the value that will be produced and where people will actually 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; you especially don’t want 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, after working through some of these sections, you will draw similar conclusions and move forward as a united front with your clients. 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’s, your clients are the experts in their field. They know their customers, employees, partners, and business processes better than you do; 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, he is 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 as with 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 to determine your starting point. Most importantly, 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 her entire website, you’re going to need a better argument than “No, it’s ugly and unprofessional” to dissuade her (even though we all agree with you). Just consider this a little advance warning.
Remember all of those times in school where your teachers would pester you to “cite your references” and “defend your position”? Unlike calculus, those skills they taught you are actually useful in real life. There really would be no arguing with you if you came in with a research paper discussing the poor readability characteristics of the Comic Sans font.
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 kick-off meeting . In addition to hashing out the details of a timeline and a budget, you will find it helpful to answer a few key questions. 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 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 and what is its purpose? 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 like this: “If I told you that, no matter your budget and no matter 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 to focus on the biggest problem 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, and you should consider breaking it up into stages.
- What are the objectives of this project? Again, keep it general. (Note that there is a difference between general and vague; these objectives will help you define the project’s 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 rephrase the question, try asking “What sorts of things can we do to accomplish the goal we’ve identified?” or “What is your vision of what the end product will look like?” These can be really fun questions to ask in a room full of people with different backgrounds (hint: if there are 10 people in the room, expect 10 different answers!).
- 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’s CEO were to ambush you in the elevator and ask you what you’re working on. You would get bonus points if you were to phrase the answer in language that’s simple enough to get the point across 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”? This question really helps to answer the peripheral question of, “Why are we doing this?”
- 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 his two cents about his biggest problems and how he hopes this project will solve them. If the room goes silent at this point, it can be interesting to approach this question from the opposite direction: what won’t this project accomplish? In other words, ask for the “anti-scope”—things that will not be solved by what you’re going to produce. Having limited knowledge of the organization, it will be easier to get the ball rolling by throwing out some completely absurd suggestions (this website will not solve illiteracy world-wide).
- 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, so it’s good to get that out there. Again, you can hit this question from the opposite direction. This differs from the prior question in that we’re looking for something a little more specific and concrete.
- 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, such as “an increase in our Google search ranking.” Make sure that what emerges from this question is something realistic, measurable, 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. A customer survey might be a good way to go; you also might be able to come up with some key statistic you can use.
We suggest sending these questions out a week in advance of your scheduled meeting. That gives all the participants 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; however, it’s better to get these 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.
We mentioned at the outset that this meeting should take an hour. In general, the more people involved, the longer it will take. Regardless, set a one hour limit on the meeting and make it a goal to get through as much of this material as possible. If you need to schedule a follow up, that’s OK; however, don’t let this meeting stretch into a two or three hour marathon. Nobody will be putting forth her best ideas after an hour.
You should also plan on bringing an audio recorder with you. Or, you might have a co-worker accompany you to take notes. You’re not going to have time to both furiously write things down and participate in the discussion. You want to be available to take part in the answers to these questions, not just passively record other folks’ opinions.
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 (see Figure 3-1).
Figure 3-1. The high tech toolbox you’ll be using in this chapter. Sometimes getting people off their computers helps with creativity!
It’s important that you clearly outline what you’re working on, so that everyone is on the same page. It may be a broad topic such as “the 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 on the topic; it’s not about discussion (that will follow).Participants should write their ideas on a sticky note (one idea per note) and call them out as they write them. 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” or even “hey, great idea” should be strongly discouraged.
Calling out ideas will reduce the amount of duplication you get from this activity; but inevitably, you’ll still get some duplicate ideas. Calling out ideas 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” from someone else. Once the timer runs out, get everyone to sit back while you 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 her 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.” Next, 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. Group the ideas by similarity. This will help focus the discussion on what’s feasible, and what’s just a pipe dream.
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 users and describe what they need or what they’re thinking or doing at any given moment. A user persona involves creating a fictional character whom you envision is one of the target users of your website. You then create a profile and background information for this person, describing her 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. Thus you should create your personas in such a 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 facts 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 this person in immediately; but once you have something that person can interact with, even in a limited capacity, you can have him take a spin around your website and give you some feedback.
User stories (sometimes called use cases ) look at the 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 the participants to start writing down features or functions of the website that they see as essential. The ideas 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 that spells out what they mean/envision; drawing diagrams is OK, too. The real purpose of this exercise is to clearly capture any and all ideas.
Give your group 20 minutes or so to produce its 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 also 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. A completed card. Number these cards for easy reference, estimate a time, and then assign a priority based on group consensus.
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 ones. Next, 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 (perhaps 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.
Brainstorming and user stories provide great ways to get everyone’s creative juices flowing; however, 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 users 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, as well as a list of what you aren’t going to include. That might seem like a silly notion—why should you bother creating a list of what you’re not going to do? However, doing so 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, you’ll have a ready answer 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. Specifically, 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 what is shown in Table 3-1.
Table 3-1. An 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.
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 focused 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. The goal of a wireframe is to focus on the layout of the elements in a page. Stay away from using colors and graphics, and just use boxes to represent various elements.
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 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 the 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), then 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. At this stage, you’ll hear 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?” 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 (or, unfortunately, that there isn’t enough room for advertising).
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. You can use arrows to indicate motion of elements, but showing the expansion of a particular element can be challenging on a single page.
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. Instead, let the client see and work with the website in a browser; he’ll be able to gain a deeper understanding of the right way to do things.
Several designers will still produce Photoshop mock-ups of a website for their clients ahead of time. Some will even produce two or three variations, so that their clients 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, so all the time and effort you put into the others will go into the great digital landfill. Why divide your time among several options? Instead, produce one design and make it the absolute best you can. Get everything pixel-perfect!
And then present it to your client in HTML/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 to get your creative juices flowing, so be it. But take it only as far as you need to before jumping to code. 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. Another big benefit of the “straight-to-code” method is that it introduces the constraints of designing for the web immediately. We’ve had several designs handed to us that use commercial fonts that aren’t widely available. Short of producing graphics of all of your text (do not do this), there’s just no way to implement that design online.
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, if you’re working in an organization that’s big enough to have both designers and developers, then the existing workflow will incorporate mock-ups. In cases like that, just make sure, 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 he envisioned.
Your goal with this activity is to lay out the site map of the website and to come up with the nomenclature and taxonomy you’ll be using for links (you haven’t suddenly slipped into a biology textbook, don’t worry). Will you be calling the page containing company information “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 schemes. 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 users already know that when they click “Dude, hook me up,” it means your site will take them to the online store. It’s a judgment call that will be guided by the goals and objectives of the website (perhaps one of the objectives is to increase sales; making it easier to find the link to your online store might help that!). If your client is hoping to rope in new customers, it might be smart to rename your links to lower the bar for entry. Deciding how to implement your site’s navigation is one of the key decisions that will impact the success of your website. Once you think you have it figured out, ask a neutral third party to see whether he “gets it,” too. On the other hand, if the main goals are simply to update a site’s look and increase sales to existing users, then 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 site map can be a great way to identify content for the web site and to work out how site navigation should function.
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 currently 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. That said, there’s nothing stopping you from calling a brainstorming session after a prototype has been built. If you’ve got that sinking feeling that not everybody’s voice has been heard, then call on those people. It’s better to do so late than never.
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 then start building the hierarchy (see Figure 3-6).
Figure 3-6. Simple is fine in the early stages. This prototype is just using the browser’s default styles. If you’re trying to work out site structure, that’s fine! The links to other pages are all there, and there’s no styling information to distract you.
Elaborate as you go along. Drop the company logo into the corner of the page, and let your client tell you whether it’s too big, too small, or the wrong shade of purple. Also, 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.
Hey, congratulations! We heard you just landed a contract with this hot new startup in Silicon Valley to produce a sales website for its cutting edge 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). The startup is composed of entrepreneurs, so it is still on a bit of a tight budget. However, the company has 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 the company needs anything too complex (in fact, “simple” came up 35 times in your initial conversation with its people!).
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 the company 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 these people, thanking them for the company’s business and confirming the date and time of the meeting. In this message, ask these people whom 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 these people to take some time to think about the questions 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. You start up the voice recorder on your phone. 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 it will receive feedback from its customers, including suggestions for improvement, so that it can continue to improve the company’s 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 those gathered 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 the ideas by the level of technical knowledge required, ranging from “little to none” (e.g., the toll-free phone number) to “advanced” (e.g., the wiki).
There is something intriguing about the wiki idea, however. People in the room start to talk about it and remark that it could enable the company to drastically reduce support costs, allowing “pro” users to help out new customers. The company’s staff members would need to swing by only occasionally to answer the “dead-end” questions and add in their pro tips. Additionally, it’s widely agreed that, because of the nature of the product, most users will likely be pretty technical, so a wiki isn’t likely to scare them off.
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 open source 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 those assembled that you’ll take care of it for no additional cost.
You’ve set the right tone for the project. You’ve established that you care about your client and its 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 once you have something worth seeing. Now it’s time to visit the wine country, and enjoy the rest of your vacation!
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. The client immediately starts clicking through it and sending you comments about what it likes and dislikes. Communication continues back and forth, with you posting messages to Basecamp about what you’re currently focused on and where you’d like feedback. Something seems to click with this project, and there aren’t a lot of revisions. You end up finishing ahead of schedule.
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—then ax it. Constant improvement is the order of the day, and no decision is so big that it can’t be changed after the fact.
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—and his ongoing efforts to incorporate community feedback to constantly improve and evolve Digg—has made him a sought-after designer and speaker.
After Digg, Daniel went on to work on Pownce, and then to Milk to focus on mobile application design. He has recently accepted a position at Google. This interview is from a few years ago, when Daniel was still at Digg/Pownce and his thoughts very much still apply today.
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 silverorange.
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 from, and generally have fun learning together with 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.