Crown Computers’ Top 10 Tips for Your New Web Site Redesign

Table of Contents

Crown Computers’ Top 10 Tips for Your New Web Site Redesign

1. First of All Ask Why?  Developing the Short List
2. When You Hire Your Vendor - Get Ready to Do It All Again
3. Don’t Skip the Information Architecture Phase
4. Don’t Let the Project Manage Itself
5. Develop a Close Relationship with Your Content. It’s Quality not Quantity
6. In the Design Phase, Don’t Bring too Many Cooks
7. Don’t Try to Launch Everything the First Time
8. Simplify: When Designing the Workflow for Your New Web Site
9. Plan for Life After Launch
10. Have a Good Time!

It’s Spring - and it’s time for the Spring cleaning. What a great time to start that new web site redesign that you’ve been putting off. As you might expect, we have the pleasure of working with diverse clientele in the process of redesigning and ultimately managing their web site. Over that time period, we’ve certainly come to see some trends in what makes a redesign project succeed. So, to celebrate Spring, we thought we’d take our time in our busy lives to provide our Top 10 Tips that you can use whenever you’re about to embark upon a web site redesign project.

Our advice is not to redesign just because you want it to look pretty.  It is critical to define some specific projects that a new redesign is going to achieve when the site completed.  One of the main objectives to redesign could be to generate more leads or online revenue. Another compelling reason would be to save money on customer support issues or improve customer relations by means of communicating to your clients, prospective and cold leads. Another reason may be to improve self management of the site content without the need for experienced programmers and/or developers to get the job done for you.  It might be a new start up business altogether. The point is to clearly define a list of strategic goals that determine the compelling reasons for why the site will be redesigned. This will help you communicate your objectives clearly to your consultants or web development managers.

Once you’ve carefully thought this through, consider developing an "official" document which will explain the project and its desired outcome in detail. This Project Outline will be your requirements document as you gather all of the desired outcomes and new capabilities.  The Project Outline serves as a map to define a set of features, functions and services that you’ll require from your chosen solution. Many larger organizations choose to outsource the Project Outline phase to consultants with either vertical expertise and/or previous site design experience.

In general, the goals of this Project Outline is to outline:

1. The Scope of the Project: What this project will contain (wholesale change or design tweak).
2. The Goals of the Project: What we will achieve from a business point of view and how we will measure the success of the project.
3. The Key Deliverables: Is there a new Web site and a new CMS, or just a new site, or other functional items?
4. Key Assumptions Being Made: What key assumptions need to be made and dependencies outlined in order to satisfy the above deliverables.
5. Key People Involved: The key people and their role on the project.
6. Functional Requirements of the Project: These are the general benefits, not specific features. (e.g. "drive more leads and Search Engine friendly pages" NOT "XHTML compliant output")
7. Functional Technical Requirements of the Project: Keep these high level for now – but capture any critical items (e.g. must be Microsoft based, or must be able to scale separate of Web traffic).
8. Cost and Duration of the Project: Your budget and time line..

Once you have developed the Project Outline, there will typically be a natural prioritization in terms of the features, functions and services that your organization will require. Separate these, both in the document and in your selection process, into "product features," and "services/vendor" requirements. For example, you may have a strong need for implementation services, because your IT team has limited bandwidth or, in the case of some smaller organization is non-existent. Or, you may have strong product feature requirements such as workflow and auditing needs because you are in a regulated industry.

Developing the Short List

Once you have defined this Project Outline, it is time to develop a short-list of potential solution providers, and develop a Request For Proposal (RFP).

In general, as you develop your short list of vendors, it’s best to focus on matching a few key strengths/weaknesses with your Project Outline Goals:

Geography: Where are services available, and where are the teams for this particular project. If you’re in Chicago, do you really want to hire a design company that’s delivered and supported out of Denmark

Vendor Strengths: What is the vendor’s main strength? What are they generally good at? This isn’t necessarily feature/function types of strengths, as much as it is general core competencies. For example, some design agencies specialize in vertical expertise (non-profit or publishing industry experience) or have generalized horizontal expertise (e.g. online marketing services, design heavy, technology heavy, balanced) The key is to match your prioritized needs with vendors who align well with them.

Vendor Weaknesses: Of course no solution is good at everything. Resist the urge to make this just the opposite of the strengths above. These weaknesses may or may not be important to you. For example, a vendor might be particularly strong in the non-profit sector, but might be weak in their online marketing capabilities. But if non-profit expertise is important to you, and you have little or no need for online marketing, they might be a good solution.

In summary, develop a short list of vendors (typically no more than 4 or 5) and send them a version of your document as an RFP. Remember, vendors should proposesolutions - not just a list of qualifications.

Most web design vendors will want to walk through some version of what they call a "discovery phase." This will be a very similar process to the one you’ve already been through internally. But it’s good to do it again for a couple of reasons. The first is that you’ve missed something - guaranteed - and the design agency will help you find it. The second, is that you’re about to embark on a long journey with your new partner.  Along the lines of your journey with the vendor, make sure that you are on the same page is a sure way to increase your probability of a successful web project.

The deliverable from this process will be a final statement of work, timeline and budget estimate from your vendor. This shouldn’t be a 500 page document - but it should be an agreed upon framework of solutions and tactics for how to get there. It should detail the breadth of scope and priorities for phase one.

There is a natural tendency to skip the Information Architecture phase in any redesign project. This is a very critical phase of your website as it is being built - we highly recommend doing this step before starting on the website. A common thought would be, "well, our current content works now, so we can just apply that to the new design." Don’t do it. It’s key to developing a site that scales well, can be merged into a CMS well and that performs well over a extended period of time.

You certainly wouldn’t redesign your house without researching construction permits, or hiring an architect to draw out the blueprints for the renovations. The information architecture is a key piece of a web redesign project. Find out what’s going on with your web site traffic. Examine the traffic patterns and look at your content. Match up the IA with your business goals and don’t skip this very important step.

A website redesign is a project and, as such, should be managed with a well defined scope on both sides of the equation. The project should have a given budget, and a defined set of resources. Decide jointly with your team on a realistic schedule and manage expectations both internally to your stakeholders - as well as to the web development partner. Aggressive timelines will force you and your vendor to cut corners or bypass necessary consultation.  This is an important step to help increase your success rate.

A website redesign is the best time for a through audit of your existing content. Once you have a better understanding of your users expectations and needs, start to review and reorganize your website content as the project progresses. After you start auditing your web content, you’ll be able to assess the gaps between the current state of your website and the information architecture that will best serve your users.

If you’ve done the wireframes and information architecture processes correctly, the design phase shouldn’t be that big of a surprise. But, as with any design oriented project - this is where emotions start to really play a big role. Absolutely resist the urge to pick elements from each design - as there was usually a good reason that the designer didn’t do this to begin with.

And, while communication and buy-in are critical to the success of these projects, redesigns by committee should be avoided when possible.

Google is an excellent example.  Google is known to launch small, iterative functions for their sites frequently. During that phase, new features and ideas will come up during the design process.  It is critical to resist the natural urge to add additional items to the scope at this stage. The best route is to get something up and live - and then go back and start to work on the next series of projects.

As you start to put strategy to how content will be launched into the new web site, resist the urge to use technology to "herd the cats." If your workflow process is too complex or cumbersome, be prepared for resistance to adoption of a CMS and your new processes. The main goal is to get the new processes adopted throughout the organization. Keep it simple to begin with, and then add restrictions as people either violate something, or if it needs to be managed.

A well-implemented, but poorly maintained web site redesign will lead to a bad Web site over time. For sites that change frequently, this can happen quickly. It’s sadly ironic that the reasons for the web site redesign - to be more effective and easier to manage can also be that site’s eventual degradation.

Imagine an IT department who has a dedicated group of web experts; always ready to respond to any request by a Web site manager to adjust the CMS, fix the lead management, adjust the SEO, fix the design, and so on. Unfortunately, in most cases, this simply isn’t possible. Having an expert integration firm hanging around and writing a new scope of work for every system change can be untenable as well – even if you can find one willing and available to work on a site over many years.

An internal service is often used, but as we’ve said, it can be difficult for an internal group to develop expertise in the application and find free developer time, especially when rapid changes are required over and over again. But wait, didn’t we just say it’s a requirement to have good support and maintenance – hence the dilemma?

Of course, these problems are solved to a great extent by the software as a service (SaaS) model. But most organizations haven’t moved in that direction yet, and need to find a balance between internal service levels and cost/resource availability.

The other half of the ongoing management of a web site, and just as important as having developers working to adjust the site over time, is the web site "owner." Often this is the same person who manages the project implementation, who later trains new users, plans application changes, works with vendors, and supports site managers. Owning the web site is typically only a part of this person’s job. They often own all of the other online marketing pieces, email campaigns, analytics, and so on. They also may own responsibility for the site’s content. If so, we hope they have a team to help! Whether the application owner relies on an external team, an internal team, or a combination, that team needs to exist and be responsive. A service level agreement, even if it is just a simple, internally created document, is a great document work from. It will set expectations for everybody’s responsibility.

So the bottom line is this: don’t skimp on building post-launch services into the project plan and budget as you start your next project. Define the players and responsibilities in the immediate post-launch "tweaking blitz" and for the multi-year maintenance, upgrade, and modification program. It’s not the glam part of the project, but success in the support and maintenance phase will determine how long the application lives and how successful it is in the months and years post launch.

All too often web site redesign projects are taken way too seriously. This should be a fun and interactive process for everyone - and can be extraordinarily successful for the organization. If you set expectations early, manage the project closely - and make sure everyone communicates - the process can be a really enjoyable one.

Remember, management of your web site is a process, not a set of products or a design vendor’s vision. It’s all about collaboration with you, your team and your vendors.

Choosing the software and services solution will truly strengthen your business. It will not only create efficiency for the Web site management process, but (depending on your business) provide you with a number of opportunities to create competitive advantages, revenue opportunities and new avenues for customers and partners to communicate with you through your Web site.

You’re an expert in your business – and you shouldn’t have to become an expert in Web sites in order to be successful. We would suggest working with a vendor who will become a core part of your Web site management team as a site management expert. But then again, as you might expect – we’re biased that way.

We wish you the best of luck with your web site redesign – and we hope this white paper is of some help to you.

>> Click Here to Download White Paper <<