Launched in 2000, The Favourite Website Awards (FWA) recognizes cutting-edge technology and creativity. It’s one of the largest online award platforms.
A year ago, though, our team realized that the FWA website wasn’t up to par with the innovative projects it awarded. What follows is the story of our year-long redesign.
The beginning: Content audit
Content audits are always important, but for this project it was essential. We needed to understand the 15 years of data that we’d be migrating so that we could write a script that would properly take care of it.
The audit showed us the different types of content on the platform, along with the frequency of content updates. As an example, we could conclude that there were a few daily awards, a monthly and a yearly award, etc. Editorial pieces like interviews, agency spotlights, and jobs were less predictable in terms of frequency, so we calculated the average frequency for these. Looking at all this told us how big the project really was.
In addition to the content audit, our founder, Rob Ford, wrote to industry leading creatives to gather input about how they used the platform and which changes they’d like to see. One thing we learned was that the community wanted the editorial content to be more prominent—it was too hidden on the current platform. But more importantly, the community wanted a responsive and fast performing platform.
Once we had all this info, it was time to put the team together. The back end was too massive and complex to do in-house, so we invited Konform to collaborate on the project. They do complex yet fast systems, so we knew they’d be a good partner to build the back end. The FWA platform was getting old and slow, so performance was key to the success of the project.“Team up with people who are better than you.”
Evolution or revolution? We discussed this topic over and over again. We wanted to stay true to the long legacy and brand equity the FWA had built over the years. But we also knew that the revamp required brand-new thinking.
So we did both. From a visual standpoint, we decided to work with the existing identity elements and focus on pushing the concept instead.
Live judging was the biggest conceptual change. In the past, users didn’t know if they were close to winning. It was a “black box” with an unknown outcome. The new system was transparent. The judges (approximately 100 women and 100 men) cast their votes, and the submissions that get the highest score over time automatically win.
Old FWA submissions were much smaller in size than they are today. We solved this by creating special templates with higher pixel density in same aspect ratio as the old submissions. This way old and new content could work in the same grid. We also created 6 breakpoints to optimize the experience on various devices.
Another thing we had to take into consideration was the question about what a digital creation is. In the early years, the FWA awarded sites, but it felt antiquated to only focus on sites when the digital world was blooming with installations, experiments, apps, and virtual reality. It was evident that we had to move away from the legendary Site of the Day (SOTD) and replace it with something else. The only issue was that people identified the FWA with SOTD—it’d be like changing the Oscar to the Oswald.
Here’s some of the examples of input we got:
- Community member 1: “FWA equals SOTD and SOTD has always been the main reason to swing by on a daily basis.”
- Community member 2: “I think it’s amazing how the FWA is renewing itself to be the representative of all media creations staying up and ahead of the times. One thought I had is that maybe the site of the day should be renamed to creative of the day… Or something broader than site.”
- Community member 3: “Call me old fashioned, but I’d like you to keep the SOTDs. It’s what all of us in the community always have been striving to win.”
We had to make a decision. Even though we understood both sides of the argument, we decided to build for the future and rename it to FOTD (FWA of the Day). In other words, any digital creation could be awarded on a daily basis.
We built more than 50 prototypes to help us test key functionality on the platform. Some were simple clickable wireframes, while others were fully developed prototypes with real data. We needed a real jury to test the live judging, so we reached out to people at the 25 most awarded agencies. We then set up a testing environment. The feedback we received from that enabled us to optimize the judging flow.
We decided to use Basecamp for this project mainly because we were 3 teams that had to be in perfect sync. Never play telephone on a project.
Even though it’s great to have one point of contact for a client, there’s too much interpretation happening when one team is an intermediate. In Basecamp, everybody sees all discussions, tasks, files, etc. Here’s an example of what it looked like halfway through the project. We had a total of 102 discussions from June, 2015 to June, 2016 when the platform launched.“Never play telephone on a project.”
Halfway through we also did a mid-term evaluation. Here are some of the main questions we asked ourselves:
- How is the project going?
- What is working / not working in the process?
- What do we think needs to improve?
- What can I do to make the project great for my team members and myself?
This process was exceptionally smooth. We believe it’s because we were a tight group with few stakeholders and a high level of trust. We use a method called “stop, start, continue” to ensure that the team dynamic is always good. Team members say what they’d like the other members to stop, start, and continue to do on the project.“A mid-term evaluation helps steer a project back on track.”
This is one of the first projects where we tested InVision. We used it to to present UX and UI, collect feedback, and to test out device-specific features. It proved to be extremely useful because we got detailed feedback in the context of a specific screen. This way we could iterate and update the specific screen without having to do a new presentation every time. It also enabled us to do clickable wireframes, which eliminated the typical errors and interpretation issues that come with static, annotated wires. We were making it instead of explaining it.
JIRA has been our bug tracking tool for a long time—it gets the job done. We spent a considerable amount of time in JIRA (1000+ tickets).
When you design a big platform, you need to take out the guesswork. Preparation is key, and it was a major advantage that we had qualitative input from the community. We believe this is a major reason why there was less than 1% negative comments when we launched. Part of the preparation is also to align expectations and make detailed tech specs.“Take out the guesswork when you design.”
Platforms are complex, and you’re only halfway there when the design is completed. Even though it’s fun to start over, we chose to embrace the FWA legacy, extend it, and make it better.
We learned that you should never underestimate the blood, sweat, and tears it takes to do good QA. This is when you realize that you thought you took all scenarios into account, but you didn’t. “How do we handle a situation where 3 judges have to vote in 3 different time zones around midnight when the next FOTD has to be awarded?” Oh crap—we forgot that one. Always remember to design for worst-case scenarios.
Finally, team up with people who are better than you. We owe a huge thanks to Konform for making a very complex back-end process smooth. Moving 15 years of content is hard technical work, and they helped us steer this project to safe harbor.