S02E10 — OCT2020

Black Art of B2B Usability Testing

Hello world and welcome to the twenty-second edition of this thunder bandit newsletter.

After the slight detour with the last two issues, we are getting back on track with another designy topic. It’s not like “the track” is reserved for design topics only, but alas. There is no track the same way there is no spoon.

Ok, let’s do this.

✦

A few weeks back, a peer pinged me with a question: “Hey, you have some experience with B2B usability testing, right? Could you give me some tips on how to do this?”

I listened carefully to what they had to say, and the context was the following: they’ve been with this company for a while and they support multiple versions of the enterprise-level product. Now they feel they have the capabilities to kickoff their user testing practice. Without finger-pointing, the company just didn’t invest in this segment before, which is pretty much normal in this part of the world.

While I always favored the road less traveled, when talking with someone I barely know I like to give a disclaimer that my limited and biased experience is not necessarily going to align with what could be read in the hottest Medium posts. They laughed.

“I’ve been there. And as I see it, you have “two tracks” you got to work on in parallel. This is not going to sound very intuitive, but bear with me.”

Internal Track

The internal track includes your immediate environment — your team, your manager, other teams, other people you work with. This is where you start to build the structure. And the place you start with is not a flat surface. Instead, it is a hole that you first need to fill in. By this I mean, you have a lot of catching up to do, and by you, I don’t mean just you as a designer, but the whole group of relevant people in product development.

It’s almost symptomatic, but in these environments “bottom-up cultures”, as my friend Sasa likes to call it, are predominant. This means that tech aspects are often put above user needs. It sounds very rigid when I put it like this, but you get the point.

It’s not just enough to show up to the meeting and say “OK folks, from now on we are going to conduct usability tests”. Even if something like this happened, no one would be against the idea, but everyone would be like “Awesome!” and that would be it. The thing is not to leverage your work by doing it in isolation, quite the contrary, to practically show what usability testing can bring to day-to-day work. Try to demystify design techniques as much as possible.

User testing, similarly to “user experience”, is a very vague term. In order to get other people on board, you need to make it speak their language. Make a bet on how it will improve the product quality and cut the development cycle time. This will resonate with your stakeholders because in this case, it can be directly translated into financial aspects. Communicate your plan to your team, as well as to your manager. Managers love proactivity but not for the sake of proactivity. It’s important for them to know what you are up to, so they could follow and support your journey.

Start super ad hoc. If you don’t have domain experts (real users of the product) in the house, use your colleagues. Jugaad — make the best of what you have at your disposal. Never underestimate this.

Document your tests and propagate them in written form in design specs, tasks etc. This will give them some subtle visibility and signalize how useful those could actually be.

Bring team members along whenever you can. There’s nothing cuter than watching some of the stakeholders watching people not understanding their creation or using it “the wrong way”. 

All this will take some extra time on your side, some overtime you won’t get officially booked to. This is fine, because it is an investment. Over time, if executed well, this investment should end up with having usability tests as a standard procedure of your product development cycle.

This is why it is important to be punctual but also patient. Changing the system the “bottom-up” way is not easy. This kind of change requires time, energy and stubbornness.

External Track

If the internal track is viewed as bottom-up, the external one would be top-down. I’d say this track would require less energy but it may be more stressful. It will definitely put you outside of your comfort zone.

Before we get to the users, there is this mid-space which I call “crossing the river”. Each big org has its own river consisting of sales people, project managers, account managers, etc — the roles in charge of customer relations.

Here’s the thing, when you come to them with the idea of talking directly to the customers (users, call it however you want) and conducting some kind of experiments on them, their initial instinct is to push back. They don’t trust you enough as this is something they work hard to maintain. They understand the fragility of these relationships. This is all normal.

This requires educating your “externally facing” people on the benefits of user testing. Similarly to your tech team, but here you need to use a bit different lingo. Instead of emphasizing the development cycle, put the emphasis on customer satisfaction. Both are essentially true but your audience is a bit different here. Also you probably don’t spend the same amount of time with these people as you do with your team, so some time and space to digest and gain trust are necessary.

The way my team did this is making collabs with our account manager, planning these interviews and their goals together. Keep in mind that having clear goals is important, because all of this usually requires a lot of time and communication. 

You need to understand the layers of communication you need to go through. First — the people your people are talking to directly are not the people you want. In most cases they are colloquially known as “buyers”. People who are there to make sure that the solution the most money is going towards is the most optimal solution for their problem. Second — buyers are buying the software for your users, and now you depend on their best judgment to recruit the best users for your needs. It can be complicated, it may require a lot of pings and follow-ups.

And finally, we come to the act of usability testing. Just be well prepared to extract the maximum you can, but moreover, try to build new relationships. Try to make it so that in the future this flow can go even more smoothly. As for how to actually do this, there’s a plethora of content out there.

One more thing here that I found very valuable is that you should bring your externally facing person to these tests. It will look like they’re in control, they’ll see that you are not going to jeopardize their area of responsibilities, it will bring them closer to your struggles and user thinking as well, and they could learn a trick or two from you which they could use on their own.

Conclusion   

The idea behind this text is not to be a checklist of the things you should do in order to conduct successful B2B usability testing, but rather to map potential efforts that would create the right environment for a healthy process. 

To summarize in no particular order: 

• Be very diplomatic
• Bring your team along, make it a collective effort
• Understand different layers of your organization, the organization you are selling your software to and the relations between the layers
• Use your manager as a support channel. They can work for you on a higher organizational level 
• Always keep in mind who are you talking to and what they see as valuable
• Be exact, try to translate all the intangible finesse into tangible outputs
• Stay optimistic and persistent. Some things, especially low priority new processes can take a lot of time with trial and error