Enterprise vs. Consumer UX in EdTech, Part 2
A continued deep dive into the confusing and contradictory nature of design in EdTech
In Part 1 of this two-part series, we explored how our work in EdTech takes on aspects of both enterprise and consumer product design, and the impact of that ambiguity on:
- our view of buyers vs. users
- the skills we must bring to the table
- how we find motivation as designers
Today we conclude by continuing to use the enterprise-consumer frame as we consider its impact on the roadmap planning process, and to what extent, if at all, we can rely on our users receiving professional development to use our products.
Product Planning
There’s a classic push and pull in software between managing complexity to maintain a clean and simple experience, and adding features to appeal to as many potential customers as possible. A large part of this process entails dealing with an endless flow of customer requests.
In an enterprise setting, some of these requests can feel more like demands. No matter how much a company earnestly and sincerely values all of its customers, when those customers are organizations rather than individuals, some are going to be more strategically important than others and must be retained at all costs. Naturally, demands from these customers are given priority.
For product teams, these sudden and unexpected product requirements can upend the roadmap. In the worst case scenario, planning is reduced to an exercise in prioritizing and sequencing feature requests from important accounts. For smaller customers, this reality means potentially having to accept changes to the product that they neither asked for nor want.
On the other hand, when you sell to individuals, as in consumer product development, it becomes very difficult for one customer’s voice to rise above the others and have disproportionate influence. In this context, the roadmap planning process is much closer to its platonic ideal. The goal is to attract and retain users, rather than organizations, and so we are free to base our decisions on our own vision and our own research.
EdTech as enterprise: feed the big fish
This tension can be particularly pronounced in EdTech. As district-level purchases have increasingly become the main driver of strategy and sales, the feature demands of specific large districts must be taken seriously. Additionally, the pursuit of RFPs and efforts to be included on state- or district- approved vendor lists both typically entail committing to develop a long list of features.
As a result, in classic enterprise fashion, product direction is determined from the top down, mandated by the needs of the big fish, while everyone else tries to keep up with all of the change.
EdTech as consumer: please the people, create demand
On the other hand, with the rise of the freemium model in our industry, some products look to take a bottom-up approach to roadmap planning. Here, the incentive is to create organic, word-of-mouth demand, and so delighting and meeting the needs of the daily user is the top priority.
In this setting, we are free not only to add or change features in whatever way we deem most beneficial to the user, but also to kill off legacy features that did not work as we hoped or have outlived their usefulness, without fear of reprisal from any one specific customer.
Our challenge: defend the experience
Given the volatile mix of massive growth and rapid consolidation in EdTech, it is not uncommon to see multiple business models represented within the same company. So, if you work in this industry, chances are your product planning process will look like some bizarre and unnatural hodgepodge of the above.
Regardless of the business model, once a certain level of success is reached, local requirements and demands from important customers will need to be accommodated to some extent. And, because we’re designers, actually helping our users solve problems can never not be the goal. So, the challenges are to:
- mitigate experience rot by incorporating customer requests in ways that provide value to actual users
- aggressively and doggedly look for ways to remove unnecessary complexity from legacy features
- perhaps most importantly, figure out when you can push back against certain customer requests
Once you’ve truly leveled up, you’ll be able to spot cases of your own internal stakeholders requesting features in (often questionable) anticipation of customer demands. Knowing when the call is coming from inside the house is a crucial skill.
The Learning Curve
A large part of enterprise design is figuring out how to get software to support the completion of complex tasks in a way that incorporates users’ understanding and preferred approach. A major determinant of success is the ability to balance efficiency and learnability.
In some cases, it makes sense to favor efficiency at the expense of first-time learnability. That is, if many users will spend hours at a time in this process, their initial learning curve is less crucial than their ability to work efficiently once they are up to speed. That ongoing work accounts for the vast majority of their experience.
In other cases, if a task is completed infrequently, then every time it is used is like the first time, and so we optimize for first time learnability.
Either way, because of the inherent complexity of the tasks these products support, most enterprise software, in stark contrast with consumer software, is designed and sold with the expectation that its users will receive some level of training.
…from the perspective of the teacher, these products need to work like consumer products. They need to provide value even in the absence of effective PD.
EdTech as enterprise: teachers receive training
Expectations around training (or, “Professional Development” if we want to be fancy about it) certainly apply to EdTech programs. In fact, many districts will put in a lot of effort to develop an infrastructure to support learning the EdTech products they’ve purchased, and will often work directly with the providers of those products to develop and deliver that instruction.
It’s tempting, then, to think that we can simply rely on this PD to help teachers understand the most complex workflows in our products, and that we’re off the hook, free to optimize for efficiency without worrying about the learning curve. And yet…
EdTech as consumer: teacher training is inconsistent and unreliable
For every district that invests heavily and puts a lot of thought into PD, there are plenty that take a more haphazard approach. This is difficult stuff, after all, and working around teachers’ chaotic schedules presents its own set of challenges.
Even when you can manage to get most of your teachers into a room together, there will often be a mess of distractions to contend with — students wandering in and out, announcements blaring over the loudspeaker, bells ringing. Once complete, there’s rarely a defined process to verify that what the teachers learned has stuck, nor any guarantee that teachers will be able to reinforce their learning by immediately applying it.
In this sense, from the perspective of the teacher, these products need to work like consumer products. They need to provide value even in the absence of effective PD.
Our challenge: facilitate learning in the product
If we can’t rely on teachers learning outside of the product, we better make sure they can effectively learn while using the product, and that, to the extent possible, we allow all users to work effectively at their level of expertise. While the right approach depends on the context, some things to consider are:
- creating effective onboarding experiences
- placing help in context and building in nudges to guide users toward best practices
- building in modes associated with level of expertise, and allowing users to move toward more streamlined experiences as they stop needing the built-in support
In addition, time spent thinking about designing for teachability, to help ensure that the software itself facilitates effective training, is time very well spent.
Conclusion
You may be tempted to take stock of your current situation — the work you do, the skills you need to do it — and conclude that most of this doesn’t apply. You may be right! But, EdTech is a vast and dynamic space. If your focus today is on a student-focused, freemium product, you may require little to no expertise in enterprise design. Just keep in mind that in software, as in most things, success begets growth and change. If your product reaches its potential, it is very possible you will be called upon to do things like build in a robust rostering system, flesh out the reporting, and make it interoperable with other products in complicated ways. In other words, future needs may very well require enterprise design skills. It behooves you to be prepared.
To design in this space it is to constantly challenge oneself to grow and adapt, to navigate competing pressures and interests, and to learn how to wisely pick one’s battles.
About the Author
Josh Singer is a Principal UX Designer and former Math Editor at Renaissance Learning. He has previously written for the UX of EdTech about making student assessment data useful.
👉🏽 Job Openings: UX Roles in EdTech
👉🏽 Podcast conversations on UX in the EdTech industry
For future updates follow UX of EdTech on Insta, LinkedIn, and Twitter.
