As a product leader, one of your primary responsibilities is to connect the leadership team’s vision of their EdTech product with the actual needs of the product’s users. To do this well, you must execute leadership’s vision responsively. This means modulating the product roadmap as your product team surfaces new information about user needs or identifies risks associated with leadership’s vision. Leadership teams are naturally more future-focused.
Within any product, there exists a large set of individual design elements, from buttons and colors to menus and form fields. Together, these individual elements make up the basic building blocks of a product’s design. Design systems are the means by which product teams document those individual components, describe how they behave, and provide usable guidelines for how to build patterns and workflows. Many product teams write off design systems as being superfluous.
Usability problems can crop up in EdTech products for any number of reasons. An incomplete understanding of user’s needs. Inadequately defined product requirements. Insufficient user testing. The list goes on. Many of these issues can be headed off simply by incorporating UX and user-centered design best practices in the product development process. But no matter how attentive your team is to its users, and no matter how airtight your approach, there’s another usability problem that is sure to materialize with time: design debt.
When we begin a UX engagement with a new EdTech client, our first priority is to quickly learn as much as possible about our client’s product and users. Our collaborative process begins with a phase of research and user understanding that includes an in-person discovery session. The discovery session allows a products’s stakeholders to identify problems, clarify goals and priorities, and align around a shared vision for their product – before identifying solutions. Here’s what you need to know about this critical planning session — and how you and your UX team can make the most of it.
When your engineering team is in the midst of an agile development sprint, they must be laser-focused on the tasks that comprise the next leg of their work. That sort of tunnel-vision is a good thing. Good, that is, so long as it’s tempered with an appreciation of your users’ needs. You see, unless engineers intentionally approach their work from an empathetic, user-centric perspective, they will naturally prioritize technical limitations and considerations over other factors — sometimes at the expense of user needs.
