Setting the Stage for Success
Healthcare User Research & Functional Requirements
After a year of discussions, a high-priority project had little to show other than an incomplete MVP and a host of unresolved—and unasked—questions. I worked with the client to understand their needs and helped them understand the needs of their users, so that we could create a set of functional requirements, project roadmap, and estimate that would take the project past the finish line.
First order of business was a long series of stakeholder interviews with the clients C-level executives and relevant project managers. I then moved on to interviewing the actual users of the Products in question. These first were conducted with the larger client team present. Fortunately, I received permission to interview representative users individually - free from the potential distraction of bosses and C-level executives who are their bosses' bosses.
With the user interviews concluded, I moved onto a series of ethnographical sessions with three different end user groups: facility and nursing staff, the client office staff who would be selling and supporting the product, and managerial level users.
Based on what I learned in the stakeholder interviews, user interviews, and enthography, I assembled a set of four macro personas that covered the high level representative users of the Product. Since this is a controlled access extranet, we were fortunate to know exactly who would be using the Product and the types of people who would be using it in the future. As such, we avoided the biographical details commonly seen and focused on specific feedback and insights gathered from the user research.
Identifying who our users were and what exactly they thought was particularly important for the Product, as it was being driven from high up in the organization, but would impact the ground level employees the greatest. Personas focused on fact and feedback helped to ensure that the needs of those users wouldn't get lost in executive conversations driving the project forward.
While the Product itself isn't terribly complex in and of itself, HIPPA regulations meant that use cases and user rights would not be as straight forward to implement. Ultimately, I worked with the Client stakeholders and developer partner team to create a single user roles doc that further seperated the four personas into a larger set of user roles that dictated scope of access, tracked contextual notes, and identified priority users that needed to be addressed early on in development.
Along with the User Roles doc, the Functional Requirements document helped fully define the scope and structure of the Product. The document began with simple Agile-inspired user stories (As a X, I want Y, so that Z.) and grew to capture important requirements data.
With the user stories keyed back to the User Roles and Personas already defined, I worked collaboratively with client stakeholders and the development partner along two initial vectors: 1. capture the existing functional requirements that exist in the team's tribal knowledge of the Product and various collateral, and 2. identify and define new functional requirements that came to the surface during the phases of user research (at which point the Personas were a helpful reference point).
From that point, the Functional Requirements were fleshed out even further. Benchmarks (data, input, performance, and usability), expected complexity, and priority and impact metrics were all captured. Having all this content in a single, referenceable location proved vital as the usual conversations surrounding a project about features, feasibility, and scope creep (and shrinkage) sprung up. We knew who our users were and had a good idea what they wanted, and we had a solid foundation on what those expectations should translate into.
With the personas, master user role doc, and functional requirements created, all three parties involved in the project - the client, the developer partner, and us on the UX/design agency side of things - had firm footing on what the project would ultimately involve, what aspects of the project were likely to prove troublesome, and which aspects of the project needed to be designed, developed, and tested first. We spent the time and money up front to do good research and discovery work, and that would see dividends as the Product moved forward.
In a world cluttered by confusing websites, too-clever apps, and mountains of unnavigable content, ensuring your customer can easily, effectively, and efficiently interact with your digital product makes a very real—and financial—difference.