Time To Upgrade
You’ve done it! You’ve created a successful technology tool or service, and users are lining up to use it. Of course, those users are going to need support. And let’s face it: the support platform that got you through your first year or so simply isn’t going to cut it now that your user base is growing and their needs are getting more complex.
Platforms don’t tend to get better as they age. Often, outdated technology or a design that wasn’t user-centered can hurt engagement. Users face difficulty finding the information they need, or participating the way they’d like to in a support community. Often community support sites fail to properly reflect their parent brands (though of course they do contribute to your users’ impression of your brand!).
An information architecture and content hierarchy that was built in a simpler time may now be leading to a larger administrative burden as your content and product experts struggle to find the right answers to users’ questions, or point them to the right resources. Time-to-answer goes up, user satisfaction goes down, and before you know it, your great support site might be doing more harm than good.
So, time for a redesign and a rebuild to take advantage of the latest technologies, a better design process, and a revamp of your IA and content strategy. Great! You just have to accomplish that while making all your internal stakeholders happy. Simple, right? Unless of course your stakeholders don’t all agree on what success looks like. And some of them don’t even think you should be spending resources on this with so much else on your plates. What to do? How do you get your stakeholders aligned in support of a new or improved customer support platform?
Not all stakeholders are created equal
Before you can focus on how to better serve your users, you have to have your internal stakeholders on board with your vision. A great place to start is by clearly articulating that vision. It’s not enough to simply say “we’re going to make the site better,” you need to actually describe how things are going to improve because of this project. Engage in some visioning and goal-setting exercises and invite other stakeholders to join you. Letting everyone have their voice heard can go a long way towards stakeholder buy-in, even if you don’t end up using everyone’s ideas.
Speaking of which, you probably shouldn’t use everyone’s ideas. Not all stakeholders should have the same level of input into your new platform. Certainly you need to gather input and feedback from all relevant parties (including the executives, of course), but in the end, you need someone in a strong Product Owner role who is empowered to make decisions about what will best serve the group, the product, and your customers.
This will mean saying no to some people’s ideas, or maybe “let’s put that on the backlog for a future release.” Not all ideas have to make it into Release 1. Focus on what’s most important, and be transparent about how you’re defining priorities for your initial release.
Focus on outcomes, not features
A great way to get people on board with your vision is to keep the focus on outcomes as opposed to features. Look back at those vision statements you created - how will your customers benefit from the changes you’re going to make? How will your internal users? How will you lower your cost of ownership? How will you increase velocity on support tickets? Uptime? Time spent getting IT to make changes that a content editor should be able to make?
By focusing on the outcomes you’re trying to achieve, you can elide discussions of “my feature vs your feature.” It also keeps people focused on the big picture, so the Product Owner can focus on the details. “Easing the administrative burden” is more compelling - and less likely to lead to arguments - than “Implementing a new workflow system.”
The discussion about which features will best achieve those outcomes is an important one, but that’s for the product development team to tackle, and doesn’t need to include every stakeholder.
Why did you build that?
Once you’ve decided what features will best support your vision, you’re eventually going to need to explain those decisions to other people. Data can be your friend here. If you can point to research and data and explain how they informed your product design process, you will put a lot of stakeholders at ease, as well as help them to understand why their pet feature may have been de-prioritized for the upcoming release.
So how do you get that data? Start with what you know: what do your analytics tell you? What features are users using the most? What are they never clicking on? Keep in mind that analytics don’t tell the whole story; for example users might not be using the “Suggest a product feature” feature on your support site because the information architecture doesn’t provide a clear path to it, or users might be making heavy use of a particular feature because it’s featured on the homepage carousel, not because it’s the best tool for the job. But the analytics give you a starting point.
From there, there’s no substitute for real user research. Field a survey, do some user testing, see what their pain points are with your current solution, and see how they really use it. Does it meet their needs? Could it do a better job?
Remember also that your users don’t spend all day thinking about your site like you do. What is the rest of their day like? What’s the context in which they are coming to your site to get help or to help someone else? Usually when users are looking for help with a technical product, they are already in a heightened emotional state when they get to your support site. Are you designing with your users and their journey in mind?
Learning and thinking about the path your users take to - and on - your site will not only help you make informed decisions about your support platform, they give you ammunition when it’s time to defend those decisions to other interested parties. Your customers will thank you, too. Your users may not know that one site employed user centered design principles and another one didn’t, but they can feel the difference, and (even on a subconscious level) they will make associations with your brand based on it.
The users don’t work here
What if your users’ priorities don’t align with your business priorities? For example, the business may be focused on getting customers to convince others to sign up for the platform, but users may be focused on finding a quick answer to their question or watching a training video. By thinking about your information architecture and your content strategically, you can plan out pathways between user priorities and business ones.
For example, a strategic call to action (CTA) for a customer to recommend your product or service to a colleague can yield results - if it’s presented at the right time. Showing that prompt right after you’ve answered a customer’s question is going to be more impactful than just putting it on the homepage and hoping someone clicks on it.
To measure and refine that impact over time, think about where you might want to integrate with an A/B testing tool so that you can measure the effect of small changes to your content (even your microcopy) and your design choices. That information also helps by giving you another data point to take back to your stakeholders when explaining your design decisions.
Measure, build, repeat
A/B testing is a great source of data, and you should make sure that it’s part of a larger set of meaningful metrics that you will use to measure the success of your new platform. Your organization probably has KPIs already in place, but those aren’t sufficient; you need to think about what metrics you can really measure from your platform and how those metrics map to the larger organizational KPIs. Numbers are a powerful tool to help get stakeholders bought into your vision, especially the ones whose budget is going to be impacted by your project.
“Measure twice, cut once” doesn’t apply here. Measurement should be something you plan for right from the beginning. Make sure that you’re measuring meaningful things, and if you discover you aren’t, adjust over time. Ensure that stakeholders have access to this data in a way that will be usable for them, like a reporting dashboard or a custom export based on their needs. Often, the numbers will make a strong enough case for your vision that you don’t have to do much more to win people over.
These measurements should also inform subsequent releases and priorities. Again, analytics aren’t the whole story, but if you’re measuring things that matter, you at least have a starting point for what to focus on in the future. Don’t keep the data to yourself. Even if you’ve provided dashboards, they might not get used, so put a schedule in place to regroup with your stakeholders on an ongoing basis to keep them informed of your plans for the future, as well as the data to back up those decisions.
Everyone’s a user
The time and thought that you put into planning your new customer support platform will help your customers by giving them a single place for product support and information where they can quickly find what they need and are incentivized to participate.
The same goes for your internal users; content editors, product managers, and subject matter experts will all appreciate the work you’ve put into your content strategy, workflow, and governance decisions, even if they’ll never admit it. And your internal stakeholders will be more likely to support your vision and your future efforts if you’ve put in the time to make them feel heard, keep them informed, and explain your decisions to them with supporting research and data.
A strong product strategy that relies on user-centered design, best practices in information architecture and content strategy, and an emphasis on good user experience design will help you support customers, achieve your business goals, and get stakeholders on board and bought in to your vision and your project. What more could you ask for?