Building Web Sites All-in-One For Dummies® (5 page)

Brainstorming and evaluating your ideas

Like with any type of a project, the first thing you can do after you gather basic information about the needs of your internal stakeholders and external audience is have a brainstorming session. Do this alone or with the core team to get the ideas flowing with minimal complications. You can (and in many cases, should) have additional brainstorming sessions with the team. The important thing at this point is to write down everything that pops to mind.

After your brainstorming session, consider the ideas from that session in a more practical way. Compare what you have with your defined goals and reasons and start discarding things that just don't fit. Again, this part of the Web project is similar to many other types of projects. Web project managers can easily fall into the trap of thinking that because it's a Web project, all the work will be done on a computer, and old-school techniques don't apply. However, resist the urge to fall into that trap. Getting away from the computer and technology can help you focus on the purpose of your project and the content you plan to deliver without the distraction of the computer and technology.

Looking at budget and timelines

Even an inhouse project has a budget and a timeline. These things can change during the course of a project: Sometimes, deadlines can't be met or need to be pushed forward. Time and money, as in any project, are tied.

While you work on your first Web projects, you'll probably find that budgeting time and money is difficult. Projects usually are more complicated than they seem; even small projects need input from multiple individuals, and those individuals will need to agree and collaborate. Although we can't give you a magic formula for calculating how these changes and collaborations will impact your project, keep in mind the following guidelines when you're planning the budget and deadlines:

•
Clearly establish deadlines up front, specifying what elements team members will deliver on those deadlines and what resources team members will need from stakeholders for the project to continue on track.
Include information about what will happen if stakeholders or clients delay the project. When a client is responsible for delivering materials (such as photos or text) and those materials don't arrive on time, you can't proceed. Standard practice is to add the number of days the materials were late to the timeline. That is, if clients are two days late with text, the deadline pushes out two days.

•
Whether you're working as a freelance Web designer or as part of an internal team, put everything in writing.
This way, you avoid the “he said/she said” scenario that causes frustration and is counterproductive.

•
Use a
rush fee.
This is extra money that you charge if the client wants you to deliver the project faster than originally agreed. You can also use a rush fee when a client asks for a project on extremely short notice — for example, a client calls and asks you to create a minisite in only two days.

Considering collaborations

While you complete your planning, consider the possible reactions to what you're planning. For example, you might encounter opposition from individuals who don't think a Web site is a good thing. On the other hand, some overly enthusiastic people might want to pitch in and help. Try to think about the people who will be impacted by the project and be prepared to address concerns, using all the information you gathered to this point. Thinking of how (or if) you'll collaborate with those who want to help is a good idea, which can help you with the next steps — selling the idea and having a meeting to officially get things rolling.

Selling the Idea

Whether you work in a large, corporate environment or you're a freelancer/design firm, you need to sell your plan to the stakeholders. Remember,
selling
isn't a dirty word. You're not trying to get people to agree to buy something they don't need. In fact, if you've done your preplanning, your project will actually help them solve problems.

Be prepared to address the stakeholders' concerns while you point out how your plans will solve problems for them. Don't avoid discussing the negative points or other impact your project might have. You can gain respect and important feedback if you show that you're open to discussion and knowledgeable enough to know that the project is not all about fun and glamour.

In short, present your idea, answer their questions — and be prepared for their concerns.

Holding a Kick-Off Meeting

Another form of selling the idea, a
kick-off
is a meeting to get all the hands-on people involved. The main purpose for this meeting is to explain the project, set expectations among the members of the team, and give them copies of the scope document so they can review and understand fully what is expected. Additionally, open a discussion among team members, giving them an opportunity for sharing ideas and honing the plan.

When presenting your idea and defining the project, ask your team questions regarding feasibility and capabilities. Also, be prepared for their questions: After all, production people and IT folks need details to do their jobs correctly. Don't misinterpret their questioning as them “being difficult.” Also, try to understand any issues that are raised. Sometimes, features or functionality are possible but just not practical to create or support, so you might need to suggest a compromise. Work with your team to come up with the best solutions.

Make brainstorming ideas a part of the process. Allow everyone to give input about big-picture concepts on features and functionality. However, when the actual work begins, respect people's expertise. Writers should be the ones responsible for the written content; designers create the designs; and developers work with the code. It's great to share ideas, but team members doing each other's jobs is counterproductive. As a project manager, you should establish that collaboration is good, but second-guessing expertise creates friction and generally hurts the finished project. Make sure you hire the right people and then define the roles and build a good environment for teamwork.

The final task for a kick-off meeting is setting the next steps. Make sure all team members understand what they need to do after the meeting. Be clear about what you expect from each team member and give deadlines. A good way to start the project off right is to follow up with an e-mail that includes a summary of the meeting, a list of tasks, and an outline of expectations.

Revising Your Original Plans: Using Feedback to Improve

As a Web project progresses, it moves through a cycle of review, feedback, and revision. Each iteration of the project (hopefully) helps the finished product become better. Establishing project milestones (which we discuss in the earlier section, “Setting Goals”) is an important part of the initial planning phases. The milestones provide points along the way when all stakeholders can have a look at the site and give feedback about the progress.

Whether formal or informal,
usability testing
(asking people to play with the site to see what works and what doesn't) at key milestone points can provide useful feedback. To conduct a quick, informal usability test, select some people who are representative of your target audience (preferably, people not involved in the project) and ask them to try to use your site; then have them provide feedback about their experiences. In Book III, Chapters 9 and 10 contain more information about usability testing and getting feedback.

When you're asking others to preview the site — whether they're usability testers or internal stakeholders — make sure you label placeholder text and graphics clearly to let people know that placeholders are not part of the finished project.
Placeholder
items do just that in a layout — they hold the place while finished text and artwork are being created. A large, red, “For Placement Only” statement across a graphic often helps people stay on track while they review a project in progress.

Make sure you show your work to stakeholders whenever you make significant progress or hit a project milestone. They need to know that you're staying on track. Also, keep in mind that some of your stakeholders might not be able to envision the finished product. When you notice someone getting bogged down on a temporary item (such as a placeholder graphic), thank them for their feedback and then try to redirect their attention to items you do need feedback on.

Receiving feedback

If you're looking for a particular type of feedback, make sure you ask specific questions that prompt users to comment on the elements or issues you want to focus on. In general, it's not very productive to just send out a link with a note that says, “What do you think?” You'll get vague responses like, “Looks good!,” which is great for a final okay before launching a project but is not so good when you're midproject and looking for something more solid. In some cases, you might even want to direct their attention to a particular piece of functionality, such as the subnavigation or a new Flash presentation, and ask them to comment specifically about just that piece. Here are some tips that can help you get the information you need:

•
Don't ask for general feedback unless that's what you really want.
The best way to get a group of random comments and personal opinions (“I like it”) is to just send a link without any explanation, or with a vague direction (“Check this out”).

•
Make sure you ask for specific feedback from individuals based on their expertise.
Any Web project involves many details and many different disciplines working together. Make sure you have experts to help keep you on track. In other words, ask writers to help you proofread your content; trust designers to make sure your colors are working for you. Rely on experts you trust for detailed feedback on details specific to what they know.

•
Never assume that a person has nothing useful to contribute.
Although the finer details should be picked over by an expert, a fresh set of eyes is very helpful when looking at the project as a whole. Remember, your actual visitors don't have inside knowledge or expertise and will also be looking at your site from a fresh perspective. For example, we've even gotten great feedback from an 8-year-old child about some icons that weren't working. You never know who will have a useful tip.

•
Include a list of what's new since the last time you sent out a link for review.
Expecting people to play compare-and-contrast to figure out what you've been up to is neither polite nor productive. Keep in mind that most of your usability testers and sources of feedback are trying to look at your project and return comments between working on their own projects. They won't take the time to help you if you don't take the time to direct their attention to the important issues.

•
Make sure you don't ask for feedback if you can't use it.
If you know that you're locked into a particular piece of functionality or presentation, don't ask people to comment on whether it should be there. It wastes their time, and they might not want to help you the next time. Let people know up front about situations that are beyond your control. For instance, if you must display a particular logo in a specific place, include that information in your note requesting feedback.

•
Ask open-ended questions.
Try to come up with questions that will make people interact with your site and really think about what they are experiencing. You need honest input from people even if it's not a bunch of compliments. If you collect useful information and act on it, you will get plenty of compliments when you launch a great Web site.

•
Thank reviewers for their input.
Make sure you thank them for their time because you'll need to call on them again as your project progresses. Keep them interested in helping you. It's easy to forget this little detail when you're wrapped up in
your project, but people want to know that their time was well spent. Make sure you send out a follow-up after you collect feedback,
including a summary of the feedback and what you intend to do as a result of the comments given.

Giving feedback

Giving feedback can be trickier than getting it, so follow these pointers that can help you give feedback without stepping on any toes:

•
Take your time.
When you're evaluating a project to give feedback, take your time and look at the site. Your feedback isn't helpful if you immediately start reacting without taking a few moments to look at it and consider what you're going to say.

•
Stay polite, and don't get personal in a negative way.
Being polite goes a long way when giving feedback. People often forget that someone has put a lot of time and effort into her work, and no one likes to be criticized. Make sure that when you give feedback, you take that into consideration. Blurting out comments shuts down communications pretty quickly. Ultimately, it's the project that suffers for it.