In a previous article, I outlined my rationale for rethinking the website redesign process to a “content first” approach. It shakes out to these 9 phases:
- Research + strategy
- Taxonomy + sitemap
- Content outline + synthesis
- Content migration
In that article, I talked about how a content-first web design process puts customers first, streamlines your design and helps your design team, helps with SEO and accessibility, but ultimately, makes for better storytelling and better conversation with your target audiences. So, how do you put that into practice? Here is a breakdown of each of the 9 steps, plus a bonus 10th step: post launch.
1. Research + Strategy First
So, what are your business goals and objectives? Don’t know? Then you need to rethink your marketing strategy, homie. Check out this article I recently wrote that should help you get started. If you do know, then you need to make those the starting point. You need to determine which of those goals and objectives your website can help you achieve and how. Out of your 4 personas, who will be visiting the website? What will they be looking for? What calls to action would drive people towards your goals? Is high traffic or quality-of-visitor going to have the most impact for your brand? You just need to determine what you want to achieve first, and then we’ll figure out how in the next phases.
When redesigning a website, you should have plenty of data at your disposal. After all, Google Analytics is free. You do have Google Analytics installed, right? Oh, good. I almost had a freaking heart attack. There are a few other tools that I recommend when redesigning websites (I haven’t been paid or endorsed by either of these, I just honestly recommend them):
- Crazy Egg – This site allows you to place a small script in your <header> and tracks all visitor activities on those specific pages. You can see where they clicked (even if it’s not a link), how they scrolled, what time they clicked, what day they clicked, where the traffic came from, and a myriad of other awesome data. Now, they even have a feature that records a users experience with the site.
- SEM Rush – This tool has been invaluable to me as an SEO professional. I use it nearly everyday, and when I don’t use it everyday, I’m getting notifications and reporting to my inbox. It’s helped me place clients in the first page of Google for so many keywords. But, it also helps tremendously as a website planning tool. You can plug your current site into it, and it will run an audit pointing out weak spots on your site that are hurting you from a search perspective. I always use it to identify red flags and areas of improvement on the next site – before I start considering site structure.
Take all of your data and look for trends. What are the most popular pages on your website? What is the most typical user flow? Are there entire sections of your site that aren’t even being used? Are people typing things into the website search box that you aren’t offering on your site? Now, do the answers to these questions also line up with your company’s goals and objectives? This is a good time to validate those goals, or a good time to rethink them, or a good time to rethink the purpose of your website.
This is also a great time to run focus groups, user testing, surveys, and more to get real user feedback on your website. It’s the most ideal approach to take before you start the next phase of the site. It’s definitely worth the money and the time for the benefits you’ll see in the long run.
As you gather all of this data, you’re starting to build your site outline. This outline (informed by research and strategy) is what you will be using to create your sitemap.
2. Taxonomy + Sitemap
Now’s the time to look at what your strategy and research told you that you need in your site, and start to group that stuff together. If you’re a gastropub and people were looking primarily for ingredient information and sourcing, then you might want to create a prominent section of the site called “About Our Food” or something. Don’t get too specific or too high level for this exercise; just simply create a catalog (or taxonomy) of information that people want from your site (and, hopefully, this aligns with your goals).
There are tons of ways to sort through and map out a website’s taxonomy; but no matter what, you are creating a hierarchy (and network) of information. Stay broad and shallow (don’t go too narrow or too deep), but be specific with your categories and make sure they are unique. What you should have, at the end, is several buckets of content that are related under a section header.
Once you have your taxonomy mapped out, take a look at the section headers that you’ve placed the buckets of content beneath. How many do you have? Are some more prominent than others? Are they all truly unique?
3. Content Outline + Synthesis
Since this is “content-first” web design this should be the most important step, right? Yep. Definitely. You know the taxonomy and sitemap by this time, so you should have a rough sketch of what topics of content needs developed. What you don’t know is how much content needs developed, what it looks like, how it breaks down, how much is written word vs. graphical, what needs designed or animated, etc.
There are a lot of questions after the taxonomy / sitemap phase that should be answered by the content, not the wireframe. Usually, people move straight into wireframing. This puts your content in a box and restricts what you can do with it. This creates problems for the copywriter, the designer, the developers, and, ultimately, the customer. When you create the wireframes first, content is forced into the space which the designer grants it (who won’t have much to go on in the first place), it’s forced onto unnecessary subpages, it’s forced into widgets that hide it (impacting the user experience and mobile design of the site), or it’s forced out of the website completely. If you wireframe first, you also might find huge chunks of content the client didn’t know about, forgot about, or decided needs developed after seeing the designs. To avoid all of these issues: content-first.
It might take extra time to do it this way: a lot of times, people like to write the content after design and run it tandem with the development phase, finally wrapping up before content migration. That’s a great way to streamline the process and make it faster, but it’s also a great way to end up with a jumbled mess of content and no place to put it. Rather, take the extra time to pull together the content before wireframing to make everyone’s life a little easier. I promise, you’re going to make up this time later. Wireframing will be faster. Design will be faster. You’ll experience less development roadblocks. Content migration will be smooth as silk. Just try it once and you’ll see.
Pro-tip 1: Don’t forget things like page title tags, page descriptions, meta keywords, footer copy, and other chunks of content like that in this phase. Often, these are the little pieces that people forget about until it’s time to migrate them!
Pro-tip 2: Sometimes it’s like pulling teeth to get final approval on the website content. In this case, don’t let your project fall apart. You’re going to have to forge forward and keep stakeholder expectations set that any big changes to content are going to result in change orders and an extended timeline. Don’t let the project stand still though: move forward with proto-content. Get it as far as you can and forge ahead.
Because you’ve taken a content-first approach, your wireframes are going to be so much easier. Your designer or front-end developer will know exactly what content needs to be included, how much space it needs, what can be placed in tables, what will need icons, etc. This is a place where you’re going to make up some of that time that you spent developing the content.
Be sure to involve your back-end developer in this phase. Having them review the wireframes before they go to the project stakeholders will ensure that any potential issues or roadblocks down the road can be mitigated early on.
Not much changes here, except your designer has wireframes that are built off a real, tangible content map. See? Everyone’s job is easier now! Hooray!
The bonus to the design phase is that the designers can really flex their chops. They don’t have to build “safe” solutions to things, because they know the worst-case scenario. They know how long headers will be, how many header styles they need, how they’ll need to treat images, if there will be special widgets needed, what icons will be needed, etc. It shouldn’t put them in a box, but rather it should be liberate them because they aren’t restricted by “what ifs” – no more overthinking plan B’s.
Similar to the design phase, the developers should feel a lot better about having designs based on content. A big issue for developers (besides not being included in the process early on for feedback) is having to go back and change the way something behaves because the content came back longer or in a different format than expected. Developers should be able to dev out what is designed and that should pave the way for content migration with minimal back-and-forth.
7. Content Migration
If you’ve done everything with a content-first focus up to this point, this part should be easy breezy. Simply put the content where you planned to put it, right? Hopefully, that’s how it goes down for you, but the chances are that you’re still going to run into a few bumps. It’s important for the content migrators, copywriters, developers, and even the designers to be involved with this phase. Have regular checkpoints, point out red flags as soon as you see them, and ask each other questions to make this a smooth process.
Just do QA. Nothing really changes here, right?
There’s not much difference in this phase between a content-first approach and a design-first approach. And I’m not going to tell you how to launch a website. It’s not my job to launch, and it’s probably not yours. If it is your job and you don’t know, you should probably be reading a different article. But, for those of us who don’t actually launch the site but simply manage the project, we should be heavily involved in this phase and be poised for action in case we, or the client, are needed. Hopefully, you are launching the site during historically low traffic hours to minimize any risk of your visitors experiencing any down time. Also, in case there is an issue with the launch from the dev environment, as few people as possible will see it. Just make sure that all the content came over correctly and do your quality due diligence.
As I said, a content-first approach solves a lot of problems and prevents a lot of hiccups in the web design process, but it has a lot of other benefits; one of which being SEO. You can strongly integrate an SEO strategy into a content-first website design as you built out the content, but also post-launch. Hopefully, you’ve built your site to be optimized to all the search best practices, but after launch, you’re going to need to carry on. A content-first approach to design is going to ensure that your SEO team is fully enabled to do that, whether it be on-page stuff or an ongoing content marketing strategy. I’ve always been a believer in content marketing as the best thing you can do for organic SEO on your site – and I’ve seen the results to back it up. You’re likely going to need to supplement it with paid search, etc., but a blog or “news” section is going to be huge for getting your site to continually grow in search success. And building your site content-first is going to help ensure that you stay focused on your critical keywords from the beginning. It’s tough to get your internal team to commit to writing blog posts, but there are other solutions to ensure you get fresh, keyword-rich content on your site. Consider hiring an agency, a blogger, a popular Instagrammer, or share the load across your entire staff to produce ongoing content for your site.
What am I forgetting here, guys?