How we created the new Wagtail.org
These are the steps we took to turn user research and SEO strategy into a website that can tell Wagtail's story better than ever.
One consistent bit of feedback we've been getting from people who are thrilled about Wagtail is that although developers can look at our code and see the value of Wagtail pretty much right away, leaders and decision makers often need some extra help. Ultimately, we decided to address that challenge by refreshing Wagtail.org so we could provide people not only with resources to learn Wagtail's code but also resources to help them try out Wagtail and see just how great our CMS could work for their content creators.
Step One: Craft a long-term strategy
It isn't always necessary to think of the long-term goals of a website before building it. If you're creating fun one-off sites like Is the Ship Still Stuck?, speed generally matters more than strategy. But most groups investing in their web presence want a website that can grow with them over time.
Fortunately for us, Wagtail.org is built (of course) with Wagtail, so we didn't expect too many technical challenges. We did have to sit down though and think hard about how our website could continue serving developers and the community well while also promoting Wagtail to a broader audience. We looked at the traffic and analytics for our current iteration of Wagtail.org, and found that people were finding Wagtail's documentation and developer resources real easily. Yet our blog articles for decision makers and our resources for finding Wagtail services were getting a lot less traffic, like less than 1% of our overall traffic.
Part of that finding can be attributed to the fact that many of our key Wagtail champions right now are developers. Another big part though was that a lot of that content was buried and couldn't be re-used or highlighted easily. We didn't have all the page types, snippets, and blocks we needed to use that content effectively or to optimise our SEO.
So we thought about all of the components we needed and crafted some ideas for a new information architecture (IA) for Wagtail.org. We could have taken one of those architectures and charged forward with our redesign. Our users are great people though, so we decided to share our ideas for a new IA with them first and see what they had to say.
Step Two: Conduct user research
We created a treejack test in Optimal Workshop to see what people thought of our new website architecture. We tested two new IAs and set up a testing link that randomly assigned an IA to each person who clicked it. For example, one of the questions we used was: "Imagine that you have a Wagtail website and you’re looking for help to fix a problem with it. Where would you look for support?"
Here's an example of what those results looked like:
It was a good thing we asked that particular question because in our testing, we found that a lot of folks were confused about where to get help with Wagtail. That's why we have a standalone Get Help page now in the Resources section of the site.
One other thing we found was that having a distinct Services sections made it easier for people to locate information on the existing services for Wagtail, like the Wagtail Support service offered by Torchbox, the Wagtail hosting service from CodeRed, or the Wagtail build services offered by Four Digits.
Based on that research, we also created a Why Wagtail section that makes it easy for people to find information on different Wagtail solutions as well as comparisons between Wagtail and other technologies they might be considering. Currently, there are two articles: one going over headless CMSs, and another comparing Wagtail to Wordpress. We'll be growing this section over time, so stay tuned for more content.
Step Three: Explore designs
Once we had a pretty good idea what the structure of the website would look like, it was time to explore design options. We wanted a design that would get people playing with Wagtail and seeing the benefits of Wagtail faster. Ben Enright from Torchbox created a visual design and user experience to help us achieve that goal.
One of the best changes Ben made was the creation of the Get Started button that appears on every page now. The button opens a menu that gives visitors multiple options depending on their interests. Developers can dive into code while leaders and content creators can click into a demo straight away and get a feel for the Wagtail interface.
Another great feature of this menu is that it can function as a Wagtail block as well, so you will see it featured in blogs and other content that encourages new visitors to give Wagtail a go.
In addition to this Get Started block, Ben designed a series of blocks and page types that provide us with more flexibility to highlight content like case studies and blog posts across the website. These blocks will make it easier for us to reuse content and showcase it in different contexts. Here's an example of the block set we're using for our main article page:
Ben also incorporated a reusable set of icons into his designs that can be called into many different blocks and page types. You'll notice that these icons appear in the headlines, the menus, and even as bullet icons in many different places across the website. With this icon set, people who are creating the content have multiple visual options to choose from to help them tell their story.
Step Four: Build, build, build
After we got feedback on the designs from the Wagtail core team and other key Wagtail fans, we assembled a team to actually build out the new version of the website.
Our first exercise together as a team was to get together and decide how the designs could be broken down in blocks, snippets, page types, and other components. This is called a story mapping session. Here is an example of the board we worked on together for the home page during that session:
By the end of our time together, we narrowed down our list of the pieces we would need to bring the new design to life. We also sorted out the existing parts of the website we would keep and the new parts that would need to be built from scratch.
The build team included a group of frontend and backend developers from Torchbox. Because Wagtail 4.0 was coming out soon, we had many different folks lend a hand to this project when they had time to contribute. One key member of the technical team though was Wagtail core team member Dan Bragis, who provided guidance to the developers who contributed and technical oversight throughout the build.
Our delivery managers, Abigail Hampson and Geraldine Williams, are probably the biggest heroes. They kept everything moving and made sure all the bits and pieces we needed to for a successful launch were in place. Pieces like our accessibility review, our SEO checks, and small things like remembering to clean up all of the kooky JUST TESTING THIS content we created during our tests. We honestly would have gotten lost in the woods without their help (or at least forgotten to set up redirects from the woods).
Step Five: Launch and refine
The new design is here now and ready for you to explore. Our next steps are to see what everyone thinks of the new structure and to get a sense for whether the design needs to be refined any further to serve our community better.
If you have any thoughts or questions about the new design, don't hesitate to reach out. You can also help us improve the website by filling out this short feedback form.
That's the story of our Wagtail.org build! We sincerely hope it inspires you to build a Wagtail website of your very own. 😁
Main photo by Dan Cristian Pădureț on Unsplash.