Go behind the scenes of our new website redesign

This is it! A few weeks ago, we gave the Voodoo website a facelift. After four months of work, we released the brand new voodoo.io website 🔥 I want to take this occasion to rewind and share everything we learnt along the way.

The reasons behind the change

At Voodoo, we know our website is a key asset in our overall strategy: it’s the entry gate for game studios, developers, and candidates. For many, it’s the first impression they’ll get of us. In terms of metrics, Voodoo is the #1 game publisher in the world, with 6 billion downloads and 300 million monthly active users across a portfolio of over 200 games. But our website didn’t reflect that at all. Something had to be done.

Our previous website was three years old. The content was outdated, the design didn’t represent who we are anymore, and the code wasn’t clean enough to allow us to update it easily. My first few months at Voodoo were dedicated to refreshing the brand’s visual identity and working on other priorities, but as soon as I had enough bandwidth I jumped on the website redesign project. I knew from the start it was the right time to not only update the design, but also the content and code. We made the choice to rebuild everything from the ground up, creating solid foundations to futureproof the website in the long term.

The process

Redesigning a website is very exciting. It’s very personal, and the perfect place to express who you are as a brand. It’s also a very strategic touchpoint, driving talent and revenue. For those reasons, we took the decision to handle this project internally, instead of outsourcing it.

We identified three main roles for handling this project from start to finish: designer, developer, and project manager. As the main Brand Designer at Voodoo, I naturally handled design. But I also wanted to learn more about project management, so I ended up wearing two caps for the whole project.

I also partnered with Malik, Tech Engineer at Voodoo, who was in charge of overviewing the development side of the project. We ended up hiring two freelance frontend developers to complement our internal team, despite not being full-time on the project.

I introduced the notion of a design system to my team very early, and especially the Atomic Design approach. A simple analogy explains this approach: in the real world, atoms come together to form molecules, molecules then form organisms and so on.

Atomic Design is the same, but applied to a design system. You start by creating the tokens (colors, fonts, icons) that will be used to create components (buttons, text fields, dropdowns). These components are then used to create sections (forms, hero, footer) before finally combining everything to create pages.

Now that we were aligned on design, I switched to project manager mode and approached the key stakeholders to gather their feedback and guidance to understand the story they wanted to tell on the website. Once I had gathered enough data , I was able to start fully designing the pages. After some back and forth, we agreed on the near-final designs before sharing with our CEO for approval.

During the back and forth, I built the pages in a “quick and dirty” manner, because everything was changing quickly, from one iteration to another. The goal was to be efficient, and not waste time working on components we wouldn’t end up using. It was only when the pages were approved that I created the components in the design system, with careful attention to detail, including specs for the devs and listing all the variants.

Once all the pages were ready to be implemented, the dev team introduced me to a new tool called DatoCMS, a headless-CMS designed to help people like me, who don’t have specific development knowledge, to modify code using an easy-to-understand interface.

Instead of developing page by page, we took the counter-intuitive decision to develop section by section. In order to prioritize, we started with the sections that were most used across all the pages. Each time a section was ready, I ensured everything was fine in the Quality Assurance (QA) phase. Finally, the approved sections were sent to our testing environment. An alternative URL would allow us to see the website in the same conditions as if it were live.

Step by step, the sections were added to the testing environment, and I was able to start building the pages directly in DatoCMS. It was just like playing LEGO. I was able to add blocks under blocks, filling the fields and adding my illustrations, and then the magic happens. Because each page is based on the exact same sections, they were all consistent. And because each section was already approved one by one, there is theoretically no need to QA the final page.

That being said, once all the pages were built, there was still a last QA phase to complete, in order to test things that are only testable when you have several pages, such as transitions between pages and navlinks redirecting to the right pages.

The result

We now have a brand new website that is far more aligned in terms of design with our new artistic direction. The content is up to date, and there’s more room for visuals, videos, and even interaction. Finally, we ensured mobile navigation was optimal, taking into account that most of our traffic comes from mobile devices.

But this is far more than just a website. We now have a super practical tool that allows us to update all the visuals and the texts on every page, without worrying about breaking anything. We can add or remove sections to existing pages. We can even create new pages from scratch, reusing all the blocks that were previously created for other pages.

Because Voodoo is a company that evolves rapidly and operates in a fast-paced environment, having the power to update the website easily without the help of a developer is a true game-changer.

Key Learnings

The common timeframe for companies like us to redesign their website is six-12 months, with more designers, developers, and sometimes an external agency. In order to make it in four months, we had to do things differently, taking risks and breaking things. We learnt a lot during the process:

• It’s OK to rush things that are not visible and don’t impact the user experience if it gives us more time ahead of the launch. For example, when approaching the deadline, we made the decision to hard-code some parts in order to free up some dev time, so they could focus on more important tasks. The important thing is to keep track of all those subjects, and have a plan to handle them after the launch.
• It’s also OK to take more time on things that will have a huge impact later on. For example, it took longer to integrate the sections in DatoCMS, but the benefits have been huge as it allows the team to create new pages in minutes instead of weeks.
• From the start of the project, only involve a few key stakeholders (CEO, C-level) to maintain a fast pace, and avoid losing time and energy on everyone’s preferences.
• Ensure you show the final version of the website on a testing environment to final approver(s) just before the launch. Even if all the screens have been approved before, it’s an entirely different task to test the website directly on a computer.
• Make sure you have an easy way to revert back to the old website while deploying in production, in case something critical breaks.
• Announce the launch internally first, and ask for your coworkers to provide feedback. They are the ones that know the most about the company, and will have fresh eyes to see what you may have missed..
• If the initiative to redesign the website comes from you, as a designer, then be ready to wear two caps: designer, and project manager. This is the reason why I wouldn’t advise thinking about a website redesign as a “background task”. It should instead be considered as a top-priority as soon as you start working on it.
• Accept the fact that the version that is live the day of the launch might have imperfections, but it doesn’t matter as long as nothing critical is broken. Dedicate the following days or weeks to fixing all the minor tasks you planned to handle after the launch, and also the improvements you didn’t necessarily notice beforehand.
• Add monitoring tools such as Google Analytics and Hotjar as soon as you can, in order to capture as much data as possible about how users are using the website. You might get some surprises, and it will impact the post-launch roadmap.

I am really proud of the team for this huge success. It is far from being over, as a website is never finished, it can always be improved. We are already working on the V2.1 ⚡️

If you want to check our new website live, go check voodoo.io, and visit our Dribbble page to see our other design pieces of work.