Blog Redesign Sprint

Overview

Company

National Outdoor Leadership School (NOLS)
A global nonprofit wilderness school developing leaders through outdoor education and expedition-based learning.

Project Goals

User
Help readers quickly browse posts matching their interests so that they can easily find engaging content.

Business
Improve the user experience of the blog to build credibility, promote brand awareness, and attract more customers.

Project Summary

I was the lead UI designer and frontend engineer for NOLS' complete blog redesign, delivering a 29% decrease in average page load time and 16% increase in pageviews.

NOLS wanted to improve the user experience of their blog to promote brand awareness, build credibility, and attract more customers. Readers were having trouble using the blog to easily find engaging content based on their interests and found the experience frustrating. I was the lead UI designer and sole frontend developer for the project. Our team followed a modified combination of AJ&Smart’s Lightning Decision Jam and Design Sprint 2.0. Post launch, NOLS’ blog experienced a -29% in average page load time, +16% in pageviews, +9% in average time on page, +8% in returning visitors, and +3% in pages per session.

Full Case Study

Introduction

Context

NOLS, a global nonprofit wilderness school, wanted to improve the user experience of their blog to promote brand awareness, build credibility, and attract more customers.

NOLS is a global nonprofit wilderness school that educates students in leadership and wilderness skills. It offers courses in four main program areas: Expeditions, Wilderness Medicine, Risk Services, and Custom Education. Of these programs, Expeditions and Wilderness Medicine account for the majority of revenue and courses for the company.

At the time of this project, NOLS was trying to grow the revenue of its Expedition course offerings but had been unable to do so for the past two years due to a shift in customer preference towards shorter, less profitable courses. One idea the company had to address this shift was to attract more customers by increasing brand awareness and driving more website traffic. To ensure they had the best chance of attracting customers to their website, NOLS wanted to improve the credibility and user experience of their blog.

Problem

Readers were having trouble using the blog to easily find engaging content based on their interests and found the experience frustrating.

Based on complaints from readers, our team knew that the blog’s audience was having trouble easily finding and engaging with content. From those user complaints as well as our own observations, our team identified the following usability issues going into the project:

• Slow page load time
• Clunky, dysfunctional design
• Poor readability
• Low findability and discoverability
• Unresponsive layout design
• Functionality bugs & errors

Users & Audience

NOLS’ blog readers are NOLS students (past, present, and future) and extended community members (parents, donors, industry members, and outdoor enthusiasts).

To help guide our design decisions and priorities, our team spent time getting to know NOLS’ blog readers through proto-personas and validated personas.

Below is key information about two personas that our team focused on:

Role

UI Designer

I was responsible for concept ideation, visual design, wireframing, hi-fi mockups, and prototyping.

During the Sprint portion of this project, I worked with the team to collectively determine the initial concept direction and create the first round of wireframes, high fidelity mockups, and prototypes for user testing. I also championed developing a new visual style for NOLS’s web brand that was much cleaner, minimalist, and modern. After the Sprint, I worked to further evolve and refine the visual design and mockups. I documented and created guidelines for this new style in WindPants, NOLS’s primary design system, which I was working on building out at the time.

Deliverables

• Wireframes (InVision Freehand)
• High Fidelity Mockups (Sketch)
• Clickable Prototypes (InVision Prototypes)

Frontend Engineer

I was responsible for the technical feasibility, implementation, and optimization of four page templates.

During this project I translated all of the high fidelity mockups into coded HubSpot blog templates and ensured the technical feasibility of the UI design. I was responsible for bridging the gap between UI design and technical implementation, taking an active role on both sides to define how the web pages looked as well as how they functioned. I also worked to optimize the web pages for maximum speed and scalability.

Deliverables

• Page Templates & Modules (HTML, HubL, CSS, JavaScript)
• Overarching Theme (CSS, InVision, Design System)

Team

I was the lead designer and sole developer for the project. I reported to one project manager, interfaced with three directors, collaborated with three writers, and worked with three other subject matter experts.

The team for this project was quite large due to the desire to include as many stakeholders and subject matter experts as possible in the Project Kick-Off and Sprint. The core team who was responsible for the project afterwards was much smaller.

In-House (11 people)

• Web Manager
• Frontend Designer
• Creative Director
• Marketing Director
• Senior Writer/Creative Project Manager
• Senior Writer
• Writer
• Art Director
• Senior Graphic Designer
• Communications Manager
• Digital Campaign Coordinator

Scope & Constraints

Limited Team Capacity
Alongside this project our team was also working on a massive website refresh that required a large investment of the team’s time and effort. Out of the two projects the website refresh was always prioritized.

New Process Buy-in
Our team had never run a Sprint before and it was challenging to get all the people we needed for it bought-in and willing to dedicate an entire week of their time to it.

Changing Stakeholders
Partway through this project my project manager (the Web Manager) left and the senior writer was replaced by someone new. As a result, I took on greater leadership of the project management and needed to take time to collaborate with this new stakeholder to ensure the project aligned with their vision and goals.

Platform Constraints
HubSpot had a very particular templating structure for blogs and it was unclear if our new information architecture and UI design would be feasible to implement.

Incomplete Design System
While the design system I was building out at the time did have some UI guidelines in place, it certainly wasn’t complete and I needed to take time during the project to add to the documentation.

Process

Overview

Our team followed a modified combination of AJ&Smart’s Lightning Decision Jam and Design Sprint 2.0.

Since our team had limited capacity to tackle a blog redesign amidst all of our other projects, my project manager decided it was the perfect time for our team to try conducting a Design Sprint. She used a modified version of AJ&Smart’s Lightning Decision Jam and Design Sprint 2.0 (a 4-day variation of Jake Knapp’s Sprint) to construct our process leading up to implementation.

*The team decided to wait to launch the blog until the website refresh went live.

Define Problems & Solutions

To gain alignment quickly, our team conducted a workshop to identify the most important problems to solve and the most impactful solutions to implement.

During the 2 hour workshop, our team first spent time mapping out the current successes and problems with the blog. Next we voted on which problems we thought were most important to solve and turned our top rated problems into How Might We questions.

From there we ideated solutions for each of the How Might We questions and voted on which solutions would best solve those questions. We then identified known constraints and potential risks which helped the team to prioritize our solutions on an effort/impact scale. Using this scale, our team was able to quickly determine which solutions offered the biggest impact for the least amount of effort and that we should prioritize in our Sprint.

Workshop Results

Determine Goals

Based on our prioritized solutions, the team defined five key metrics to track success.

The team got back together after the workshop to discuss and define what metrics we would use to track the success of our project. We decided the following five metrics would be the best way to track the effectiveness of our proposed solutions:

• Decrease avg. page load time
• Increase pageviews (specifically on post pages)
• Increase avg. time on page
• Increase returning visitors
• Increase pages per session

Map & Sketch

Our team began the Sprint by identifying our target customer moment and sketching detailed, opinionated solutions to our prioritized problems.

For our first exercise in the Sprint, the team created a simple map of the major steps blog readers needed to take on the blog to reach our goal of promoting brand awareness. This map allowed us to pick who our target customer and moment should be while completing the rest of the Sprint.

• Target Customer: Alumni
• Target Moment: Inspire

Next, our team searched for and recorded existing ideas on other blogs and websites that we could remix and improve in our solution for the NOLS Blog.

Then, to generate competing, thoughtful, and concrete solutions that could be critically and fairly evaluated by the rest of the team, we spent time separately sketching out solutions to the blog’s problems. As part of this process we each gathered key information, doodled rough ideas, tried rapid variations, and drew a single well formed concept with all the details worked out.

Decide & Storyboard

Using our solution sketches, the team determined which ideas we should prototype and how the prototype should work.

To figure out which solutions we should prototype, the team silently reviewed all our solution sketches, dot voted the most exciting features, briefly discussed each solution sketch while noting standout ideas, and dot voted our top solutions. Our team then combined our top three solutions into a single sketch and presented it to our Director of Marketing for approval.

Similarly, to align on how the prototype should work while testing it with users, the team proposed six step storyboards, dot voted our favorite steps, and then consolidated the winning steps into a single storyboard flow.

Prototype

Based on the team’s proposed solution sketch and storyboard, I created three high fidelity mockups in Sketch for use in a clickable prototype.

While working on the high fidelity prototypes for the blog, I focused on creating a new visual style for the NOLS blog that was much cleaner, minimalist, and modern (taking heavy inspiration from my work to redesign NOLS’ advanced search feature). I focused most of my energy on reenvisioning the post pages for the Blog since they were the most visited pages on the site. Due to time constraints and another competing project, another teammate stepped in to help me finish up the bottom of the homepage mockup. They were also responsible for stitching all the mockups together into a clickable prototype and narrating a trial run walkthrough of the prototype to the rest of the team.

Test

Another teammate created a testing script and conducted five in-person moderated usability tests with NOLS alumni on a high fidelity clickable prototype.

In an effort to evaluate the experience of the blog’s target customers with our new prototype, the team’s designated interviewer recruited five recent NOLS alumni (who had just returned from a course) to take an in-person moderated usability test at a desktop computer. Below are the findings they gathered from these sessions:

Key Takeaways

Prototype

After the Sprint, I further refined the visual design of our testing prototype and created four high fidelity design mockups in Sketch of all the blog’s page templates.

Following our team’s Sprint, I further refined the visual design of the testing prototype’s post page and homepage. I also designed two more page templates that were not part of our team’s testing prototype but would be needed for the blog, a category page template and an author page template. In addition to creating these four high fidelity mockups, I documented and created guidelines for this new style in WindPants, NOLS’s primary design system, which I was working on building out at the time.

Develop

Based on the four high-fidelity mockups I designed, I coded four blog page templates in HubSpot using HTML, HubL, CSS, and JavaScript.

Architecture Set Up

The file architecture I chose for this project was almost entirely dictated by HubSpot's templating system for blogs. At the time, HubSpot only had two blog templates: a listing page template and a post page template.

The listing page template had conditional logic in it to display: 1. a list of all blog articles in reverse chronological order (newest first, oldest last) on the root url of the site blog.nols.edu, 2. an author avatar and bio along with a filtered list of blogs below by that author in reverse chronological order on the following url paths /author/[author-name], 3. a list of all blog articles of a certain tag in reverse chronological order on the following url paths /tag/[tag-name].

Both of the templates were built from global header, content, and footer modules, which consisted of HTML + HubL, CSS, and JavaScript files. In addition to the blog’s coded module files, I also set up a global CSS file and a design token file for all our design system values.

Tech Choices

Languages
While the languages that I used in the project were mainly determined by HubSpot—HTML + HubL, CSS, and JavaScript—I did make a choice to use as much semantic HTML markup as possible to improve code quality (e.g. clarity, maintainability, accessibility, SEO).

Template Logic
To realize our team’s new blog design, I reworked the old listing page logic to account for a more customized homepage, category pages, and author pages.

Trade Offs & Alternatives Considered

Pagination vs. Load More Button
The implementation of a more customized homepage, category pages, and author pages required the replacement of the pagination on list view pages with a load more button. The load more button did come with the limitation that however any posts made available would have to be preloaded (in this case this would be 200 the maximum amount of posts HubL would fetch), which meant it would come with performance costs. Native lazy loading helped a ton with this and minimized the performance costs to an acceptable level.

Reformatting Posts vs. Semantic HTML
If we wanted to use the maximum amount of semantic HTML on the blog, it was going to require our blog writers to hard code in <figure> tags values into each blog post where they added photos in each post since HubSpot didn’t have <figure> tags as an option when inserting photos via the content editor GUI.

It would also require our writers to reformat all previous posts, which totaled about 1,000+ posts at the time. Our writers decided that making the blog as accessible as possible was a priority to them and they agreed to implement the needed changes on all blog posts (future and past) as part of an audit they were conducting across all blog posts.

Image Heavy Designs vs. Performance
Our new designs were image heavy to entice readers, however that did come with performance costs at load time. Native lazy loading helped a ton with this and minimized the performance costs to an acceptable level.

Challenges & Failures

Homepage Performance
I struggled with the homepage’s performance before native lazy loading existed. The logic being used to fetch the post data was all done in HubL + HTML, which I couldn’t get to work with any lazy loading JavaScript libraries available at the time. As a result, my initial page load times for the newly coded pages were absolutely abysmal. When native lazy loading for browsers became available and I could add it straight into my HubL + HTML, it had a profound impact on page load time performance.

Another part of load time performance that the writers needed to be responsible for moving forward was image size. For any future blog posts, writers needed to make sure the file sizes of the images they were uploading were as optimized and as small as possible (there were some pretty horrendously large images files uploaded for some blogs).

Font and Spacing Units
I carefully considered whether to use rem or px as my units for font size and spacing since I wanted to ensure my interfaces were accessible. I read lots of conflicting opinions online, one side arguing for px because it gave users the ability to zoom without breaking the page layout (and that if a page was built entirely with rems then it essentially functioned like zoom). The other side argued that if users can set a base font size in the browser then all web pages should respect that and size text accordingly while not breaking the page layout.

In the end I ended up going with rem because it seemed to give users more options for how they made the page more accessible to them—either by adjusting base font size or zooming the page. I’m not entirely certain that my implementation prevented the page layout from breaking at some point (since not all values on the page layout were in rems—I did use percentages for some layout widths/heights and px for breakpoints).

Need for a Test Blog
To visually test what I was coding in the templates, I set up a test blog and created test posts; this was time consuming to do (sadly I couldn’t copy over posts from our main blog). However, this was a necessary tradeoff in order to test my code.

Old Post Clean Up
When a new senior writer joined our team, they conducted an audit of the site and suggested a new set of categories for all our blog posts as well as the removal of very old posts. The writers spent a good deal of time going through all posts on the blog to retag them or delete them. Along with this work they helped me to implement semantic HTML images and synopsis text for each post.

Solo Dev
As the only developer on this project I didn’t have anyone else to get feedback from or bounce ideas off of, which was a challenge at times and could have made my work stronger.

Realign, Prototype, & Develop

When a new senior writer joined our team, I collaborated with them on another round of mockups and development to ensure the project met their vision and goals.

After I had finished designing and coding the new blog pages, our team decided to wait on launching it until our refresh of NOLS’ main website went live since the blog’s new style mirrored that of the refresh.

While we waited for those changes to launch, my project manager left the team and the original senior writer was replaced by someone new. This new senior writer conducted an audit of the blog and crafted a new strategy and recommendations for our team to implement. I collaborated with the new senior writer on another round of mockups and development to make sure the new blog met their new vision and goals.

Outcome

What Happened

Post launch, NOLS’ blog experienced a -29% in average page load time, +16% in pageviews, +9% in average time on page, +8% in returning visitors, and +3% in pages per session.

Three months after the launch, the redesign was responsible for a:

• -29% decrease in the average page load time year-over-year
• +16% increase in pageviews on post pages
• +10% increase in pageviews on all other pages
• +9% increase in average time on page
• +8% increase in returning visitors
• +3% increase in pages per session

This data strongly suggested that the redesign had improved the blog’s user experience and was not only attracting more readers but also enticing them to spend more time on the blog.

After this three month period, I was unable to continue tracking this data because both of our blog writers were laid off due to the COVID-19 pandemic* and content was no longer being regularly published.

Lessons Learned

Always give users autonomy with accessibility.
If there are multiple ways to account for a user's need with regards to accessibility then all those ways should be accounted for—you should never assume how users will interact with a web page or browser.

Using native and semantic markup can have a powerful effect on performance.
Native browser features (such as lazy loading) and semantic markup (such as in HTML) should always be used when possible to improve code performance, clarity, accessibility, and maintainability.

Setting up structured processes and discussions are crucial for quickly creating the right thing.
Having processes in place to quickly understand problems, how to solve them, and what’s the right thing to build are invaluable. Being intentional about structuring discussions, involving stakeholders early, and getting team buy-in/trust will save tons of time on a project.