Grist.org Website Redesign
Grist.org was in a time of transition in the web space over my tenure, with many major changes as well as a massive site redesign. The goal of the new design was to make it easier for users to read, navigate, and dive deeper into more content. The organization had also transitioned to Wordpress and ditched the internal servers from a technical standpoint. There were many stakeholders and departments we had to design for to make it all come together while keeping user and business goals relevant.
The first order of business is to see where we were at in terms of current features. We did what my product manager called a MoSCoW
- Must have
- Should have
- Could have
- Want to have
I worked with the product (web) team of 3 developers and ran through our current lists and we did our own current inventory using this method. Afterwards, we approached key stakeholders in each of the main divisions (fundraising, advertising, editorial, etc) and validated what could be trimmed and what was required which helped us flesh out future features.
Our plan for tackling research was largely based on the quantitative measurements we got from Google and KISS metrics, as well as understanding who the audience was by reader profiles, social media, and analytical demographic information. I ran a competitive analysis on similar sites with relevant content, organization size, & design to Grist's product such as Mother Jones, The Atlantic, and the Daily Beast. We tested our current site and looked at our quantitative data to verify a few features that were not working such as having three columns and the right-most column having a drastic decline in click-thru.
We decided to do remote testing with users on the existing site to see if we could identify shortcomings and with to gain more knowledge into if they could find features or items. The initial results weren't terrible from the script we gave, but the mobile users had a much more difficult time, and everything took twice as much time for them to complete tasks. This was particularly noticeable on the donation portion of the site, where we would see a steep drop off of users once they accessed the donation screens.
The first order of business to wireframe was the article pages. It's the meat and potatoes of the editorial product and has the most touch points on the website. The goals were simple: Easy and attractive to read. I designed a few iterations of the pages in Balsamiq to share with the team before deciding which versions completed the goals and which were efficient to develop with the product team's involvement. After determining the article pages, we focused on the homepage, category/section pages, and the fundraising section among others.
The fundraising portion was a unique project because the product team had almost complete freedom to redesign and incorporate new functionality. I helped with the design and userflow of the project and we trimmed down as many steps as possible, which helped with the user flow and the confusion (particularly with error reporting).
After wireframing and landing on a general option and direction we wanted to head in, we started creating higher fidelity prototypes and even building much of it on a dev server that gave us the ability to test live content. We iterated on the design elements during the prototyping phase to adjust for mobile use, speed (page load time, device/browser support, accessability, etc).
The team was working fluidly between different mediums with each phase of the project. Stakeholders were involved and included in this stage of the process to make sure that their voices were heard and we developed from a mindset of getting the minimal viable product from what we had at first, and pivoted on a few things like advertising to incorporate new features into the site that were deemed necessary.
Refine, Retest, Iterate
Once we determined the pages, layouts, elements, and functionality we started on interactions such as the above modal for social sharing. Throughout the process, we conducted remote user testing to validate our assumed flows based upon the design and created a script to run through new features we were planning on incorporating to justify their effectiveness. Having a live prototype with current content was a definite advantage and gave us great insight to QA, finding technical bugs and improving for the future.
Implementation and Measuring
The site transition was launched very smoothly from the old site to the new, and the team measured successes and shortfalls mostly with quantitative data but also by running a survey that was overwhelmingly positive. Metrics were up across the board, from increasing time on site, pageviews, and mobile accessibility. Small improvements were made to interactions and fringe pages that were rarely visited after deployment.