I spent the first 7 years of my career both testing software and completing usability research on a variety of healthcare technology topics. Now, working full-time as a User Experience Researcher at Key Lime Interactive, I’ve had an opportunity to reflect on some of the skills I picked up while testing software and ways in which that knowledge has helped me succeed in the world of usability.
Prior to my work as a software tester, I had little to no experience with coding or development. Much of what I learned came with practice, trial and error, and repetition. After nearly a year in my new role as a UXR, I’ve started to piece together the puzzle of how my time as a software tester has allowed me to integrate more seamlessly with project teams, implement new methods, and research a variety of topics outside of healthcare. Three core pieces of that puzzle include: (1) being able to talk like a developer, (2) following my intuition, and (3) knowing how to sell a fix to a product team.
#1. Talking Like a Developer
Being able to talk like a developer doesn’t necessarily require the knowledge to read or write code. Instead, it means understanding the basics of the development life cycle. There are a variety of ways the development cycle can be broken down, but it’s usually described using 5 to 7 stages. In a nutshell, it accounts for the conception of an idea, requirements gathering, design, development, testing, deployment, and maintenance. Understanding the stage of the lifecycle that a research project is addressing can help when guiding clients to the best methods and better understand the requirements of the study.
Let’s compare two examples: a project in the early stages of requirements gathering and one that has been released and is in the maintenance phase. When researching a project that is still gathering requirements, I might want a larger participant base if the target audience is still variable. This larger sample might give me an opportunity to better understand the needs and expectations of many backgrounds and best guide clients in establishing and meeting design goals. Knowing that the themes of research might be broader, the methods I’d suggest might be more open-ended, such as moderated and unmoderated interviews. In contrast, a project that has already been released to the public likely has a specific target audience which usually consists of an existing user base or one that they’d like to reach better. These types of projects may also have more direct questions which could be answered via surveys or diary studies. When considering requirements, research on newer products, in my experience, has allowed for longer timelines and potential for iteration, whereas existing products in the maintenance phase might require quicker fixes and, therefore, more rapid research.
Although every research opportunity may vary, understanding the development process has helped me more appropriately establish timelines with clients and help them scope the best approach to the research at hand. This helps me build trust and strengthen communication as we move forward from the kick-off to study creation. Understanding the development process is also an essential building block to listening to my gut as I establish research questions and begin drafting my study.
#2. Following Your Intuition
As a manual software tester, a key part of my job was creating and executing test plans, which accounted for the many ways a given user might interact with, and therefore potentially break, the product I was testing. This required considering not only a variety of users but also possible settings and scenarios under which they might be using the product. In my time as a researcher, I began to find that this was often similar to the way I might approach research questions and design any given study.
Over time, as a software tester, I noticed patterns in the ways users I interviewed might be affected by changes to software or areas where they might struggle, and I was able to incorporate them into my test plans. Eventually, I was able to trust my gut when determining which areas might be most likely to break, which made me more effective in a fast-paced environment. In turn, as a usability researcher, I’ve noticed patterns in how participants might respond to different parts of a product and which methods and questions tend to garner more feedback. Just as I learned over time to trust my instincts as a software tester, I’ve also found myself better equipped to trust those same feelings when it comes to kicking off or drafting a study. During kick-offs, I feel comfortable asking more questions about the goals of the research and suggesting additional areas to consider. When drafting my studies, I use that same intuition to incorporate questions that are most likely to meet the goals of the study while providing the client with in-depth insights.
Intuition isn’t foolproof, so peer review is still important in my process. It both helps avoid unintentional biasing and continues to grow my insights for the future. Knowing how and when to trust my instincts is a never-ending process of growth and refinement that leads to better outcomes and more effective studies, which sets me up for success as I approach sharing my findings with the client.
#3. Selling a Fix
Once your study is run, you’re left with findings to summarize and recommendations to share. When testing software, much of the same applies. Not only do you need to write up the problems you’ve found in a succinct but descriptive way, you often need to know how to prioritize, share, and defend the importance of both the problem you’ve found and the recommendations you offer. I found there were two important things to consider when making my suggestions for software fixes that also apply to sharing research findings. I need to consider both the time and impact of any given recommendation and the stakeholder to whom I present.
The issues identified in software can vary in time needed to resolve and impact. For example, an issue that may take only a few minutes to fix may be likely to go unnoticed, such as a misspelling on an infrequently visited page. Or, the issue may be impactful, such as a page crashing, that will take hours to fix. It might also fall somewhere in the middle, like a button that users often overlook, which may have a moderate impact and require redesigning and, therefore, a longer amount of time to fix. The same often occurs when there are usability issues identified.
As a researcher, being cognizant of how much time it may take to fix a problem for the average developer or designer can help in prioritizing what recommendations to approach first, in addition to following my instincts based on past experience. Sometimes there are many tiny problems at play that may overshadow larger usability issues, so I may suggest a client attack these first to help their users complete their core workflows. Other times, there may be one or two large things causing users to leave their workflow. In these cases, it’s often imperative to dedicate the bulk of available development time to fixing this problem and putting smaller fixes on the back burner for the future.
When I approach research clients or software developers, I also want to take into consideration who I am talking to. With a developer, I need to understand that finding issues and bugs in something they created may be a sensitive subject. I also need to understand how long they might need to fix the problem since this time estimate would directly affect their timelines. I might be more inclined to share direct details with them about what caused the problem, all the ways it could happen, and even ways they might fix it based on other pieces of development in the area. With customer support, I’d be more likely to focus on workarounds and the time they might take, as well as the impact on the user's workflow, rather than the ins and outs of the development itself.
Depending on the clients who may be at a research readout, I may also want to tailor my recommendations to their direct interests. Are they directly involved in the day-to-day operations of the area of research? If so, I might want to share more details about the ways users wanted to see their workflow changed and which recommendations might be easiest to approach next as opposed to those that might require more time or research. If they’re higher up and involved in more strategic work, I may want to focus on the high-level summary of what was found and which next steps might be most impactful overall.
My time as a software tester provided me with many insights and abilities. Learning to speak the language of my client, following my intuition, and selling my recommendations accordingly are some of the most impactful skills I gained. These skills are easily transferable to my current work as a UXR. Establishing a strong early rapport allows more room to make suggestions when developing study objectives and methodology. Strong client rapport and trusting my intuition help me determine the best way to share the data and recommendations in a way that is most effective for each unique group of stakeholders. These techniques have had a positive and lasting impact on my approach to usability. It’s worth considering: how might you incorporate them into your own research?
At Key Lime Interactive, we thrive on the diverse backgrounds and experiences of our researchers. Contact us to learn how we can add a unique perspective to your next research project.
Comments
Add Comment