All products — yours included — are only as good as users believe them to be. Which means any EdTech product’s success hinges on its ability to anticipate and solve users’ most pressing problems, both in and out of the classroom. And it’s safe to say that without UX research, your product’s design is little more than a stab in the dark.
Why is it, then, that so many EdTech companies struggle to appropriately leverage UX research in their product development process?
In some cases, it boils down to underestimating the value of UX research. And in others, it’s a lack of finesse in strategically applying the right methods at the right time. Either way, if you’ve “done” UX research and failed to move your product forward successfully, the details of your research regimen may be the reason why.
“Doing research” isn’t just about talking with a handful of users about an idea before it is designed, and it also isn’t just about usability testing a prototype before designs are sent to engineering.
In order to fill in unknown gaps and drive your product forward, you need to skillfully integrate UX research throughout the process. Fail to approach research appropriately, and you risk making costly mistakes — either by wasting precious design and research time or developing something that doesn’t engage your users.
So how can you ensure your UX research efforts are perfectly tailored to drive value and make your EdTech product smarter?
The Goldilocks Conundrum: How Much UX Research is Just Right?
Most EdTech companies incorporate at least a little UX research in their product development process. But what that actually looks like in practice varies widely from product to product and team to team. That’s no surprise. After all, there are countless ways to insert research into the process — and varying degrees of commitment to the value of UX research.
When it comes to approach, many EdTech companies find themselves on opposite ends of a spectrum. The organizations on one side view UX activities as a compulsory box to be checked. They do just enough to say they’ve “done their research,” but not enough to uncover new or truly meaningful findings.
In this scenario, research is usually tacked on at the beginning or end of the project, almost as a formality. For example, an EdTech company of this mindset might decide not to “waste time” on discovery research at the start of a new project. They assume they already know their users well enough to accurately identify their needs, so what’s the point of holding up the process? The team builds their product based on educated assumptions, then circles back and conducts a single round of user testing on the finished design.
The problem? At this point in the process, testing can tell you whether or not your design is successful, but it won’t tell you whether or not you’re solving for the right problem in the first place.
On the opposite end of the spectrum are EdTech teams that embrace UX research but don’t know how to dial it up or down to suit their shifting needs. That is, they follow the same rigid process for each individual project (and checkpoints within projects) regardless of the circumstances. Organizations that fall into this camp may ultimately get frustrated with how costly and time-consuming research is — never realizing it doesn’t really have to be that way.
Like Goldilocks trying to find the perfect chair to sit in, these opposing approaches generally don’t fit. They’re either too big or too little, too hard or too soft, but never “just right.” That’s because these “end-of-the-spectrum” approaches fail to account for:
- Your existing knowledge base. Your team, including your designers and other internal stakeholders, has a wealth of knowledge. Your research plan should flow from and reinforce your existing knowledge base. That doesn’t mean rolling with your assumptions; but it does mean prioritizing research in the areas where your current understanding is least developed.
- The need to be agile and iterative. One-and-done UX research programs don’t mesh with the agility and flexibility most product teams desire in the development process. By the same token, overly rigid research prescriptions lock teams into a certain way of doing things even when the situation calls for a pivot. A robust, flexible UX research program should adapt based on your growing foundation of knowledge — and allow your product to do the same.
- The need to reduce biases — yours and your users’. If you treat UX research as a cursory requirement, you’re much less likely to check your biases at the door. At the same time, limited research may prevent you from eliminating not just your own biases but those of your users, too. For example, during initial tests users may not be as invested in your product as they will come to be post-launch.
- The time and effort required to gain a holistic understanding of users. Cursory user testing often fails to take into account the full instructional ecosystem in which users actually operate. It’s one thing to interact with a prototype in a laboratory setting and quite another to use a product in the hustle-bustle of the average school day. Deep discovery-phase research and repeated rounds of testing can unlock a more holistic understanding of your users’ context and corresponding needs.
Bottom line? UX research is neither a formality nor a formula. Rather, it’s a strategy. One that should evolve along with your product roadmap.
The 4 Most Common UX Research Methods
UX researchers rely on a diverse toolbox of qualitative and quantitative methods that can be used at various points in EdTech product development as the need arises. The most common UX research methods include:
- Discovery interviews. These one-on-one sessions, which can be interview- or observation-based, are used to gather information in the discovery phase of a new project. The goal may be to uncover more about a particular problem or simply to gain a deeper understanding of your users and the context in which your product is used.
- Digital focus groups. Digital focus groups are another way to quickly and economically uncover problems, gather feedback, and prioritize goals in the early stages of a project.
- Surveys. Surveys are a great way to validate key findings coming out of discovery-phase research activities. They are particularly useful in assessing the statistical significance of a particular issue, which can give your team a better sense of the level of risk involved. UX research surveys commonly include 50-100 respondents, but the actual number depends on the level of confidence you desire in your data. Researchers also use short single-question surveys as a benchmarking tool, such as tracking user satisfaction with the Single Ease of Use Question (SEQ) over time.
- Validation interviews and usability testing. Validation research usually comes into play once product teams have a working design or prototype and want to verify its usability. However, validation research can also be used to validate a concept — one that hasn’t yet been fleshed out in designs. This form of research is also useful in comparing the relative merits of two or more design options. A good researcher will know effective methods (and metrics) to evaluate solutions side by side. As part of this exercise, researchers typically interview five users from each user segment.
Think of this collection of high-level UX research methods as a set of musical instruments. The music you make with them will depend on which instruments you choose to play, when, and how (not to mention your skill level in playing them). Used haphazardly, it’s possible to produce a cacophony of unpleasant — and ultimately meaningless — sounds. But when played in concert, these methods can create a symphony of insights that propel your product to the next level.
A seasoned UX team can not only compose an original research “score” for your EdTech product — but also provide the expert musicians needed to play each instrument masterfully.
Key Questions to Inform Your UX Research Strategy
There’s no such thing as a one-size-fits-all formula for UX research. The cadence of research sessions and the types of research you employ should be molded to fit your particular needs and goals. Asking the following questions will help your team get a more detailed picture of your current project’s research needs.
1. Assess your project stage and timeline.
- What stage of the design process are you in?
- What is your timeline for getting designs development-ready?
- Takeaways: Your research plan will look different depending on whether you are at the very beginning of the problem-discovery stage or already possess enough information to start identifying solutions. Note that you might have some information that will allow you to combine phases by using low-fidelity prototypes as part of your upfront research.
2. Gather background information.
- What are the goals of your project? Are you hoping to increase engagement, improve user satisfaction scores, expand into a new market, or something else?
- What is your project’s scope? For example, you might be building a new product from scratch, adding a marquee feature, or simply refining an existing workflow.
- Who are your users? Are your current users the same as the ones you want to attract in the future, or are there other user groups you should learn about?
- What specific problem(s) are you trying to solve?
- How do you know a problem exists?
- What, if any, solutions have you already tried?
- Do you have any existing data relating to this issue? Where did it come from? And how confident are you in that data?
- Takeaways: Once you’ve gathered existing background details, identify the areas where you have significant gaps in your confidence. Make sure to prioritize those areas in your research plan.
3. Establish benchmarks.
- How will you measure success as you conduct your research? Your benchmarks may differ depending on whether you are viewing it through the lens of learning science, user experience, or your business requirements (or some combination of the three).
- Takeaways: Your research benchmarks can include soft metrics (such as the quality of feedback in interviews), but you should also set some hard metrics — such as time on task, System Usability Scale (SUS) score, , affect grids, and the like — to validate your results against. Once you’ve set your benchmarks, you can evaluate your evolving prototypes in subsequent rounds of research against the same set of success criteria to get a through line of useful feedback.
4. Determine your process for assessing and applying research findings.
- Within your organization, which stakeholders will have a say in how you interpret and apply your research findings?
- What factors might convince them of one outcome or another?
- What will give them the confidence to move forward with a particular solution?
- Takeaways: To allow for more data-driven decisions, try to tangibly define what success looks like. To that end, think about what your threshold or tolerance should be for deciding on a winner. For example, if one solution is extremely easy to build and another is extremely difficult, how much better must the difficult solution perform to “beat out” the easy solution? As you consider your approach, don’t forget to take opportunity cost into consideration.
5. Determine the level of risk involved.
- What is at stake if you fail to find the right solution or resolve this problem?
- What is the risk to your business? How critical is this particular feature or product to your business model?
- What is the risk to your users? To what extent will this particular feature, functionality, or user flow impact their overall user experience? For instance, the design and placement of a “submit” button have a much smaller impact than an onboarding interface that sets mental models for the rest of the experience.
- What is the engineering risk? How much time and energy will it take to build the right solution?
- Takeaways: The more risk involved in your project, the more research you should employ before charting your final course. On the other hand, for relatively low-risk issues, you can probably get away with less up-front research. In some situations, you might even consider jumping straight to a beta feature release you can monitor and refine post-launch.
Putting It All Together: Crafting a Customized UX Research Plan for Your EdTech Product
When it comes to your UX research program, you need to avoid “one-and-done” efforts as well as cookie-cutter solutions. The ideal UX research regimen includes a robust mixture of different methods conducted at various points in the development process as well as follow-up monitoring once a feature or a product is live. There’s no such thing as a “standard” UX research playbook. Rather, you need a customized approach to create the most efficient and impactful UX research program for your EdTech product.
At Openfield, we specialize in helping EdTech companies like yours identify precisely what you need in terms of research. We can quickly get up to speed on your product and advise you exactly how and when research ought to be injected into your current project or product roadmap — then execute it for you. Ready to start the music? We’d love to hear from you.
