Request Processing R&D

$200K+ Saved. How a proof-of-concept prototype uncovered crucial gaps in the UX, saving unnecessary team & product lifecycle resources

Presenting rationale to help stakeholders understand the overall implications and potential wasted costs that would incur from data migration, training and onboarding that outweighed the perceived benefits.

Project Summary

Each internal department built their own app over the course of several years that served very similar functions. In essence: external users submit requests for internal processors to facilitate and review queues of work.

There were several pain points that initiated this project. Overall, it felt like the team was building the same app again and again with some subtle tweaks - but due to lack of cross-collaboration, this was often discovered too little, too late.

Can we design a single app to replace 6 others?

The proposition was attractive - reduce complexity overall and condense into a single formula. Through some workshopping and team discovery, we landed on a modular system that seemed to allow each department to keep customizations with their requests and intake processes while dramatically reducing technical complexity for developers.

Where the rubber met the road - user adoption

While demos of early concepts and prototypes continued to increase confidence in stakeholders, our users ultimately had a different response. The changes we proposed to submit "all requests" in one place created more confusion.

Finding ways to meaningfully categorize and differentiate requests for each department (and within each department) proved to be too complex. The more we differentiated each request type, the more technically complex the code became, defeating one of the primary appeals of the project. While external users occasionally did not like the separation of requests, the merging of everything was a worse outcome.

The verdict: table the pursuit - leverage findings in a few of the separate apps

We leveraged the attitudinal concept design feedback we received from external users as the rationale to pause production on the project. I coupled that data with our story map projection on how long it would take to get to an MVP state, determining that we'd save an estimated $200K+ in product lifecycle costs by not pursuing this (not including the additional costs saved from migrating each separate app's data and training both external and internal users).

Using this information, we helped direct leadership to make the decision to cease production of this new endeavor and instead, use some of the new feature discoveries on the existing request-like applications.

One of the biggest takeaways was having a "request tracker" embedded directly into the app that was more externally facing. This concept enabled all users to see how close their request was to being fulfilled (i.e. we're on step 3 of 7). This was a massive improvement from the previous 'ledger' of mostly internal user-created notes. This introduced some automation and increased internal user efficiency while simultaneously providing more clarity to external users.