When users don’t choose their software — they’re assigned it by an employer, institution, or administrator — good UX isn’t optional. It’s the only path to genuine adoption. Resistance is built in, trust has to be earned, and assuming users will simply comply is a strategy that fails quietly and expensively.
In This Article:
- Why Does Mandatory Software So Often Let Down the People Using It?
- What Do Forced-Adoption Software Environments Have in Common?
- How Does Designing for Assigned Users Change Everything About UX?
- Five Lessons That Transfer Beyond Education
- How Do You Apply These Lessons to Your Product Environment?
- Frequently Asked Questions
- Key Takeaways
Why Does Mandatory Software So Often Let Down the People Using It?
Most UX firms learned their craft on products people *chose* to use. We learned ours on products people *have* to use.
That difference shapes everything. Your users didn’t choose your product. That doesn’t mean they can’t trust it, but earning that trust requires a fundamentally different approach to UXthat most firms have never had to develop.
People resist when choice is taken away from them. That resistance becomes the baseline condition of forced adoption environments, and it shapes every interaction a user has with your product. When a student has to use your LMS, when a nurse has to log into your documentation system, when a store employee has to check an app between customer interactions, the dynamic is fundamentally different from consumer software. You can’t earn adoption through delight alone. You have to earn trust in an environment where skepticism is already present.
That’s the problem we’ve been solving for nearly two decades. And the methodology we developed to solve it in educational technology transfers directly to any environment where users don’t choose their software. They’re simply handed it and told to make it work. The organizations that get this right understand that the absence of choice doesn’t eliminate the need to earn trust. It makes it more urgent.
What Do Forced-Adoption Software Environments Have in Common?
Picture the product environment your team is navigating. You’re managing software that three different stakeholders helped define: an executive who approved the budget, a procurement team that evaluated the RFP, and an IT department that had to integrate it with four other systems. None of them use the product daily. The people who do never had a seat at the table.
That’s not a failure of process. It’s the structure of every mandated enterprise product ever built. And it creates a recognizable set of conditions that compound each other:
Compliance drives architecture. Privacy requirements, data security mandates, and industry regulations shape what the product can and can’t do, often before a single user need is considered. UX decisions that ignore these constraints don’t survive contact with legal or IT.
Years of debt have accumulated. These products grew through acquisition, compliance mandates, or years of patched-together updates. The interface reflects how the product was built, not how users think about their work. Multiple user tiers, including administrators, managers, and end users, each have competing goals. Designing for one typically creates friction for another.
Integration complexity is constant. The product has to work alongside legacy systems, hardware, and analog processes users already trust. A product that doesn’t fit that ecosystem, however well designed in isolation, gets worked around.
This is a specific and demanding design problem. It requires a methodology built for constrained environments, users who didn’t choose the product, and complex systems. It’s a problem one industry has been solving under real pressure, with real stakes, for twenty years.
How Does Designing for Assigned Users Change Everything About UX?
One industry has been living inside these conditions since it was invented. Educational technology has never had the luxury of optional adoption. Students use the LMS because the syllabus requires it. Instructors manage gradebooks they didn’t choose. Administrators inherit platforms from decisions made before they arrived. Nobody opted in. The product just appeared one semester and was expected to work.
That constraint didn’t limit what we built at Openfield. It built us. Nearly two decades of designing for users who didn’t choose to be there in educational technology created a methodology that doesn’t assume goodwill. It earns it. And it transfers.
Our work spans more than 40,000 hours of EdTech user research across K–12, higher education, and corporate learning, interviewing students navigating tools they didn’t choose, instructors adapting to systems that weren’t designed around their workflows, and administrators managing products with years of accumulated design debt.
When iClicker needed to transform a hardware-based classroom response system into a fully digital product without losing the 7 million students and 5,000+ instructors who depended on it, the challenge wasn’t just technical. It was about earning trust from users who had no reason to be excited about change. When WileyPLUS needed to reduce friction in their student registration flow, the answer wasn’t a redesign. It was a targeted research process that identified exactly where the experience broke down, resulting in an 80% reduction in support tickets without a full overhaul.
These weren’t EdTech-specific problems. They were forced adoption problems. And the lessons from solving them transfer.
To learn more, check out our iClicker case study.
How Does EdTech UX Experience Apply Beyond Education? Five Lessons:
Over the past several years, we’ve applied the same methodology developed in EdTech to product environments well outside the classroom. The problems looked different on the surface. Underneath, they were remarkably familiar.
Here are five lessons that have transferred directly.
Lesson 1: Understand the Ecosystem, Not Just the Product
When Whole Foods Market launched Innerview, a new operations app for their store employees, adoption stayed low. The instinct might have been to redesign the app. But the real problem wasn’t the product. It was that the product didn’t fit into the ecosystem Team Members were already living in.
Our research took us into Whole Foods stores across the country, where we observed employees during actual shifts. What we found was a workplace that ran on clipboards, handwritten checklists, and physical discount cards. Some employees couldn’t even use their phones on the floor. Learning happened in the moment: when a customer asked a question, when a benefits issue arose, when something broke and someone needed information fast.
Innerview hadn’t failed because it was poorly designed in isolation. It failed because it didn’t integrate into an ecosystem of established behaviors and the culture Team Members associated with Whole Foods. We also discovered that the Amazon acquisition had created real anxiety. Employees were resistant to digital tools that felt like they might replace the entrepreneurial, human culture they’d built.
The outcome wasn’t a new app design. It was a foundational research framework of guiding principles, validated personas, and a strategic roadmap that Whole Foods could apply across any future product decision. As one Whole Foods product leader put it: “The research gave us a foundation we could build on, not just for this app, but for understanding how to support Team Members across everything we do.”
→ The EdTech Parallel:
We’ve seen this play out with LMS integrations repeatedly. A new tool gets built to connect with an existing learning management system, but the team designed it based on how the LMS was supposed to work — not how instructors actually used it. Nobody observed the workarounds instructors had built over years. The new tool launched, and the workarounds continued.
Lesson 2: Customization for Buyers Can Destroy Experience for Users
CrossKnowledge, a corporate learning platform serving major global enterprises, had built a highly configurable product. Organizations could customize it extensively to match their brand and structure. It was a strong selling point for the buyers: the L&D directors and HR leaders making the purchase decision.
The problem was what that flexibility did to the people actually using the platform. Corporate learners at companies like AirFrance, already navigating demanding schedules and competing priorities, would log in and not know what to do next. Assigned training sat unstarted. Completion rates disappointed. The platform had been built for the buyer, and the actual user had gotten lost in the process.
Our work focused on the two highest-touch areas of the experience: the dashboard and navigation. Through multiple rounds of research and rapid design iteration, we created an experience that helped learners immediately understand what was assigned to them, pick up where they left off, and discover new training relevant to their role. We also integrated Wiley’s existing design system (CrossKnowledge’s parent company), which created consistency across the product suite while preserving the brand customization that made CrossKnowledge valuable to its enterprise clients.
The result was a unified experience that served both audiences: organizations still had the customization they needed, and learners finally had the clarity they’d been missing.
To learn more, check out our CrossKnowledge case study.
→ The EdTech Parallel:
This tension between institutional buyers and individual end users is one of the most persistent challenges in educational technology. The administrator who buys the platform and the student who has to use it have fundamentally different definitions of success.
Lesson 3: Complex Integrations Require UX Thinking, Not Just Technical Thinking
When FastPark, an off-site airport parking company with 14 locations across the country, came to us, the initial request was simple: add a reservations feature to their website. What followed was anything but simple.
Years of growth through acquisition had left FastPark with a fragmented brand, an outdated website that wasn’t mobile-responsive, and a digital infrastructure tightly integrated with physical SKIDATA entry and exit systems at every parking location. PCI-compliant transactions, scannable virtual reward cards, location-specific rate management, and a loyalty program with legacy card data: every integration point was also a user experience decision.
Our team had to understand and clearly articulate a complex technical infrastructure before we could design anything meaningful for the humans navigating it. We worked alongside FastPark’s IT leadership to map account creation flows and validation architecture, identifying every permutation that could affect member data security. We prototyped, tested, and implemented a reservation system that introduced e-commerce functionality while remaining genuinely easy to use.
The outcomes were significant, with reservations measured in the hundreds of thousands and associated revenue in the millions. But the lesson was about process: you can’t design a good experience for users if you don’t first understand the system those users are navigating.
→ The EdTech Parallel:
Every integration point in a learning platform is a user experience decision. The teams that treat technical integration as a UX problem ship better products. The ones that don’t find out about the friction in support tickets.
Lesson 4: Mental Models Matter More Than Features
Wolters Kluwer’s CoursePoint+ is a powerful digital learning environment used in nursing education programs across the country. It’s a content-rich, feature-complete product that had been built with genuine care. It also had a fundamental problem: it was organized around how it was built, not how instructors thought about their work.
The product was structured by publication, the way a publishing company organizes content. But nursing instructors don’t think in terms of publications. They think in terms of the classes they teach. To access course content, instructors had to drill down through multiple publications, losing time and patience in the process.
Our baseline research surfaced this disconnect clearly. One instructor described it directly: “I think about things in terms of the classes I teach, not the publications I use, so it’s not organized the way I would expect it to be.”
The fix wasn’t a full rebuild. It was a targeted redesign of class controls and navigation that aligned the experience with existing instructor mental models. We also developed a componentized design system that created consistency across three products in the Wolters Kluwer Health suite, reducing user confusion and significantly cutting the friction that came from relearning workflows across different tools.
The broader lesson: when a product is built to reflect system logic rather than user logic, adding more features makes the problem worse, not better. Research that surfaces the real mental model is always the first step.
To learn more, check out our CoursePoint+ case study.
→ The EdTech Parallel:
This mismatch between system architecture and user mental models is one of the most common findings in our EdTech research. Products are built around databases, not workflows. The gap between the two is where users get lost.
Lesson 5: Siloed Teams Need a Shared Diagnostic Language Before They Can Fix Anything
Imagine being a graduate researcher at MIT. You know the article you need exists. You have the citation. You search, you click, you authenticate, you land somewhere unexpected, and you still don’t have what you were looking for. You try again through a different system. Same result. You ask a librarian. They walk you through a workaround that involves three separate tools.
This wasn’t a hypothetical. It was the daily experience of MIT Libraries users navigating a system of interconnected but siloed tools: the library homepage, Bento, Primo, DSpace, and Dome, each managed by a separate team with separate analytics and no shared picture of where the experience was breaking down.
MIT Libraries wasn’t lacking data. They had conducted 40+ user interviews, maintained detailed behavioral analytics, and managed rich insight repositories. What they didn’t have was a way to connect those signals into a coherent picture of where to focus. Each team saw a piece of the problem. Nobody saw the big picture.
Our work wasn’t a redesign or even a traditional research study. It was a diagnostic framework, a system that bundled individual metrics into clusters, giving every team a shared language for identifying where, why, and for whom their systems were failing. We mapped common user journeys across the full ecosystem, assessed technical feasibility for instrumentation with the analytics team, and co-created three feasibility tiers so teams could act immediately within current constraints while building toward longer-term improvements.
We also layered four interpretive lenses onto the framework: User Role, Intent Type, Entry Channel, and Search Input Style, so that the same data point could be read differently depending on who was experiencing the problem and under what conditions.
The result wasn’t just a better measurement strategy. It was organizational alignment. As one MIT Libraries stakeholder put it: “We were impressed with the depth and strategy of this plan, and equally impressed with how Openfield learned to speak the language of libraries.”
In complex environments, the ability to learn a new domain quickly, to understand the institutional language, the technical constraints, and the political realities, is as important as any research method. It’s what allows an outside team to facilitate alignment rather than impose solutions.
To learn more, check out our MIT Libraries case study.
→ The EdTech Parallel:
The same fragmentation plays out constantly in higher education. An LMS team, a library team, a student success team, and an IT team all have data about where students struggle. None of it is connected. Until someone builds a framework that makes sense of it together, every team keeps solving for their piece while the student experience stays broken.
How Do You Apply These Lessons to Your Product Environment?
If your users have no choice but to use your product, the question isn’t whether they’ll log in. It’s whether they’ll trust it, engage with it, and actually get value from it. That gap between mandated usage and genuine engagement is a UX problem. And it’s solvable.
The starting point is almost always the same: get close to the users who had no say in the decision before you make decisions about the product. Not through surveys or support tickets, but through the kind of contextual, observational research that shows you what people actually do rather than what they say they do. In constrained environments like hospital floors, warehouse departments, call centers, and retail stores, that kind of research requires a specific methodology and a willingness to meet users where they are.
From there, the work looks different depending on your environment. But the principles hold across all of them. Understand the full ecosystem your product lives inside, not just the screens. Design for the user who has to use it, not just the buyer who chose it. Treat every integration point as a UX decision. Diagnose mental model mismatches before adding features. And build shared diagnostic frameworks that give siloed teams a common language for understanding what’s broken and where.
We won’t come in and rebuild your product into something sleek that doesn’t survive contact with your users, your systems, or your organization. That’s not what we do.
We work within your constraints. Your legacy infrastructure, your compliance requirements, your team dynamics, your timeline. We do the hard work of understanding your users deeply enough that what gets built actually works for them. Not in theory. In the environments they’re actually in.
These aren’t EdTech principles. They’re Openfield principles that EdTech forced us to develop. They apply wherever the stakes are high and the users didn’t choose to show up.
Frequently Asked Questions
Can a UX firm with an EdTech background really understand our industry?
The methodology transfers because the human problems are identical: assigned users, competing stakeholder goals, and systems built around process logic rather than how people actually work. Forced adoption, multi-tier user structures, complex system integrations, and regulated data environments are challenges we’ve navigated extensively in educational technology. We also bring an outside perspective that internal teams often can’t, which is particularly valuable when a product has accumulated years of decisions that feel normal to the team but create real friction for users.
How do you conduct user research in environments with strict access limitations?
Access constraints are common in the environments we work in: hospital floors, retail stores, warehouse environments, and call centers. Our approach is to design the research method around the environment rather than forcing the environment to accommodate a standard method. That might mean 10-minute interviews between customer interactions, journal prompts left with participants to complete asynchronously, shop-along observations during live workflows, or remote sessions with a manager facilitating scheduling. The goal is to get authentic data from real users in their real context, whatever that takes.
What’s the right first step when a product has years of UI debt?
Start with a UX audit and foundational research before making any design decisions. UI debt usually means the product has grown in ways that made sense locally but create friction globally: inconsistent patterns, navigation that reflects how the system was built rather than how users work, features that duplicate each other, and onboarding experiences that assume knowledge users don’t have. A structured audit surfaces those issues objectively. Foundational research with real users tells you which ones matter most. Together, they give you a prioritized roadmap instead of a redesign that recreates the same problems in a new visual style.
How do you design for multiple user types with different goals and permissions?
Multi-tier user structures are one of the most common challenges in the environments we work in, and one of the most frequently underestimated. The temptation is to design for the most powerful user: the administrator, the manager, the buyer, and treat end users as secondary. That’s usually backwards. The end user’s experience determines whether the product actually works in the field, which determines whether the administrator’s goals are ever met. We research all user tiers systematically, map how their goals interact and conflict, and design experiences that serve each tier appropriately without forcing tradeoffs that hurt the people with the least power and the most daily contact with the product.
Does this approach work for products that are heavily regulated?
The conflict between compliance and usability is overstated. Most compliance requirements exist to protect users, which is exactly what good UX is designed to do. The key is bringing UX research into the conversation early enough to shape how compliance is implemented, rather than inheriting decisions that were made without user input and trying to make them feel less painful afterward.
Key Takeaways
- When users are assigned software rather than choosing it, the pressure to earn their trust doesn’t go away. It becomes more urgent.
- Forced-adoption software environments share a recognizable profile: forced adoption, multi-tier users, complex integrations, regulatory constraints, and accumulated UI debt.
- EdTech has operated under these conditions for decades, building a methodology that doesn’t assume goodwill. It earns it.
- Five lessons transfer directly: understand the ecosystem not just the product; design for users not just buyers; treat integrations as UX decisions; diagnose mental model mismatches before adding features; and build shared diagnostic frameworks that align siloed teams around a common picture of what’s broken and why.
- These aren’t EdTech principles. They’re Openfield principles that EdTech forced us to develop.
Your Users Didn’t Choose Your Product. That Doesn’t Mean They Can’t Trust It.
Whether you’re running a corporate learning platform, an enterprise operations tool, a healthcare system, or a workforce app — if your users were handed your product rather than choosing it, we know your problem. Let’s start with a conversation about your users, not our services.
