Chapter 3: Production
Information Architecture, Content Development & Migration
Content Development and Migration
Depending on whether you decided to optimize existing content or develop new content for your website, the amount of time you will need to spend on content migration will vary. The size of your current website and your future site are other variables that will determine how much time you should block out for content development.
Content revision and optimization can be done concurrently with the design part of the project and completed shortly prior to launch.
Whether you are writing all new content or hiring someone to do it for you, or trying to balance inand outsourcing content creation, you can keep this work independent of the rest of the project.
The only areas where there is overlap is information architecture—which will determine what content should be created—and the work you do with your SEO firm, which will ensure your content is the right content for your audience, and structured appropriately for search engines.
You can also begin revising and developing content well ahead of a website redesign kickoff, and save even more time from the project schedule!
If you’re happy with your current content, make sure you include migration in the project discussions, and find out whether it will be a manual process, or one that can be automated through the content management system.
With the discovery, goal setting, content planning, and information architecture development finally out of the way, it’s time for the part of the project that both stakeholders and agencies look forward to the most: the visual and creative parts.
A good web designer is more than a graphic designer who happens to know some HTML. Whereas in print media the only interaction with a piece is viewing it and possibly turning pages, a visitor to a web page can interact with what she sees in many ways, with each click either getting her closer or farther away from what she is seeking.
The design process will aim to distill the mechanics of a visitor interacting with your website and knowing how to deliver that visitor to the right pages, and motivate the actions and behaviors that will yield positive business outcomes.
This section should help you navigate the tricky and sometimes contentious wireframing and art direction portions of a design, and what is involved in going from design mockup to usable code.
Your design firm or designer should be able to interpret your goals, the desired behavior from future website visitors, site content, and other needs, and offer a structural preview of how these requirements will meet in a harmonious way on your website.
Wireframes are the best way to do this before committing to visuals that cannot be easily revised. Although the wireframe portion of a design project is not the most labor intensive, it is often the most difficult for the project team to work through because of their nature. So how do you make the process less painful? Understand the role wireframes play in the redesign process and how to help your team do the same
What are wireframes?
Wireframes are used by user experience and user interface designers to account for the various components of a page on a website, ensuring all necessary functionality and content is captured and has a place in the upcoming design.
Wireframes are not a blueprint for how the final product will look, or a map of where every item will appear. Try thinking of them as a visual checklist that ensures every important element is included, and that relationships between elements are mapped out.
Why are wireframes important?
Wireframes are the web design version of the old adage to “measure twice, cut once.” The actual design and development of your website is complex, involved, and often expensive process. Once it has begun, you want to keep changes as minimal as possible and don’t want to rethink direction with a half-built website.
Focusing on information architecture, content quality, and structuring various elements prior to the actual development gives you multiple opportunities to ask questions, make important decisions, and spot and address problems where it’s most time and cost effective to do so.
Why is working with wireframes so difficult?
Humans are wired to respond to visual information and it’s hard to ignore something in front of us and picture it’s going to be something else. This is one of the great challenges for visual designers in any discipline: non-designers always struggle to imagine something they can’t see, and don’t always know what they want or don’t want until they see it.
While the UX designer wants feedback on whether every page element is present and behaving properly, the project team may get stuck on “move that to the left” and “will it be green or blue?”
How can working with wireframes be more productive?
In order to keep from getting stuck on the wrong information during a wireframe presentation, your design agency should help the project team understand the mechanics of what a wireframe does prior to actually showing it. Emphasizing that it is more of a checklist than a mock up might help.
Designers can also explain that the focus is on user interaction with individual items, and how they interact with one another in a page, consistently emphasizing function over appearance.
What your project team can do is limit who is present at the table. Whatever the size of your website redesign committee, the decisions to be made here are more technical and structural than visual. Only the core stakeholders should be involved in approving wireframes.
Most executives will admit they are not designers, and even that a wireframing discussion goes right over their heads. Their concern is that the website is structured soundly in a way that will keep the process on target, and on budget, and focused on meeting the website goals your team defined earlier on.
It’s hard not to get attached to the first visual representation of the website your team is so excited to launch. With a little preparation, patience, and better understanding of where wireframes fit into the process, you can keep the discussion focused and productive so you can move on to the fun part: reviewing the actual website design.
Approving a design by committee opens the door to a multiple of perceptions and opinions. When everyone at the table wants to feel a sense of ownership and confidence in the outcome, it’s difficult to step away from the process and let someone else make decisions. How could you hand over that power to someone who doesn’t see what you see?
When your proposed website design leads to disagreements and colleagues digging their heels in. Some will try to invoke design experience in an effort to give their opinion more weight. You might find yourself tactfully responding to the HiPPO (highest paid person’s opinion) in the room and struggling to build consensus.
Before you sit down for final approval, select whose word is final in the discussion. It doesn’t have to be your company president or CEO. The CMO or marketing director is often the best equipped person to make the final call, not because of being a “creative type,” but specifically because of experience targeting messaging and design to the customer rather than internal stakeholders.
Going from Subjective to Productive: A Step-by-Step Process
When you sense that there are some strong conflicting opinions in the room, it’s time to pause the discussion and rely on a process to keep the dialogue constructive, focused, and productive instead of devolving into a conversation about personal preferences.
If you know you can’t reach agreement quickly, you’ll need to:
Remember that a website design, while requiring a creative and visual approach, is still a business endeavor with expected business outcomes. A successful website is one that drives the desired customer response and that is the most important metric. A successful website will also instill confidence in your team and how your brand is presented, but remember that pleasing your internal audience is secondary.
On the web, people see videos, images, and text. Web browsers see code. In order for browsers to load a website that looks like what your design firm presented, someone is going to have to supply the code that these browsers can read. This is the role of the web developer.
Depending on the original statement of work supplied by your design firm, the development could be done by either their in-house developer, or someone on your staff who has development skills and deep knowledge of how to later implement that code with your content management system.
Doing the development in-house can save you on project costs because it means less billable time on the agency side, but it can be costly in terms of time required from your team, and away from other projects.
Which content management system will be used for the new website can also determine which path is best. You might have a lot of in-house expertise around building page templates in your CMS, or it might be a development-heavy effort that is best left to someone who has done dozens of similar projects.
Regardless of who uses the design mockups to create static HTML versions of pages, implementing that code as part of CMS templates can be another major or minor project in itself.
The content management system you selected for your website can make a big difference in overall project cost and timeline, as well as the ongoing cost of keeping the website up to date and making occasional design changes.
If you choose a new content management system implementation to go along with your website project, you might be able to leverage your CMS vendor’s services and expertise in helping you go live.
The actual implementation of your website and CMS is the part where the marketer and your organization are usually least involved, but how it happens has long term repercussions for who is truly in charge of your website.
Because the timeline, cost, complexity, and transparency of your implementation is inextricably linked to the content management system you use to host your website, it’s beyond the scope of this handbook to cover every potential timeline.
Ask these questions early on in the planning process to assess what the implementation might look like, and whether it will fit with your website goals and project timeline: