Managing Research, Relationships, and Expectations During Your Website Redesign

Today's guest post comes from digital marketing expert Justin Dunham. Enjoy!I was once asked to completely rebuild a corporate marketing site within six weeks.The project included rewriting all content, creating a brand new identity, changing the CMS backend, and adding e-commerce. Our brand-new CMO insisted on personally approving each piece and told me there was no time or budget for testing.

Conversions went down 70% after the launch

And on top of that, nobody used the store. The site took us over a year to fix. It happens a lot, despite all we know about the importance of testing. Sites, stores, and applications get launched on tight timetables, with input only coming from inside the organization. You also may need to deal with lots of stakeholders, with widely varying opinions, priorities, and knowledge.Once you get your project launched, the truth will become clear. But it might have taken months to get to consensus on the site as originally launched, so how can you now incorporate what you’ve learned from testing while not kicking off another round of debates? And how will you get the resources for a significant overhaul of the site to line up with what you’ve learned?

Before the launch

Be positive, but prepare everyone for the reality that you won’t get it right on the first try.

Try these three mantras to get yourself (and your team) into the right mindset.We should all be excited about the launch. And it’s not THE launch -- it’s the first launch.There’s a strong temptation to launch a site, consider it finished, then leave it alone for months, or even years. This is bad by itself, but it’s critical to avoid this if you know the site might fail right away.Instead, help everyone understand that websites should change over time. That gives you flexibility to fix the problems you see, and prepares everyone for the reality that a great site is an ongoing investment of time and money. It also lowers the stakes behind the decisions you make. If the site can be changed at any time, then maybe it’s not as important for the CEO to get her way on having a front page carousel -- or maybe you can reduce your own frustration, knowing that it can be changed if it doesn’t work out.Thanks for this idea!As you’re building your site, you will probably get some suggestions that you don’t agree with, or even that run contrary to good site design. It’s difficult to balance what to accept and what not to, and you have to make the decision based on who asks, and what the effects are.But in order to have a chance to implement your own ideas later, you need to accept feedback as well as you can. Making the effort to implement others’ ideas makes you look like a fair arbiter, which will make bad news easier to deliver later.  Let’s do it your way.If you know you’ll need to make major changes to the site anyway, pick your battles as to what input you’ll accept and what you’ll dismiss. In some cases -- for example, an overbearing senior leader -- you won’t have a choice, so it’s easier to just deliver what’s being asked for in the most gracious way possible. But even if you do have a choice, it’s important to keep your reputation as someone who can work collaboratively. This helps everyone feel invested in the success of the site, and also lets you say that you tried everything. If things don’t work out, you can then try out your own ideas.

Begin a partnership with your user research team

You might be lucky enough to have a customer or experience research team in house. Part of your job as a web or product manager is to have a relationship with this team. So if you don’t have that relationship already, build it before you launch a new site. Part of your job is to have a relationship with the research teamYou and your research team need to be prepared with a plan for how you’ll test the site, who you’ll talk to, and what questions you’ll ask. It’s important to get this right. People can be resistant to outside user testing -- the most common objection is that users outside the company “don’t represent our audience.” I’ve seen people say this even when the test subjects are actual customers.To guard against this, focus on usability and other issues that are common to all site visitors, not just the specific people you need to reach. Figure out what tasks visitors need to accomplish -- finding an item and then purchasing it, or perhaps learning more about your company -- and then see if the people you recruit for your study can do those things with no guidance. Figure out what tasks visitors need to accomplish, and then see if the people you recruit for your study can do those things with no guidanceModerated tests will typically give you a better understanding of your site’s usability, since the moderator can ask for clarification and follow up with the user’s thought process as they are working through a task. But it’s fine to use an unmoderated test, especially if you’re just trying to get an initial read. Find a balance between something that will you give good, defensible data, and what you can afford.   Run these tests as soon as possible after launch, and on a regular basis afterward.

After the launch

Start with your sponsor

So you’ve run user testing on the site, and you’ve now identified that some things need to change. How do you get those changes approved? Large projects such as a website or product launch will often have an "executive sponsor" who -- formally or informally -- has taken responsibility for the successful launch of the project and for getting buy-in with other, more senior, executives. What if there isn’t a specific executive sponsor? In that case, assume that your manager is in that role. The key is to pick someone who is highly invested in the success of the project, who you have a good relationship with, and who has credibility with senior executives.Gather all the information you can about how the site is performing. That will definitely include the results of your user testing. If you have analytics data, you’ll want that too -- for example, if you don’t believe your users understand how to use the menu on your site, can you show heatmap or clickstream data that demonstrates that they aren’t clicking there? Or can you show dramatic changes in bounce rates that demonstrate the new front page isn’t engaging for visitors?You’ll want to put all of this together into some kind of presentation that includes what you’ve learned, what it means, and, most importantly, your specific recommendations for how to fix the problems. This last part is by far the most important. Any executive you talk to about a massive undertaking like a website will not have the necessary background to figure out what needs to be done. This is your chance to make a proposal and have it stick.

Figure out who the remaining stakeholders are, and how to sell them

Most stakeholders will have an intense focus on the site as you’re launching, but won’t want to spend as much time on it when it’s already up. That’s helpful for you, since it makes it easier for you to make changes. But there are still a lot of people who your changes will affect. In the case of re-launching a web application, you may only need to deal with the product team, and you might be a part of that team, anyway. But if you’re dealing with a corporate marketing website, your customers will include all of marketing, much of sales, and the product team. It’s likely that the head of your division -- or even the CEO or other senior executives -- will need to be kept informed as well; your sponsor is the right person to ask for help.Once you’ve figured out whose input you really need, it’s important to position your recommendations so that stakeholders see them as a win for their teamOnce you’ve figured out whose input you really need, it’s important to position your recommendations so that stakeholders see them as a win (or, at least, not a loss) for their team. For example, let’s say you need to change your website navigation, removing some items that visitors aren’t interested in but that powerful constituencies have requested.

• Offer an alternative that still accomplishes stakeholders’ goals. For example, can the pages that aren’t working in the navigation bar be moved somewhere else, where they’ll be more effective?
• Focus on high-level goals. In this example, are irrelevant navigation items causing visitors to bounce, which hampers marketing effectiveness?
• Position the change as a way to learn more. You tried things one way, wholeheartedly, and it didn’t work. That’s OK, and now it’s time to try things a different way.
• Take things one at a time. If the new navigation scheme you came up with isn’t working for visitors, fix that before you fix the writing on the site, which takes longer. Focus on acquiescence, not getting active approval for every change.

Get resources in place and get started

Once you get agreement on a change, move fast to get that change implemented. Hopefully, as the person who owns the website, you have in-house engineers, or an agency, that you can lean on. If not, and you need to ask for resources, you’ll again want to quantify. Quantifying the impact of improvements in UX is not easy, but often you’ll see these numbers show up in revenue or customer satisfaction scores, or more basically in bounce rates, leads generated, and perhaps even overall traffic. Make sure you document these changes so that you can go back and look at them later.