Design Research Hack: When you want your design to be user-centered design and you don’t have access to users!

Hope Turner
5 min readFeb 3, 2021

For the last few years, I’ve been a user experience researcher on an enterprise software platform. Because this platform is very powerful, flexible and complex — learning how to use it can require some effort. Even after years of exposure to the various capabilities and their use cases, I find I still learn something new. I expect that won’t change. I won’t pretend that I know all the ‘ins and outs’ of all the features or all of their supporting use cases. It can take years of on-hands experience to gain that level of knowledge!

Successful design requires teamwork and collaboration!

The problem at hand…

As a design researcher tasked with working across multiple, complicated capabilities that feed into the platform, I am very conscious that I am not my user. I need to institute a process of ongoing user testing research in my process to have any chance of success. I need to interview users, share designs with them, and get their feedback.

Finding knowledgeable users that are capable of providing insights to the design team, is often not an easy nor viable method. And because of the varieties of use cases and roles of people using this software, it can be very challenging to find qualified and available people out in the wild, to engage in user testing. Identifying and ramping up new users is even more time consuming and often is not the most effective use of resources.

Online testing tools, that provide speedy and plentiful results, can fail us. It’s frequently near impossible to get meaningful insights or to trust that the participants are a good realistic representation of one of our user types. (Don’t get me wrong, online tools do have their time and place).

And of course, there is always time. We all want fabulous, powerful insights, but often don’t have the time required to do the deep dives we would like to do to get there. In our agile world, we try to align our efforts into sprints and timebox our research in ways that challenge us. We want to stay a few steps ahead of the designers — and even more so, the developers.

What is a design researcher to do?

If you are indeed working at a large software company, you have a wealth of knowledge available to you — if you just know where to look! My breakthrough came through one day when I was watching a YouTube video produced by someone internally in our technical sales team. The narrator of the video was friendly, engaging, and knowledgeable — so I reached out to him to have a quick Q&A session. He ended up to be a great resource and collaborator — engaging and educating the design team. He provided relevant product history and summed up his interactions with some customers. Years later, we still regularly meet to discuss customer feedback or requests, as well as research sessions to review new designs. He has also pointed me to other internal people to help out with research efforts — and my network of knowledgeable participants has grown! (If you are lucky enough to have a lab services team that help implement and extend your product, hit them up too).

While technical sales people are not our users, they can be an invaluable source of useful and relevant information. They interface regularly with customers and are incentivized to make the platform attractive. Building close relationships with customers, they develop strong empathy and understanding of users. They are able to provide a unique perspective where they can aggregate the experience of many customers to communicate to the design team.

Most technical sales people that I’ve invited to research sessions, have not only provided quick and valuable feedback, but were excited to collaborate with the design team. I highly recommend to designers and researchers, that have internal sales in their companies, to build relationships and collaborate on a regular basis. The one caveat that I offer here is to understand the difference between a feature request and a customer pain point. Sales people can sometimes be interested in focusing on features that may not serve end users or solve for their pain points. It helps to understand the difference.

Once I was able to identify and connect with willing participants internally, I moved my focus outwards. IBM has a great network of business partners and that’s where I found my next set of collaborators. Business partners may not provide the brutally honest feedback that you will receive from tech sales, but remember their motivation is a little different. We have invited a few of our partners to collaborate with us in our Enterprise Design Thinking workshops and the value of our collaboration cannot be overstated. They provide a different perspective that helps us to get a well-rounded view of our product and customers.

In summary…

When time and resources are tight, look around your company and see who might be able to provide product or customer insights. In large companies, you might have to get creative with finding the right people that can help. Look to see what has been publicly published on YouTube or discussion boards to find your internal subject matter experts (SMEs). Reach out to them. Even when they are the wrong person, they will often point you to other people that are more relevant.

Connect with business partners. Investigate and see who already collaborates with your project managers or executives. It helps to have a formal introduction from someone at your company that already has an existing relationship with your partner, but if not, don’t be afraid to reach out and introduce yourself to explain that you would like to collaborate with them on design research.

And when you do identify your research collaborators, you can work with them to do the first pass of feedback on designs before sharing with your customers. These internal collaborators will help you identify the low-hanging fruit so that you can refine the designs and get more meaningful feedback from customers and users later. Meet with these folks regularly. Show them how you’ve improved the designs based on their feedback. Use this method of internal review to iterate and create stronger designs before sharing out to customers!

--

--