Regardless of which option you choose, there are a few things to keep in mind. At Openfield, we’ve worked with product owners in both contractual capacities and have learned what makes each one successful.
Project-based UX is a limited engagement that puts specific guardrails on how your UX budget is used. It focuses UX research or design efforts on a singular product or even an individual feature within your product.
In our experience, three scenarios emerge as the best contenders for a project-based approach to UX.
Contract-based UX allows for more flexibility than project-based. Instead of earmarking dollars for a specific project or feature set, budget allocation remains fluid throughout the contract. This brings some significant benefits.
Regardless of how your UX contract is set up, you’ll want safeguards in place to keep both technical and design debt to a minimum. These debts — inconsistencies that accrue over time — can inhibit the ongoing success of your EdTech product if not identified and managed appropriately.
Shorter-term or project-based contracts typically increase the risk of incurring both forms of debt. That’s because the laser-sharp scope focuses on one issue at a time — and that can happen in isolation. Now, unknowingly, the same problem may be solved in different ways within an individual project or one product within a suite. This leads to the creation of debt situations.
Without the right protections in place, long-term UX engagements can also introduce additional technical or design debt. Fortunately, we find the same mitigation efforts work to reduce debt in both project-based and long-term UX approaches:
Ultimately, managing debt accruals within your EdTech product comes down to establishing — and communicating — the appropriate guardrails.
While we see a greater tendency for silos in project-based budgets, no EdTech project is immune. Regardless of what type of UX contract you use, it’s important to keep lines of communication open between your internal product team and your external UX partner. Otherwise, the UX team will have a restricted view of what’s happening outside their work. We often refer to this as the “keyhole effect.”
Imagine looking out your window through a keyhole. You’ll see some of what’s happening outside, but you’ll miss the vast majority of what’s going on. That can lead to a wrong assumption about what is actually happening.
For example, you might see a drop of water on the window in your keyhole view. Based on that, you might believe that it’s raining. So you’ll likely grab an umbrella. But when you walk outside, you discover that someone left the sprinkler running in the front yard. It is, in fact, not raining and the umbrella is unnecessary.
When this happens in your project — when your UX team doesn’t see the full product roadmap — they will make decisions based only on what they know. While the intentions are good, the results can create setbacks for future iterations of your product.
Whether your UX team is project-based or long-term, it’s important to share the broader picture with them — early and often. When the team realizes how your product strategy is evolving, they can deliver informed recommendations about how solutions in one product can (and should) inform solutions in another.
Regardless of which option works best for your EdTech product — engaging a UX team on a project basis or via a long-term contract — success ultimately boils down to context.
Give your UX team a holistic view of your roadmap and visibility to the work by other teams. With a greater understanding of the vision for your product, they can connect knowledge and solutions across a single product or multiple products. This improves the quality and consistency of the team’s work, prevents design and technical debt from creeping into your product, and delivers an impactful user experience.
Still considering which UX approach is right for your EdTech product? We can work with you to weigh the options. Let’s talk.