ARTICLE: Chris Albert

Project-based or long-term contract UX: Find the right approach for your EdTech product

Both project-based and long-term UX contracts have a place in the EdTech space. It’s not an either/or scenario. But each option for engaging an external UX partner comes with a unique set of considerations. The scale and scope of your project will play a significant role in your decision about the best approach.

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.

When Project-Based UX Makes the Most Sense

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.

  1. You’re evaluating the fit of a potential UX partner. Bringing in an outside team to oversee the UX research and design for your EdTEch product can feel intimidating. A project-based UX engagement lets you scale work and take the new team on a “test run.” You’ll learn about the team’s structure and see how they will work with your own people. You’ll also understand what outputs you can expect before you invest a significant amount of your budget.
  2. You have a single, mature product already in the market. If your EdTech product is established, you may want to concentrate your UX efforts on a specific feature or component. A project-based UX approach affords you the opportunity to bring a team in to make targeted, incremental changes. 
  3. You want to add to the power of your internal team in a focused way. UX research and design can be a significant undertaking for your team. Bringing in an external team for a specific task or amount of time keeps your project moving forward and reduces the burden on your internal team

The Benefits of Contract-Based 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.

  • The ability to pivot quickly can address shifting priorities. Because the budget in contract-based UX is not tied to a specific output or deliverable, it’s easier to change the focus mid-stream. When research findings or market changes demand a reallocation of effort and resources, your external UX team can quickly move attention — and budget — to the new priorities.

    A flexible budget is also beneficial when your UX team can complete a feature initiative more efficiently. The money saved in that instance can then be easily reallocated to initiatives that might require more investment.

    One important note here: The actual dollar amount of your contract does not preclude you from this flexibility. Even modest budgets can benefit from this approach.   
  • Work can be more easily leveraged across products. Contract-based UX is typically tied to a suite of products rather than one product or feature. The work in this context, then, typically includes recommendations that benefit the entire suite and will help gain efficiencies.

    Even if the team is working on a singular product under your contract, the understanding of how that product fits into the larger suite means they can conceive, design and build solutions in a way that can be leveraged across multiple products.

Protect Your Product From Technical and Design Debt 

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:

  • Developing a design system and establishing development standards make it easier to maintain consistency across a singular product and multi-product suites. 
  • A consistent flow of information (i.e., sharing regular updates on research, design solutions, etc.) equips your team to head off the infiltration of unintended design and technical debt. 

Ultimately, managing debt accruals within your EdTech product comes down to establishing — and communicating — the appropriate guardrails.  

A Word of Caution About the “Keyhole Effect”

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.

The Right Approach for Your UX Budget Comes Down to Context

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.

  • Photo of Chris Albert
    Chris Albert

    As a UX Design Lead at Openfield, Chris is a deep thinker with a savant-like ability to untangle and simplify complex systems. Now in his 8th year with Openfield, the wisdom of his 20+ year career in design and his tireless devotion to his work and clients inspires everyone at Openfield. Out of the office, you’ll find him doing the same thing he does at work – ever advancing one of his many crafts and interests. He’s a letterpressing photographing traveling gaming car guy. Chris is our Renaissance man.

Spread the word – help avoid the traps of digital product development!