At last, the SOW is signed. You’ve got the blueprint for a winning website design strategy backed by a great proposal and pitch, and now it’s time to build. But where do you start? Whether this is a new site from the ground up or an overhaul of an existing web presence, there are a lot of components that make up a website build. The first and most important step is for teams to break out of their silos, audit, and sign off at all major phases, and keep everything well-documented. This ensures that each stakeholder’s needs are carefully integrated into the design, and avoids plans getting lost.
And let’s be honest, website builds are big projects that can take anywhere from three months to a year. Or more. There is bound to be staffing turnover, both on client and agency teams. Keeping a checklist of all the major components will go a long way in training new team members and keeping the project on time (and on budget).
Before I dive into the checklist, let’s address a common misconception with site builds. Many times they are labeled as a website redesign, but these terms are not interchangeable. This can be very misleading and downplay the effort required. A redesign implies that only the outer layer is changing, leaving all the “guts” the same. Unless the site is only re-skinned, leaving all content types, database structure, etc. as is, it is a website build. Even creating a new theme in WordPress should be considered a build. Alright. Now that we’ve got that out of the way, let’s jump in.
Sitemap
One of the most essential initial documents you need for a website build is the sitemap. A website sitemap should include all URLs—both existing and new—involved in the website build project. And if a new URL structure is being defined, it should be outlined as well. The sitemap will give the development team early insights about the content types required and the amount of restructuring and potential refactoring, especially if this build is a migration to upgrade from a previous build.
Content Strategy That Informs Wireframes
Most builds I have been part of were not only addressing the look and feel of the site, but certainly the content as well. Whether the goal is becoming more concise, targeting keywords that drive the business, capturing a new audience, or delivering a different tone, a plan needs to be laid out that considers how the content and framework and the site will work together. Your content team should work hand in hand with UX/design in shaping the most prominent components on the new site.
Some examples of their strategy may be:
- Audit to discover content to rewrite, redirect, or sunset
- Creation of new hub page(s) and associated copy
- Rewriting service pages
- Character limits on hero and call-to-action copy
- Descriptive text on call-to-action buttons
Wireframes That Inform Design and Development
The wireframes… Wireframes are the most important documents for any website build. They are the blueprints of a website in the same way an architect’s blueprints are for a building, and thus should be scoured over and scrutinized—by all of the departments involved in the project.
Wireframes need to be very detailed and communicate the structure of the site. The entire site. Seriously, all of it. Way too many times, developers are handed wireframes that are incomplete and confusing, only generating more questions than answers. If not executed properly, the stage will be set for feature creep, pushed deadlines, resource shortages, and general anguish.
As a result of many years in web development and countless site builds, the Portent development team has established the following requirements when creating wireframes.
Universal requirements
- Define the header level for every header (H1, H2, H3, etc.)
- Define image aspect ratios for every image placeholder
- No color. Use white, black, and shades of gray. Avoid high contrast
- Consideration of critical path for every template
- Avoid actual content
- Create mobile, tablet, and desktop breakpoint wireframes for every template and/or component
A Wireframe for every unique template
A wireframe should be drafted for every single unique template on the site. There should be cohesion between templates that use like components. Here are a handful of possible wireframe templates a site build would need, and don’t forget there should be a wireframe for each project-defined breakpoint (as mentioned above)!
- Homepage
- Service page
- Product hub
- Product page
- General/default page (about, careers, privacy, etc.)
- Blog hub
- Blog post/single
- Blog category (if different than a hub)
Navigation Wireframes
The navigation of web sites is a small application itself. With everything going mobile-first and all the various devices and screen sizes, there is a multitude of components involved with navigation. As such, the wireframes should cover all cases, including:
- Top of the page (default)
- Below the fold (sticky navigation)
- Mobile/tablet menu opening
- Second and/or third level opening (if applicable)
- Scroll up sticky (if applicable)
- Search form view/hide
Form Wireframes
Every site build is bound to have forms. It’s one of the most important lead capturing goals, which is probably pretty obvious. If the plan is to use embedded CRO forms (i.e., Pardot, HubSpot, etc.), you won’t need these.
- Validation errors
- Successful submission
- Pagination (if applicable)
Explain the Wireframe Elements
Components and functional pieces should have short briefs written to describe their purpose, and best use. Any requirements or rules should be communicated in this step. It is also helpful to document any areas of design ease or lack thereof (i.e., large variable heights or widths, flexible percentage-based placements such as “the logo comes down into the box 10% of the height”).
Recommendations
While these aren’t necessarily requirements of the wireframes, the following are strongly recommended guidelines.
Build and deliver the mobile wireframes first. A breakpoint starved of width based real estate but infinite height is as difficult to plan as it is vital. So do it first and spread out from there.
Plan image placements using aspect ratios. Aspect ratios can have different sizes while maintaining their shape, which helps provide a consistent experience across devices with varying width and height. Try to use the same aspect ratio for as many image placements as possible. This makes sourcing images easier and their appearance more consistent across screens. Examples of standard media aspect ratios for photographs, tablet screens, and HD content are 1:1, 3:2, 4:3, and 16:9.
Finalizing Wireframes
The project schedule must be set to allow for all involved teams, especially development, to give critical feedback and apply adjustments. It’s crucial for clients to understand the importance of wireframes and treat their review accordingly. All requirement solutions should be present and signed off on.
Designs that Inform Development
Website designs should follow the wireframes exactly, to a “T”. They are the skin on the scaffolding. When designs are ready to be signed off on, there should be no surprises in terms of structure and functionality. Nothing new should be introduced that isn’t already reflected in the wireframes.
There are many different approaches to handling website designs. Portent typically prefers a component-based design system. In other words, individual components are designed thus that when put together, construct layouts. An alternative approach is individual page comps, where one-off templates are constructed without deliberate reuse of elements. We have found this approach has more margin for error and confusion. For more information on component-based designs, refer to Brad Frost’s Atomic Design theory.
We won’t go over the fine details of Portent’s philosophies on design in this post, as that is an entire topic itself, but here are some general guidelines the development team prefers:
- Component-based design system–fonts, brand colors, header styles, button styles, etc. — laid out separately and concisely
- All designs adhere to styling rules with colors, typefaces, and font weights. The goal should be zero edge cases.
- Decide on all baseline HTML element styles before building components and pages. The styling can be flexible as the design evolves, but needs to remain consistent. Example of HTML elements:
- H1 – H6
- Strong
- Em
- Block Quote
- Quote
- Links (hover, focus, active, visited, default)
- Buttons (form submission, application actions)
- Select fields
- Radio buttons
- Checkboxes
- Captions
- Paragraphs
- Component layouts in three formats: ideal, too little content, too much content
- Real examples of components with approved copy
Like the wireframing phase, the project schedule must be set to allow for all teams, internal and external, to give feedback.
Analytics Implementation Plan
The analytics team should have a plan formalized well in advance of the development stage of a website build. While some analytics tasks for the project may be handled with third-party resources, there will surely be some that require resources from your development team. Formalize those requests early on so developers can plan for them.
Here are some common analytics requests for website builds:
- Google Tag Manager installation
- Third-party analytics installation
- CRO integration
- Closed-loop integration
- Custom form tracking events
- Other marketing funnel/event tracking
SEO Implementation Plan
Same as the analytics team, the SEO team should deliver its plan to development well in advance. Here are common SEO requirements for website builds:
- 301 redirect map
- Schema markup requirements
- URL structure requirements
- robots.txt definitions
Putting it All Together
By the time your website build project reaches the development phase, months have gone by and internal teams have drafted and executed on plans which were dependencies for other phases. It is up to the development team to glue it all together into a tangible website.
Any delays in the schedule will directly impact the development team if they are not accounted for. Additionally, any project components that are incomplete or forgotten will rear their heads. There are bound to be surprises, but minimizing the quantity and, more importantly, the severity of them is key. That is why all the planning and the checklists and the scrutinizing of those checklists is so important. There have been too many times in my career when, by the middle of the development phase, all sorts of issues are cropping up, from content not being ready to overlooked functionality. This puts an incredible amount of stress on a development team that doesn’t have the luxury to just throw more money and resources at it. It also sets the site launch to be pushed back, and quality of work to be impacted.
Use this checklist as a guideline. Build on it. Customize it on a per-project basis, but please use it. Anything that helps out the development phase of a project is a winning strategy, because no one is finishing a week or more in advance of the original launch date. Your development team will keep their sanity with 40 hour work weeks for the duration of the development phase, rather than working 50-60 hours per week stretching themselves thin while trying to pry answers out of other teams. Or stakeholders. Or both.
So use this checklist. Your web developers, project manager, and internal stakeholders will love it.
Let’s try and keep some sanity here.
