We’ve previously discussed the growth of tooling in recent years, and since then, User Interviews published its 2023 map with over 400 vendors included. There’s no shortage of tools out there, and while you can read all about the pros and cons of each, there’s an essential piece of the puzzle that’s often overlooked: procurement.
Too often in my career, I have found the perfect tool, only to get completely bogged down by the myriad of idiosyncratic challenges of software procurement, especially in corporate settings. It can take months to get through the process for a tool you need now, and in certain instances, you might still need to change vendors altogether despite your efforts. You can minimize the heartache by anticipating needs and considering the entire process when investigating and selecting vendors.
Before we get into the details, it might help to ensure everyone has a basic understanding of what the procurement process typically looks like. If you’ve never been in a leadership role or a ResearchOps role, this might be completely foreign to you. If you have, this might stir up some bad memories.
Each company will differ slightly on the order or on which steps are included, but here’s a simplified look at the process:
What features, functionality, and pricing/subscription model make the most sense for your organization’s current needs? What limitations are you up against? These may include financial, regulatory, legal, or practical.
While you don’t need to assign numerical values to each category, understanding which are the most important factors will make it easier to assess when you have multiple options that all seem good. This also helps maintain objectivity.
The aforementioned User Interviews Tools Map is a great place to start, but feel free to check in with peers at other organizations or poke around in different virtual communities (e.g. Slack or Reddit).
Don’t be afraid to think outside the box: there might be an analog in a different industry that turns out to be an ideal solution for you. Marketing Automation, Library Science, and Customer Success are all great places to consider.
This is both to get a better idea of pricing and packaging and to get set up with a trial account to fully test the functionality. We’ll discuss more later, but use this trial account to develop learning materials and update your internal documentation.
It’s unlikely that any one option will be the ideal solution, so it’s important to weigh the strengths and weaknesses of each and to know what happens if your top choice falls through.
After assessing the options, ranking them, and figuring out what service level/pricing package makes the most sense for your use case, have a conversation with the vendor about pricing. Most enterprise software deals involve some degree of a discount. This could be a first-time discount, a loyalty discount (for renewals), volume discounts, longevity discounts (e.g. signing longer contracts), etc.
Assuming this tool will have some sort of interaction with your existing tool stack and/or your product, someone from IT or Engineering will need to review any integration points and how to implement the tool.
Your organization has a security posture that it needs to maintain, and this extends to the vendors you select. The degree to which vendors need to uphold certain standards depends on the nature of the tool: what information they’re storing, what access they have to other systems, and how information is processed all come into play.
Depending on how your organization handles budget, this might be a quick sign-off or it might be a lengthy discussion with the Finance team. If you were able to put an item in your budget for this tool and the cost is at most what you budgeted for, this should be trivial. If you have to move things around and find additional budget, this can be incredibly cumbersome.
Every software vendor comes with a set of terms and conditions you need to agree to in order to use their tool. The Legal team will review this and may be involved in negotiating certain terms into or out of the contract you sign.
Depending on your position in the company, you may be the one physically (digitally) signing the contract. Make sure this is clear when you start the procurement process so no time is lost getting approvals and signatures. The same goes for sending payments: make sure your Finance team is aware of who needs to be paid and you’re aware of when those payments will be processed and sent.
Part of the negotiation process will be deciding on an appropriate start date. Once the ink is dry and your core team has access, you can start onboarding into the tool. Most vendors will provide some sort of onboarding/kick-off package which usually involves some degree of training material and/or sessions for the team as part of your contract.
Software tools are only as useful as they are usable. If nobody knows how to use what you just paid for, what’s the point?
Don’t give everyone access on day one. You can use training as a way to control the flow of new users to minimize confusion or overwhelm.
Software contracts are usually annual, and depending on the vendor, can be as short as one year and as long as, well, infinity I guess? 😅
Yes, this is the simplified view. Let’s take a deeper look at some of the things that might loom larger for Research tools.
While there are certainly similarities across the procurement process for all disciplines, there are also specifics. Engineers may care more about extensibility to avoid vendor lock-in, whereas Marketers might care more about interoperability to ensure it plays well with their current systems. Research is no different: there are specific considerations you need to think through when picking a vendor.
Nothing kills a deal faster than a mismatch in operating models. If you’re running a heavily democratized research function and the tool you want to use has a per-person-per-month model, you’re either going to (a) pay a lot of money for a tool that isn’t used frequently by any one person, or (b) have to constantly juggle seats, adding overhead and potentially confusing your teammates. On the flip side, if there’s a strictly per-use cost and you have many people using the tool without clear guidelines or reporting, you could unknowingly rack up a huge bill.
The nature of the work we do as Researchers involves a lot of highly sensitive personal data, whether that be usage data from in-product analytics, raw survey data, or audio and video recordings from sessions. Understanding your organization’s data governance and privacy requirements will help you screen candidates in and out before getting the rest of your company involved. Familiarize yourself with things like GDPR, HIPAA, PCI, SOC, and ISO standards, at least enough to look for a company’s Privacy or Security page and recognize the relevant logos.
Despite being our top choice and getting an excellent discount, Auth0 had to give up on TryMyUI because their security posture was not strong enough to pass Compliance review.
This may not seem relevant if you’re privately held and early stage, but the closer you get to going public, the more data privacy weighs into your operations.
While it may not be as large of a concern for Research as it is for other disciplines, interoperability is still a factor in selecting a vendor. You’ll likely need to pass data back and forth between tools one way or another, so minimizing the amount of manual copy/paste or download/upload your team has to do is essential for both efficiency and data governance: it’s impossible to mistakenly leave files on a local machine if they never get there in the first place. When you talk to vendors, present them with your full stack and ask questions about how capable they are at interfacing with your existing tools. If they can’t do it currently, oftentimes companies are willing to build extensibility in for popular platforms (think Salesforce, Snowflake, HubSpot, etc.)
So much of what goes into Procurement stretches beyond the mechanics of getting through the process. A strong ReOps practice will help get through those mechanics smoothly, but there’s more that can be done to ensure your team is ready for your new tool on day one.
Inertia is your worst enemy here, so be clear about what the benefits are to having a tool for this, what’s going to change, and what’s going to stay the same. This includes answering questions and making decisions about processes, use cases, training/onboarding, and access.
If anything, you want to build hype and get people excited about the tool before it even arrives, as this can provide additional urgency to the gauntlet of reviews it’ll need to get through.
You can do this by recording videos from your demo account, or holding training sessions and office hours to get your team familiar with the tool and understand how it can be used before go-live.
UX Researcher Lawton Pybus takes a deeper look at change management and technology adoption in his newsletter, The 1/4" Hole.
Generating excitement is a bit of a double-edged sword — when you announce the tool is available, you open the floodgates to people asking for access. Ensure that permissions are set appropriately to minimize confusion and chaos within the tool.
It’s just as important, though, to be clear about what the appropriate use cases are. This will help your team understand who actually needs access to the tool and what they can and should be using it for. This is especially true if your contract isn’t an unlimited one (either in seats or usage): you don’t want people blowing through your quotas or racking up enormous bills because they aren’t clear what the intended use is.
By creating clearly defined guidelines for surveying, recruitment, and rewards at Auth0, we were able to give everyone access to QuestionPro, Respondent, and Tremendous, lessening the burden on our ReOps team.
Prepare answers to expected questions, like who gets to use it, how often, and for what, as well as what to do if they need increased access or help. As much as possible, play nice with the existing processes at your organization around provisioning and access requests, and establish clear lines for support (internally or externally).
Use your trial period to update all of your documentation ahead of the tool switch. You can write all of the docs, publish them, and begin to socialize them both to get feedback and to help people familiarize themselves before go-live. If you’re onboarding a tool for the first time and don’t actually have a process for, say, participant recruitment, this is an excellent opportunity to develop that process and document it.
When onboarding a new tool, it's easy to get excited about all of the cool features it provides and how much it’ll benefit your team.
Even before the tool is there, people tend to assess vendors in the idealized state: free of any organizational constraints or requirements. Procurement is much more than that and can take months from start to finish.
Once you’ve conducted a thorough assessment and started the process, you can minimize the trough of sorrow between paying for a tool and seeing value from it by shifting your focus to the operations work required to make go-live a success.
Brad (they/them) is a UX Leader, User Researcher, Coach, and Dancer who's been helping companies from early-stage startup to Fortune 500 develop engaging, fulfilling experiences and build top-tier Research & Design practices since 2009. They have helped launch dozens of products, touched hundreds of millions of users, managed budgets ranging from $0 to $10M+, and coached hundreds of Researchers. Born in Buffalo and currently based in Brooklyn, NY, Brad dances with the Sokolow Theatre Dance Ensemble and Kanopy Dance Company, co-organizes the NYC User Research meetup, and served on the Board of ResearchOps from 2018-2021.
