Skip Navigation
The Pivot Point

From One Client to Many: Evolving a Digital Decision Aid

October 23, 2024 7 minute read

How can we scale software while still meeting the diverse and evolving needs of multiple organizations?

Back in 2019, we took on a project to design and develop a digital decision aid. The goal was to help patients make informed choices about genetic testing. At the time, it was a straightforward job—designed for just one organization. But soon, more institutions requested their own versions from our client.

Each new deployment presented unique needs. Some required adjustments to fit internal workflows, others needed changes in how data was captured, and a few wanted modifications in how patients received their results. What started as an occasional project quickly became a recurring ask.

Initially, we would replicate the existing design, make the necessary tweaks, and hand it off to development. Simple enough—until the requests kept growing. Soon, we found ourselves repeating the same customizations, sometimes with further adjustments, and it became clear: We needed to rethink our approach to scaling. How could we continue to meet each organization’s specific needs without reinventing the wheel every time?

Scaling Challenges

Our first instinct was to create one version of the decision aid and add new features as organizations requested them. In theory, this would allow all clients to benefit from updates made for others—a win-win situation. But as often happens, the theory didn’t hold up in practice. Each organization had specific needs—some even contradictory.

Take login methods, for example. One organization wanted a simple username and password system. Another preferred using a code provided by the clinic. Yet another required both—a code for initial access, followed by account creation. Supporting these variations was possible but added complexity. Over time, as more features piled on, updates slowed, and creating custom versions became less efficient.

And because many of these decision aids were built for research studies that lasted a few months, maintenance wasn’t always top of mind. Early on, we prioritized speed over long-term sustainability.

The "Generic" Decision Aid Experiment

To combat these growing complexities, we experimented with a "generic" version of the decision aid. The idea was simple: Build a scalable product with only the most commonly requested features. That way, organizations with fewer unique requirements could implement it without much hassle.

At first, this approach worked. But as clients started using the generic version, they naturally wanted to tailor it to their needs. Modifications began stacking up, and before we knew it, our “flexible” product had morphed into several highly customized versions. The experiment showed us that while flexibility is key, there’s no one-size-fits-all solution.

Keeping the Design Consistent

Another challenge emerged as we continued to customize: maintaining design consistency. While only one client requested a unique branding, new functionalities introduced subtle variations to the user interface. Over time, these small changes added up, making it harder to maintain a consistent look and feel across different versions.

We ended up managing three distinct UI libraries:

  1. The original version
  2. An updated design for new projects
  3. A client-specific version aligned with their branding

Balancing customization with design consistency became one of the trickiest aspects of the project’s evolution.

Lessons Learned

Looking back, it’s easy to see where we could have done things differently. We’ve deployed this decision aid more than 10 times now, each with its own specific modifications. If we were to start over today, we’d approach it with a few key insights in mind:

  • Plan for flexibility early on. A more adaptable UI library would have helped us scale faster and more effectively.
  • Anticipate variations in user flows. For instance, we’ve implemented five different login methods. Understanding which parts of the user experience commonly require customization would have streamlined development.
  • Prioritize data collection and storage tools. Many of these decision aids were for research, so building better integrations with platforms like RedCap would have been a smart move from the start.
  • Start discussions early about technical constraints. Things like patient and provider notification emails often require coordination with corporate IT teams. The earlier we address these, the smoother the project runs.

Looking Forward

Five years later, we're still making updates to this decision aid. Each new deployment brings its own challenges, but it also deepens our understanding of how to balance customization with scalability.

The biggest lesson? No matter how complex the project, thoughtful design and a human-centered approach can find the right balance between flexibility and consistency. At Pivot, we continue to evolve our processes, ensuring that every solution we build connects people with experiences that matter—one project at a time.