I was talking the other day with some friends on the HubSpot Product UX team about how much we try to find new ways to listen to our users and then act on what we hear, and it got me thinking about how many more of our senses we rely on in our pursuit of good UX design at HubSpot.
Quite a few, really, if you’re willing to stretch a point. And never let it be said I don’t know how to stretch a point. I’m a pretty big fan of puns and mixed metaphors, too, but that’s a horse of a different feather altogether. Ahem.
Still, we know that we build better experiences when we’re more fully alive to how our users are feeling and engaging with the product we build. So why wouldn’t we want to engage all of our senses in that noble pursuit?
Here are some of the ways we use our senses as a UX team today.
Our UX researchers are on the front lines of designing and running the testing we do. But because we’ve designed our UX teams to be truly embedded, multi-disciplinary teams, those research calls are also often designed, led by, and analyzed by content designers, product designers, and product analysts, too.
If there’s a question we’d like to pursue about a naming convention, mental model, metaphor, or a semantic shift in the air, it might be a content designer leading the charge. Or maybe we’re interested in learning more about task completion, ease of discovery, or something else. Whatever it is, we’re tuning in and doing our best to listen more than we talk.
Salespeople have incredibly illuminating conversations all the time with people who are just learning about HubSpot and deciding whether or not it’s a good fit for them. What’s on their minds at this stage of the process? How does an experienced sales rep tend to answer the questions people most often have?
It’s been particularly eye-opening to check in from time to time on how salespeople at HubSpot demo the product in 10 minutes or less. So many times, we’ve learned about a piece of the product or a task our users need to perform that we didn’t even realize was tops on their list.
Like when our sales reps told us about how much our sales users wanted a certain kind of filters in our free CRM. We were able to weave that insight not just into what we built, but how we designed our onboarding for that tool, and how we approached the information architecture and navigation of the tool, too. We’re able to gather those sorts of insights and apply them every day, just by staying close to our sales team.
The customer success team sometimes lets us listen in (with the customer’s permission, of course) to how they introduce new users to the HubSpot software. It often involves a generous mixture of theory and practice, and that gives us incredible insight into the strategic, operational, and tactical pathways our users need to pursue.
For instance, at one point the customer service team got together with us and gave us a list of the top ten actions the happiest and most successful customers take in the product routinely. We used this information to completely overhaul our onboarding flow, so that every new customer could benefit from getting a direct route to what might be the best path to success for them, too. We asked our content designers to create a new narrative for the user’s first few weeks in the product, one that casts them as the hero and agent of change in their own story. It’s been wonderfully successful so far.
For both sales calls and customer service calls, it’s as easy as filling out an internal form to get matched up with a rep whose calls we can shadow for an hour or two. The return on the investment of time is enormous, so most UX team members try to fit a few shadowing sessions in as often as they can.
We also dig in every quarter to the raw NPS feedback results that we gather from users, which often leads us to connect us with a customer service rep who can tell us more about a specific problem a customer is having that led to us getting some negative feedback. From there, the UX team members closest to the product experience in question can work directly with the customer to address the situation and design a solution.
This is exactly the kind of “feedback flywheel” that we rely on to improve our customers’ experience, and that we’ve designed our product to enable for them to act on feedback from their customers, too. Christopher O’Donnell, Senior VP of Product, spoke about this process from the stage at INBOUND this year, and we on the UX and Product team were vigorously nodding our heads. We use this process every day to stay close to our customers and try to give them what they need.
We look at all the available data when we really want to dig in and find out what the larger themes are. Sometimes the UX team on a certain product team will embark on a long-term, intensive project to audit and assess what users really need from an existing piece of the product. These projects often start just by combing through all of the current, relevant feedback that we already have at our fingertips.
Some of the feedback we’re always gathering includes:
- SUS scores
- Help ticket requests, transcripts, and resolution rates
- Net Promoter Scores
- Usability test reports
It’s a lot to go through. But that’s not a bad problem to have. It just means we can’t do this kind of project for every question we have, all of the time. This is usually just for big picture assessments, understanding where the major pain points or potholes are scattered around, and auditing an entire product area to help us prioritize the next long-term stretch of work.
New additions to the UX team almost always remark on how much data they have direct access to to help guide what they do. It’s pretty unique, even in our data-driven SaaS world, to have direct access to as much customer feedback as we do. And even more unusual is how easy it is to either dig into the raw feedback on your own, or find a synthesis of the data that clarifies the trends and big picture.
So if you’re comfortable wading through masses of data (and have the time, and it’s right for the project you’re working on), you can do that. But if what you really want is the nutshell version, you’ve got ready access to that, too.
So UX folks at HubSpot never have to make their decisions blindly, or with their fingers crossed behind their backs, completely unsure if an approach is likely to be the right one to try. We’re able to operate from a firm foundation of feedback, which is pretty rare.
This aligns closely with one of the main principles of the HubSpot Culture Code, where we say that we solve for the customer and look to the long-term solution that will be right for them. Staying close to customer feedback means we never lose sight of what our users are saying to us, so it’s exceptionally hard to act against their interests, even when it might be the easier path.
The first step is to start combing through these existing sources of feedback and start identifying the major recurring themes. Users are generally pretty clear and unflinching when they’re describing the roadblocks or frustrations they face every day.
We’ll categorize and code these into overarching themes, then share what we’re seeing with other members of the team. Do the themes we’ve identified and the severity we’ve assigned them align with what they see? This regular gut-check helps us stay honest and maintain a clear, crisp, and centered understanding of what the user voice says.
Empathy is becoming an overused word in UX these days, but that doesn’t mean it’s an unimportant skill. Really understanding how a user feels when they try to complete a certain task, or find a new tool, tends to bring home just how much there still is to do. Even better is when you know how to pair your empathy with action, and allow what you understand about a user experience to inform your strategy, too.
One of our favorite tools for finding out how our customers feel is an empathy session. This is a fairly informal session where we try to complete a task or a flow as if we were a certain customer at a certain level of familiarity with the tool. It’s not an exact science, but let’s just say that we never walk out of the room with nothing on our list of things to improve.
There’s that old saying in UX that you are not your user. And while that’s certainly true, it doesn’t mean you shouldn’t try to walk in their shoes on a regular basis and see how it feels. We’ve started making empathy sessions a core part of our process, we’ve found it so valuable in so many ways.
Similar to empathy sessions are cognitive walkthroughs. These are more static experiences, where someone has screenshotted every step in the process of a certain task or flow, and each team member present is asked to answer a series of questions about how clear each step is. Again, not an exact science. But always helpful.
Over the last year alone, we’ve run dozens of empathy sessions across our product teams.
Okay, here’s where I start to stretch the metaphor just a bit, but please just bear with me.
The HubSpot software has never really been about just offering a point solution, or merely completing a task. We started off in this world as champions of the philosophy that businesses had to adapt to the new reality that the path to success is to recognize that the customer has the real power and agency in the modern business dynamic.
That can mean you create content that’s focused on their needs, not yours; or your sales process is centered on truly helping, not pushing your solution on prospects; or that your customer service system is built to help you listen to your customer and respond to those needs, not just focused on streamlining and efficiencies to solve for your own bottom line.
Our entire existence is wrapped up in this idea of growing your business by doing the right thing.
Our software is designed to make it easier for other businesses to do the right thing, too. And the flip side of that is that we try not to build things that encourage or enable doing what’s wrong.
In the course of our history, we’ve made some tough and at times unpopular decisions to not build a certain feature or system, because it didn’t pass that gut check. We believe that we have a responsibility to be a force for good in the world, that it’s not enough to just say “well, technology is neutral, so our hands are clean.”
Technology isn’t neutral. And neither are we.
We believe you’re either taking a stand for what’s right, or you’re a big part of what’s wrong.
So we ask ourselves every day: Does the software we’re building pass the sniff test? How closely are we adhering to our customer code with what we’ve just built? Are we using customer data in the most ethical way? Are we just meeting the bare minimum legal requirement, or actually doing the right thing? Is this experience stable? Is it reliable? Secure?
Is the content and design accessible to all? How readable is the text? What if you’re a non-native English speaker? If you have cognitive trouble? What if you’re distracted, multitasking, grieving, or stressed? What if you’re using a screen reader or you’re color blind? Are the visual metaphors in our illustrations inclusive of different genders, cultures, identities, lived experiences? Does everyone “get it?” Who might feel left out?
What sort of business practices are we advocating for in the software we build? Are we encouraging our customers to do the right thing by their customers, too? How can we be more proactive or clear about what the right path might be?
What might the unintended consequences of our work be? How might this software be used by bad actors, and what can we do to actively and intentionally prevent improper use?
We don’t think we’re alone in asking ourselves these questions, but we also don’t think it’s nearly as common as it should be. People we interview for our team ask us all the time if the Customer Code really drives what we do, or is it just a bunch of words on a poster somewhere? And because we do ask ourselves these questions, and make the hard choices the answers demand, we’re able to respond truthfully that yes, the Customer Code is a reality in our daily lives. It’s not just a poster. It’s our position. And our practice reflects that.
That’s what I mean by checking how our work smells. How it feels to others after we’ve left the room. Like everything else, it’s not an exact science. But we try to ask these questions as much as we can, and take personal responsibility for finding the answers we need.
And it’s worth pointing out that the more diverse our teams are, the better we get at asking the right questions and answering them, too.
All senses engaged
We don’t do any of it perfectly. But practice sure helps. As long as we keep getting out there, with all of our senses deeply engaged, listening and empathizing and looking and learning as much as we can, we’ll keep trying to build software that actually makes sense.
Sorry. Told you I liked puns.