Key Facts
• The client had a core product they had been building for over two decades and the leadership was convinced they understood their target user and market.
• This understanding created a product that was siloed and difficult to work across, based on outdated assumptions of how people got work done.
• I led a team through multi-phase research to discover that some of these assumptions were true, but users were doing tasks that required features from across the product, meaning the silos were making their work more difficult, not easier.
The Problem
Leadership for the client had been around a long time, and they were convinced they understood what customers and users wanted and needed. Early on they had built an idea of their perfect enterprise user: someone who used the software day after day, all day long, to repeat the same series of tasks. This manifested in the product and the organization as a very siloed, modular structure, where some modules were seen as more business critical than others and given more resources and time.
As the system grew to work with more and more complex customer needs, things were changing. Customers were wowed by the power of the complex modules, but were stunned to find basic tasks like importing items, searching for things, and managing windows to be so difficult. Admins started pouring in with complaints that training and ongoing user education was becoming too burdensome. Still without evidence of their new core user base and use cases, leadership was hesitant to turn away from what they had believed for so long.
The Research Process
I set out with a multi-phased approach to understand the user and their usage patterns. First, I launched the largest user feedback survey the company had ever sent, reaching over 600 customers and almost 2000 individual users. In it, I wanted to measure how often people were using the software, if that stayed the same over time, what parts of the software were they using, and why.
The results told a much different story than everyone assumed. The assumption of mostly regular users was correct, however they didn't spend all day or even half a day in the system. Their work had become so interwoven with the system that they would find themselves jumping in and out of it throughout the day as various tasks and jobs needed done, with a large majority of users reporting 3 hours or less of total work in the system a day.
The survey was followed by direct observations and interviews with users, and I made sure to note any time they moved between modules and why. This uncovered the true story behind the product, which was that while some modules were certainly more central to a user's work, there was no single business critical module that should be prioritized. In fact, it was the integration of the modules together that was most important.
Results
This integration of modules was because users didn't see themselves as using the system for distinct tasks, but rather for flexible steps towards accomplishing a larger task. Even the "holy grail" users, regular heavy users of the case management solution, reported moving fluidly between case management, workflow management, and searching and importing items.
This shift in story led, in part, to a large reorganization of the company away from modules and more centered around the industries they worked with. This allowed teams to focus on how to integrate these many capabilities in the best way for specific use cases, rather than working in generic, siloed modules.