Prior to July 2017, it had been over two years since the HubSpot blog had been redesigned.
Now, in most circumstances, two or three years doesn’t seem like an awfully long time. But thanks to the pace of technology, the blog’s design and experience seemed to be fading faster than normal – as if it were aging in dog years.
This isn’t something we noticed in a moment of clarity, though. The limitations of our existing design had been on our minds for a while. In fact, it would often come up in meetings or get dropped in passing conversations — but we weren’t in a position to do anything about it at that point.
After all, redesigning a blog is an investment of time and resources. It requires focus, collaboration, and extreme organization. And it was hard to get all of those things — time, resources, focus, collaboration, and organization — to align all at once.
But hard doesn’t equate to impossible. And at the end of the day, it was inevitable: We needed a new canvas for our content — one that reflected our brand, our message, and our direction.
That’s why, nearly a year ago, we set out to design a new iteration of blog.hubspot.com. One that could keep up with the speed of change and provide our readers with a better experience.
It took a small army, but we got there. And now that we’ve had a moment to stand back and reflect, we want to share the process with you — from the proposal to project management to flipping the final switch. Below, we’ll walk you through a month-by-month overview with the hope that it helps you better organize your next redesign project — and we’ll even throw in some additional free resources along the way.
For us, the redesign process started approximately nine months out. While nine months might seem like a long time, getting the project on everyone’s radar early makes it easier to negotiate resources, budget, and scope.
Prepping for the Proposal
The first step in getting the ball rolling was meeting with the actual blog team (writers, editors, and managers) to discuss the following:
Some of the recent challenges we'd experienced with the limitations of the existing design.
Considering it had been a few years since we’d revamped our blog, there was no shortage of pain points to be addressed here.
For example, our existing design allowed for visual content, but it wasn’t properly set up in a way that made that type of content shine. In other words, we could embed videos, but they got lost in the text. And we could include photos, but they were constrained to the width of the blog.
Other issues we identified: page load time, user experience, conversion rate optimization, content discovery, and site architecture.
>> Tip for Marketers: If you’re even thinking about proposing a blog redesign, start putting together a list of these pain points now. Then, when you’re ready to start planning your pitch, go back and tie each issue to a metric or initiative it’s negatively impacting. The more real numbers you can pull to demonstrate the impact it’s having, the better.
Features and functionality we'd like to implement to future-proof our design.
1) New post types of multimedia content.
With video and audio quickly become the most desirable content formats for consumers, we wanted to introduce new post formats designed specifically for those mediums. These new posts types would allow for that type of content to take center stage, and create a divide between our more visual, interactive posts, and our standard informational written guides.
2) An infrastructure for organizing posts by topic over keyword.
After recognizing both a shift in the way search engines deliver results and the way searchers input queries, our in-house SEO experts introduced the team to a new way of looking at content mapping and search engine optimization.
The topic cluster model puts topics before keywords, allowing a single "pillar" page to serve as a hub of content for an overarching topic. From there, "cluster content" covering related long-tail keywords then links back to the main pillar to boost its authority. This approach aims to create a more intentional link structure across the blog properties, making it easier for Google to crawl and rank our content. This is something we needed to solve for if we wanted to organize our content this way at scale in the future.
3) Modern ways to share content
Our existing design made it easy for readers to tweet or our articles or share them on Facebook -- you know, the standard approach to social sharing -- but it ended at that. And since our last redesign, audiences have grown used to consuming and sharing content on new platforms -- think: Slack and Facebook Messenger.
If we wanted our new design to stand the test of time, we needed to introduce these sharing options now. Even if our entire audience wasn’t using them at the time of launch, we trusted the user growth numbers for each of those respective platforms enough to include them in the sharing functionality during this iteration.
4) New conversion points
In the past, we offered a few different conversion points on each of our blog posts: bottom of the post CTAs, slide-in CTAs, and anchor text CTAs. While these CTA types continue to help us generate leads for our business, we wanted to ensure that CRO was something we were constantly iterating on.
With the new redesign, we wanted to offer a new way for visitors to discover our free guides and reports -- a more contextual one. The hope was that a fresh conversion point would help us solve for some of the inevitable banner blindness our readers were likely experiencing, while improving the reader’s experience overall.
5) More consistent branding.
Back in 2014, our blog redesign was fresh and innovative -- it sparkled. But in 2017, well, it just felt like it had lost its luster. It lacked the influence of our brand values and it didn't mesh with some of the newer, more polished pages across the website. And perhaps most importantly, it didn't reflect our current brand -- let alone the direction our brand was going in. If we wanted to stay ahead of the curve, we needed to make some changes that were more indicative of the direction we were headed.
Other blogs we admire.
“Every new idea is just a mashup or a remix of one or more previous ideas,” explains author Austin Kleon in his book Steal Like an Artist: 10 Things Nobody Told You About Being Creative.
And that’s exactly what we did leading up to this redesign: We hunted down every design we’ve ever been envious of and looked for ways to mix and match the features and functionality to meet our audience’s needs, as well as our own.
It’s important to note that we didn’t limit ourselves to just our industry when pulling inspiration. In fact, we’ve found that it’s often better to look outside of your own industry when sourcing inspiration, as it forces you to think more objectively about the different design elements.
>> Tip for Marketers: Secretly admiring your competitor’s website? Don’t be afraid to surface this in the buy-in meeting. The last thing your stakeholders are going to want to hear is that your company is falling behind the competition. This could be the push you need to secure the budget and resources.
From here, we focused on prioritizing our challenges in terms of importance and impact, as well as defining which wants and needs were:
- Better suited for V2
This exercise helped to ensure that our core team was on the same page going into the larger discussion meeting and provided us with a clear sense of scope.
At this point, we were ready to involve other stakeholders, including representatives from design and development, optimization, and branding.
The Buy-In Meeting
Getting buy-in for a redesign project is typically easier said than done -- especially if your stakeholders or C-suite doesn’t see the value. To combat this, it’s critical that you deliver your upfront research in a way that proves the project is more than just a cosmetic procedure -- think: improved metrics, better user experience, more opportunity for generating MQLs, etc.
Aware that we'd needed support, resources, and approval from other departments to move our ideas forward, we approached the initial redesign proposal meeting with a few things in mind:
Ask for more than what you need.
Sometimes you need to ask for more than what you need in order to get what you want. It’s a classic negotiation technique, after all.
Remember how we organized our wants and needs into three categories – non-negotiable, nice-to-have, and V2 – in the meeting prep? By peppering in a few nice-to-have features in with our non-negotiables, we upped our chances of more getting done by simply aiming higher right out of the gate.
This is a great strategy when it comes to getting more than you expect, but only when it’s balanced with our next point ...
Whether you work on a large marketing team or a small one, there is never any shortage of work for the designers and developers to complete. And as you approach a buy-in meeting, it’s important that you don’t lose sight of this.
While we had a timeline in mind going into the meeting, we were willing to meet the other teams in the middle if it meant we’d have more resources to devote to a better end product in a few months.
>> Tip for Marketers: Be respectful of your team members’ time. By asking them to devote time and resources to your redesign project, you’re pulling them away from other projects that might have a larger business impact. If they ask you to be patient, don’t take it personal -- just be sure to ask when it would be best for you to follow up or re-open the conversation.
Trust the subject matter experts.
While we’d prepped pretty extensively for the meeting, there was no doubt that our wants and needs lacked the technical knowledge necessary to map out what was both possible and realistic. To keep the project within scope, we needed to trust the feedback from our development team, rather than push back on it.
“The worst thing you can do is make assumptions about projects without discussing them with your developer first. Assuming that a particular task is easy to execute can lead to misaligned timelines and frustration on both ends,” explains HubSpot’s Senior Web Development Manager, Dmitry Shamis.
After both a successful proposal and buy-in meeting, it was time for us to start making things happen. But before anything was drafted or designed or discussed, we had to figure out exactly who was going to be involved -- and what they were going to be responsible for.
Assigning a Project Manager
If there's one piece of advice you listen to here, have it be this: Don't wait to appoint a project manager. This is the person that will ensure deliverables are coming in on time, review sessions are scheduled, the project remains within scope, and the quality bar is being met.
Here on the HubSpot Marketing team, we're lucky enough to have Matt -- our resident senior project manager super hero. Once we determined that the redesign would be moving forward, Matt immediately took the lead on facilitating next steps.
At this point in the process, he was tasked with designing the core project team and getting a kickoff meeting and subsequent daily standup meetings on the books. However, he'd later take on many of the responsibilities I outlined above -- keeping tabs on deliverables, involving stakeholders for approval, mediating roadblocks, etc.
Identifying Roles, Responsibilities & Process
The DARCI Framework
For the sake of organization, we called upon the DARCI framework to serve as a starting point in assembling the core team that would be tasked with driving the redesign. If you're not already familiar, the DARCI framework (Decision Maker(s), Accountable, Responsible, Consulted, Informed) is a tool for establishing clear accountability in teams and organizations.
This framework is designed to clarify accountability and roles, provide a shared language for assigning and tracking progress, and help teams increase productivity by encouraging transparency and follow through.
Here's a look at what we landed on:
Thanks to this framework, we always knew who to involve and when to involve them. Of course, this was a large group – 24 people to be exact – and not everyone listed needed to be involved on a regular basis. That's why, with the guidance of our project manager, we decided to implement an additional operational framework for just the core group that would be executing on the project on a daily basis. Again, the goal of this level of organization was to clarify and document responsibilities, promote effective communication, and help us facilitate collaboration across teams.
The Scrum Framework
The core redesign team consisted of five people: myself (blog.hubspot.com DRI), Matt (project manager), Liz (tech lead), Taylor (front-end developer), and Amelia (web designer). In order for us to balance priorities while operating across teams, we adopted Scrum – an Agile framework that prioritizes teamwork and collaboration through the execution of development cycles known as Sprints.
Source: Scrum Alliance
Each Sprint would last for one month or less to reduce complexity and would be centered on a common goal. For example, the primary priorities of our first sprint were to design wireframes for the homepage and section-level pages and begin development infrastructure planning, which all of our subsequent Sprint tasks rolled back up to accomplishing.
It's also worth noting that the Scrum framework requires teams to appoint a facilitator – or Scrum Master – which we assigned to our project manager, as the Scrum Master's responsibilities include helping with conflict resolution, facilitating consensus, encouraging discussions, planning and implementing Sprints, and moving the project forward.
Aligning the Core Redesign Team Around One Vision
With the new team and all of the necessary frameworks in place, we were ready to get to work. Before planning our first Sprint, we met as a core group to realign around the vision and inspiration we'd put forward in the beginning. The goal of this realignment meeting was to:
- Ensure that none of our priorities had changed
- Discuss which features would require the most work
- Determine a Daily Scrum standup meeting time that worked for all parties
At three months out, it was time for us to tackle the bulk of the design and development work. Again, this is where the Sprint cycles came in handy.
We used JIRA – an issue and project tracking software – to plan and track each Sprint. The JIRA software made it easy to assign tasks, track progress, collaborate through comments, and keep everything organized in one central place. Having a visual, easily accessible backlog also made it easier for us to keep other internal stakeholders involved who weren’t working directly on the project but still had a say in the process and approval of specific elements.
Given that receiving feedback early and often was the key to keeping ourselves on track, we also set up milestone review meetings to gather notes from stakeholders and share our progress.
For each Sprint, we aimed to set primary priorities for that timeframe. Here's what those looked like for our first three Sprints:
DESIGN PRIORITIES: Create and iterate on wireframes for post pages and home pages.
In our first Sprint, the focus was largely on design. We started with a very straightforward set of wireframes – no frills or colors, just structure. And after collecting feedback from both the core SCRUM team, as well as the DARCI team, we iterated on those pages until we had something we were comfortable with.
DEV PRIORITIES: Discovery and infrastructure.
For the devs, the bulk of their work was on hold until we landed on a set of designs we wanted to bring to life. Until then, this phase for them focused largely on evaluating the list of proposed features – video and audio inclusions, new social sharing functionality, improved subscribe modules, block quotes, etc. – to determine how we might approach them, what tools we would need, and so on.
OTHER PRIORITIES: SEO + pillar/cluster convos.
One of the biggest aspects of the redesign was figuring out a way to rework our existing and future content by implementing a pillar/cluster model. This model was proposed by our in-house SEO experts as a way to improve our site architecture and make it easier for Google to crawl and rank our posts.
Outside of this model, we also wanted to discuss general SEO considerations for the redesign – things like: paginations, site speed, and H1 tags – to ensure that we weren’t disrupting our search engine authority throughout this process.
DESIGN PRIORITIES: Listing pages, author page, and pillar pages.
In Sprint #2, the design work remained heavy. Aside from designing pages for blog.hubspot.com and our main sections – Marketing, Sales, and Customer Success – there was also work to be done for our post-level, or listing pages. As part of the redesign, we planned to introduce two new types of listing pages: one specific to video content and one specific to audio content.
Outside of those needs, we also wanted to revamp our author bio pages and introduce a new pillar page design that would support or pillar/cluster SEO efforts I mentioned earlier.
DEV PRIORITIES: Homepage, post page, and features.
As designs became more concrete, our dev team had a foundation to start building. Rather than wait for every decision to be made around design colors and details, they got started on constructing the bones of the new blog to ensure that everything we’d discussed up to this point was, in fact, possible to create.
OTHER PRIORITIES: Analytics intro, localization discussion(s).
A large part of this redesign was implementing better analytics and tracking that would help us make more informed decisions about or content – where to feature it, how long it should be, which types of media to include, etc. To make this happen, we put together a document of every aspect of the blog we’d like to track to kickoff a discussion with our analytics team on what was realistic – and what wasn’t.
As for the localization conversations, it was important to initiate these early. We’re a global company here at HubSpot -- we have offices in the Cambridge, Portsmouth, Dublin, Singapore, Sydney, Tokyo, and Berlin. In other words, we have a lot of blogs, catering to a lot of different audiences. And as part of this launch, our goal was to roll this new design out to all of our blogs, which requires a lot of communication, adaptation, and understanding of one another’s goals.
DESIGN PRIORITIES: Tweaks from Sprint 2 demo and pillar page finalization.
As we collected continuous feedback from our stakeholders on the designs, our designer stayed busy iterating into Sprint #3. At this point, most of the changes were small, yet important nonetheless.
DEV PRIORITIES: Post Page features, Listing Pages, July 1 Success prep.
With most of the design work complete, the devs were hard at work making all of the new features come to life. At this point in the redesign, we also launched a new domain: blog.hubspot.com/customer-success. This domain wouldn’t go live on the main blog.hubspot.com homepage until the full redesign launched, but we wanted to give ourselves enough time to start publishing early so that there would be content for visitors to consume once we were ready to make it public.
Between Sprints, we'd hold Sprint planning meetings to help us get organized for the next set of priorities. These would be held prior to the previous Sprint ending to ensure there were no gaps in progress. During each Sprint planning meeting we would assign "story points" to individual tasks. While many teams tend to give estimates in terms of hours, story points allowed us to quantify effort in a more meaningful way.
The number of story points assigned to a task should take into account risk, complexity, and blockers, as well as the actual amount of work being assigned.
As for making a final decision around how many points to assign, developers, designers, and stakeholders should weigh in first if it's a story in their lane. For example, if the task is to design a wireframe for the author bio page, our designer – Amelia – should be the first to suggest a set number of story points. Once the subject matter expert has weighed in, the larger group can discuss whether or not it seems appropriate or if it should be adjusted.
The most common story point range is the Fibonacci sequence – 1, 2, 3, 5, 8, 13, 21, 34, 45 – where each number is the sum of the two preceding numbers. However, your team can adapt this scoring system to more accurately fit your needs. The important thing is that you have a baseline story that everyone can use to weigh their point distribution – think of this as a benchmark.
Once you have story points assigned, you'll then have a sense of your team's velocity – aka the sum of the story points completed in any given Sprint. For example, if a Sprint contains eight tasks or user stories, and the total number of story points is 21, the team's velocity is 21.
Keep in mind that velocity has the potential to change from one Sprint to another based on how far along you are in the project, roadblocks, vacation time, competing priorities, etc.
At this point, we could see the light at the end of the tunnel. Sprint #5 was all about finishing touches and perhaps most importantly, QA or quality assurance. This was the final Sprint we’d complete leading up to the actual launch date.
- DESIGN PRIORITIES: QA
- DEV PRIORITIES: Loose ends, QA, special requests
- OTHER PRIORITIES: QA, editorial calendar planning, blog team training, and V2 planning
For us, the QA process involved a lot of external team members. To ensure that we were covering all of our blind spots, we wanted a QA team that consistent of both folks that were close to the project, as well as colleagues that were seeing it for the first time.
As for the actual QA process, we sent out a document with instructions on how to get started. Quite simply, we needed folks to:
1) Test everything.
Look at new pages on as many different browsers/devices as possible – smartphones, multiple browsers on your laptop, etc. QA should include: testing functionality, testing linking, and testing front-end aesthetics.
2) Log any issues using JIRA.
Include the device type and a clear explanation of the issue. From there, our devs would monitor JIRA to triage any outstanding issues.
Editorial Calendar Planning
From a content standpoint, we wanted to be sure that we were launching the new redesign with posts in the pipeline that reflected our high quality bar.
This meant planning blog content a few weeks in advance to ensure that there would be both a variety of topics being released during what we’d hoped to be a high traffic period for us, as well as a variety of post formats -- including video, audio, and visual posts.
Blog Team Training
While the blog team had been consulted throughout the redesign process, the redesign brought about some changes to their workflow that needed to be addressed before any switches were flipped.
These changes were mostly small content input considerations – how to format the new pull out quotes, how to insert featured images and image overlays, how to assign pillar pages, etc.
To solve for this, we set up a redesign overview training for all of the blog stakeholders to participate in, and documented it via both a recording and an internal Wiki page – ensuring that new hires and other internal contributors would be able to easily navigate the new process.
V2 Planning & Optimization
Constant iteration is key to a successful blog redesign – or any redesign for that matter. Here at HubSpot, we refer to this approach as Growth-Driven Design, where the goal is to launch quick and improve as needed once you have some data to inform your choice.
While this project took a little more upfront work than a typical Growth-Driven Design process, we plan to lean heavily on the process post-launch by measuring user behavior through heat maps and using that data to inform feature and functionality updates.