Website redesigns are vital projects that don’t happen often enough for most of us to get good at them. Developers and designers know exactly what they need to do, but struggle because the rest of the players often … don’t. Here are some guidelines for assigning responsibilities to make your next website redesign more successful.

Business requirements and vision: Client SME

The person who clearly understands and can articulate the desired business requirements for the website is the most important player in the project. The person who owns this responsibility  must deeply understand the competitive environment, advertiser needs and reader behavior. She must be able to synthesize these elements into clear business outcomes for the site.

Inward-looking outcomes are much easier to articulate, but only outward-looking outcomes belong in your requirements document.

An inward-looking outcome might be “Grow revenue per thousand page views (RPM) on article pages from $20 to $35 within 6 months of the redesign launch”. This is a good description of the metrics that will be used to measure the success of the redesign. However, it offers no help to the designer or developer.

Instead, couch requirements from the perspective of advertiser or subscriber (outward) outcomes. For example:

“Make advertising more welcome by giving advertisers multiple opportunities to communicate with readers who have demonstrated interest in their class of product or service.”

“Remove friction from the registration process by allowing readers to register for any offer on the site without needing to re-enter information already stored in their profile.”

Use web analytics to identify where the current site blocks the outcomes you’re looking for, like newsletter registrations, ad click-thrus, or paid content purchases. You should also use analytics from your email system and your ad server to get the full picture.

Rather than relying on anecdotal information about competitors, use inexpensive or free services like Compete, Quantcast or Google Ad Planner to understand who your competitors really are. These services can open your eyes to new websites that are taking readership from you even though you’ve never considered them a competitor.

It’s critically important to keep business requirements from drifting into the “how”. If your business requirements start specifying a technical or design solution, they are no longer business requirements. The person who owns this initial part of the project knows more about the business than anyone else. They need to make sure all the other players get maximum value from that knowledge. If they start coming up with suggestions for how requirements should be met, they are shirking their responsibility.

Reader requirements: Content Marketer/Editor

The needs of the reader or audience are often overlooked in the redesign process. The content creator should understand her readership better than anyone else in the organization. It’s her role to advocate for the reader in the redesign process.

Unfortunately, this advocacy often devolves into the dreaded “focus group of one” approach, where the content staff considers their ideas fully representative of reader needs. Instead, do the research.

If you have good analytics and someone who knows how to interpret them, you can uncover insights into what users want or need based on what they really do. You’ll draw conclusions from the data that you might not have found otherwise. If these suggest a new feature or editorial direction, then go confirm the validity of your conclusions by speaking with readers.

Reach out to and speak with readers who match your most important target demographics. Bring some readers into a focus group/usability study with some preliminary design ideas. Ask them whether your company’s brilliant product idea actually resonates with them.

Reader requirements are at least half of the functional requirements document.

Functional requirements: Product manager or technical project manager

I’ve written before about how to build a website requirements document, but not about who owns this task. In a small company, it may end up being the marketing manager or an IT staffer. In a larger company, a digital product manager or a technical project manager may fill the role.

Whatever the title, the person writing the functional requirements document is the “bridge” between the business requirements and the technical capabilities available. That means this person must understand the business needs in the context of what is both possible and sensible on the technical side.

This isn’t easy, and can result in some nasty “blame the messenger” situations if the role and expectations for the functional requirements are not clearly understood by all the players. It’s not unusual for the business side to adopt a “don’t argue with me, just build what I tell you” attitude, because they are the ones who are held accountable for the business success of the site. If your “bridge” guy and technical teams are good, then the business side should back off and let them do what they do.

Design: Designer

This seems pretty obvious, but it’s hard. Marketers who willingly modify their ideas in the face of technical constraints often have a much harder time letting go of micromanaging the design of their website.

The business side needs to be deeply involved in producing the creative brief. If they’ve done their part with this, and have a good designer, then it’s time to let the designer do their job. If they’ve neglected their role in the creative brief, or haven’t hired a good designer, the end result will suffer.

Even a good designer can be motivated to do better work by allowing them the time (and budget) to conduct usability testing as part of the design process. There are tools that make this cheaper and easier than it was even two years ago.

For example, most web analytics packages show you the frequency of clicks on a page in a way that can uncover hidden usability problems. “Heatmap” programs like clickdensity and clicktale combine clicks, cursor hovering and mouseover data to provide a picture of how people are using a page. This has many of the benefits of eyetracking studies, but doesn’t require you to gather people in a room and hook them up to eyetracking gear.

For more on how and why to produce a creative brief, you may want to look at “How to write a website creative brief”.

Site functionality: Developer

If you are adding significant new functionality as part of your site redesign, your developer obviously needs a great functional requirements document to work from. Some organizations add another step and create a technical requirements document. Unless you’re doing a lot of bleeding edge stuff or launching a new web content management system (CMS) at the same time, functional requirements should be sufficient.

It’s easy to get used to treating developers and what they do as a black box. Most every developer I’ve worked with has been very smart, not just about programming, but about coming up with new solutions to business problems. Let your developers own the “how” part of the redesign process.

The ideal situation is to bring your developer into the conversation early in the process of fleshing out requirements. This allows him to understand enough of the business goals to go beyond the “our system doesn’t do that” to “here’s another way we could accomplish the same thing”. If you only involve your developer at the end, or if you allow the business side to stray into the “how” of things, you will miss out on these insights.

Supporting players

It’s common for many more than four people to be involved in a  website redesign. Getting useful, considered input from lots of people can be very valuable. However, if you create a committee approach to decision-making, your redesign will be late and unfocused. It’s better to get input from lots of folks, and then leave decisions to the people in the roles listed above.

A version of this post originally appeared on eMedia Vitals.