Why UX Research Repositories Fail
I will assume you are reading this post because you are either planning to implement a research repository in your company or you’re in the middle of your implementation. Either way, this post is for you.
In the last couple of years, we’ve seen a variety of success stories from companies implementing their research repositories, most people are familiar with Mailchimp’s case study ( Connected UX) and WeWork ( Polaris). Most recently we heard from Microsoft (HITS) and Uber ( Kaleidoscope).
These case studies come from large organizations with established UX teams and enviable resources, but what about the small and medium-size companies out there trying to move forward?
Over the last four years working at EnjoyHQ, I’ve seen many failures and a fair amount of success regarding teams building better processes around research activities, especially when it comes to designing better processes around storing and sharing research insights across the organizations.
Most teams we work with not only look for better ways to share research insights with stakeholders but are also interested in increasing their research work’s speed and quality, while ultimately influencing product decisions.
All the above are great goals for any UX team, but they have little to do with implementing a research repository. In this post, we’ll explore why this is the case and what I’ve identified so far as the most common reasons why research repositories fail.
1.Setting up unrealistic expectations
If you are dissatisfied with the way your team does research or in some cases does not do research at all, I have bad news; a tool is not going to fix it.
Making research data more accessible to team members uninterested in research will only lead to frustration. If stakeholders are disconnected from the value that research offers to the business, introducing a tool will only create overhead and more friction.
This is the equivalent of buying a new license for Asana or Basecamp and expecting your team to immediately start delivering projects on time. While great software certainly helps, never bet the entire success of a project or process on a tool.
Instead, you should find out why people are not excited about research or don’t find it helpful. This usually means doing internal research, speaking to many stakeholders and focusing on building good processes in the first place before you implement a new tool.
Perhaps the product team does not understand the value of research or what good research looks like. Maybe your company’s development process was never designed to be influenced by research. There are plenty of reasons why businesses do not invest in or value user research. Determine what those reasons are in your business and tackle those first.
Trying to implement a research repository without the product organization’s support and commitment is the equivalent of saying: “If You Build It, They Will Come.” — They will NOT come.
2. Lack of leadership
Before trying to design a new process around research activities and how people will use insights across the business, ask yourself a very important question:
Am I the right person to lead this process, or do I need somebody else to lead it?
This question is not about whether you believe the process needs to be improved but understanding if you have the drive, authority, and influence to bring people together and coordinate efforts on top of your existing work.
These types of projects are rarely planned in advance by top executives. Usually, these projects get started by researchers tired of producing research nobody uses, jumping between a bunch of tools and documents to answer very basic questions, or anxious that most of their time goes into logistics and not actual research.
If you believe a research repository will solve these issues, you must also convince management that the project implementation requires full-time attention for a period of time and cannot be accomplished as a side project. This will make a difference in your success rate, as projects dragging too long tend to fail due to lack of momentum.
Find internal support and join forces with customer champions across the business. The time spent doing this will bring a variety of benefits beyond the successful implementation of your research repository.
However, strategically plan the process, involving too many people to make decisions about the goal, structure, and implementation of a research repository will lead to a bloated scope. Different teams use research insights in diverse ways. If you are leading the process, make sure everybody is clear about the scope and what success looks like, so other teams can contribute to an initial vision and not start from scratch.
Be clear about what you need from other teams or stakeholders, making requirements as specific as possible. Implementing a research repository by consensus between multiple departments is possible-but very painful.
3. Lack of team ownership
Let’s assume for a moment your organization deeply cares about being close to its customers and having efficient processes around user research. Perhaps they are investing in building a strong UX function, and the product organization is excited about making research more accessible to the business. With a solid foundation like this, you are more likely to succeed.
Now let’s imagine you worked diligently and finally implemented a research repository.
You are excited because you managed to build a more effective way of sharing knowledge about customers, and you did it in collaboration with other teams across the business.
But what happens if …
Or perhaps you decide to move to another role or a different company?
Will the repository continue to be useful? Will somebody else makes sure it continues to help the business? Who will take care of the repository?
I know of many companies that have implemented Salesforce several times. The person who implemented it first leaves, and then the next person in charge doesn’t like the implementation, so they do it again from scratch. The same process happens over and over again…I’ve seen it happen with email marketing, CMS, Wikis and project management tools, etc.
It is understandable that implementations need to be revised as the business changes but it shouldn’t be a process driven by whether or not the person in charge left the company.
A research repository needs maintenance and optimization, whether you like it or not. Ongoing success requires an active collaboration of team members and maintenance ownership.
The same is true for most tools. For instance, if you’re using an analytics tool like Amplitude or Mixpanel, you know the only way to get value is to continue tracking properly. If you do not update your properties and events as your product evolves, the reports will be useless.
If you decide to leave your company tomorrow, you should feel confident your work will be continued by other team members as an integral part of how the business operates. In other words, the repository should become an ingrained process and not a pet project somebody did once in the past.
4. Fear of iteration
It is understandable that given how difficult it is -sometimes- to convince stakeholders of investing in this type of project, you may feel you need to get it right from the start.
We all want to succeed but success is not a linear process so when it comes to implementing your first research repository, you will normally get a few things wrong and that’s ok.
For example, many teams spend an incredible amount of time trying to create the perfect taxonomy for their repository. Although adequate time and involving the right people are necessary, you should know that no matter how hard you plan the taxonomy, you will still change it over time. The more you understand how people consume the repository’s data, the more you can optimize it. Striking the right balance is not easy, but you should keep it as lean as possible.
Onboarding team members
Another challenge I see teams face is onboarding members to the new process or tool. The idea of democratizing insights is very appealing but should be a controlled process.
If you open data to the entire organization, but the business doesn’t know how to use the data or contribute to the repository, you will likely create a bit of chaos.
My general advice here is to slowly onboard teams based on the contribution level they will provide to the repository. For example, initially, the product team would be the right group to get started, since team members tend to do research that directly impacts product decisions. Later, you can onboard teams that perform less frequent research but can benefit from accessing previous product team research. After those initial groups are onboarded, you can consider stakeholders and teams who do not perform research but make decisions based on customer insights.
Depending on your business, each circle will have different roles. In some businesses, product managers act as primary researchers, but other businesses have large specialized research teams. Your context is crucial here.
Privacy and data access
I’ve also met teams that are extremely concerned about opening data access to other team members, mostly from a research participant privacy standpoint.
The typical situation involves sharing research that contains participant information with product managers and then finding out the product manager contacted the participant without telling the researcher.
I completely understand the concern; however, if a product manager wants to talk to a customer, they will do so whether you have the biggest security wall around your research or not. This is not about the tool but the process-the trust and communication between team members.
Although onboarding team members and privacy issues aren’t directly tied to iteration, the lesson is that as you implement your repository, you will identify new protocols that need to be implemented, and you don’t have to know or establish them all from the start.
5. Picking the wrong tool
Picking the right tool to support or enhance your internal process is always challenging and requires thorough research. If you’ve outgrown your initial repository built on spreadsheets, Airtable, Wikis, or other document management systems, you must clearly identify your new requirements.
The most successful implementations come from teams that have clearly identified what they need to support their research process. They normally come to us with a specific list of features and security checklists we must be able to support.
Unfortunately, I’ve seen the opposite scenario too. I’ve met teams that spent significant time implementing the wrong tool to later realize the tool was not GDPR compliant or didn’t meet internal security requirements of their procurement team. Sometimes procurement processes can last several months, and you don’t want to trigger that process before you are confident the new tool is a good fit.
When selecting a new tool, you should consider how it will scale and if it covers research workflow basics. Does it work with the right data formats? How robust is the user permissions management? Can I bring data from all the sources I want to tap into? Can I anonymize data? Are these deep integrations or does it involve another third-party tool like Zapier? (which may need its own procurement process). Do they offer customer support in my time zone? The list of potential questions is long.
Here’s a template that may save you time when comparing vendors. Please make a copy and feel free to customize it based on your unique requirements, this is by no means a full list but hopefully it will provide a head start to your research. Research Repository Requirements Comparison
Final thoughts
There’s never been a more exciting time for design and research teams. UX as a discipline is rapidly flourishing, with a new breed of incredible leaders transforming their organizations into more customer-driven ones.
Implementing a research repository can be a transformational endeavor if you are willing to experiment, rally people around your vision, and persevere during the process. It will be, for sure, a learning opportunity that will give you insights on how your business works and what is stopping it from becoming a learning organization.
I wish you all the success in your journey to help your business get closer to customers.
“Nothing worth having comes easy.” ― Theodore Roosevelt
Sofia
PS. If you are at the beginning of your implementation this may be helpful. The Ultimate Research Repository Checklist.
Originally published at https://blog.getenjoyhq.com on January 2, 2020.
