We just finished up a very big project with one of the major Boston hospitals. It was a great project – lots of strategic implications for the client, some interesting technology, and a user community eager for someone to solve the problem we were trying to solve. Of course, it was also one of those zero-to-sixty in three seconds kinds of projects with tendrils into EHRs and hospital information systems. We started with a blank piece of paper in January and at the end of July handed our work off to the internal IT department. They’ll be putting it into production this month.
We’ll be posting a case study on the project itself soon. But right now I want to talk about something we observed during the design process. Ideally, we like to get in on a project as early as possible so we can be involved in talking to users, validating assumptions about requirements, and making sure the customer is actually going to get what they want. It also helps us make sure that we don’t get stuck in a situation where the project may fail. This may not seem to be in our best interest from a business development perspective, like the time we did a round of user research only to discover that if the project went ahead nobody would use it (we still felt like we gave the client the kind of service they needed).
This time we got to do the whole cycle. We started with about thirty hours of interviews with primary care physicians throughout Massachusetts. Some worked in big hospitals, some worked in solo offices, some were in the middle. We asked them about their referral patterns to different hospitals, about the kinds of information they need to make decisions, and where their frustrations were when dealing with hospitalized patients. We had them talk through the process of caring for a sick patient, and learned a lot about what was working for them and what wasn’t.
After the initial interviews we came back around to share mock-ups and designs with a selected subset of our initial interviewees. They loved it, and their feedback was useful and easy to incorporate because we were still at the design stage. Once development was well underway, we went back a third time. This time we had working software to show them. Or, at least, more or less working software. Normally IT groups tend to shy away from showing partially finished software outside of very controlled environments. We’re careful about that ourselves – a bad first impression from a key user can really hurt a project during the broad roll-out, even if the bad impression was of early stage software six months before launch. But in this case we felt good about it since the users we were talking to had already been exposed to the design process – they knew we were still working towards the end goal, and they had a lot of fun seeing how their suggestions had (or hadn’t) been incorporated. Nobody got upset if a particular suggestion hadn’t been taken, and a few of them were very helpful in characterizing issues that we hadn’t been able to identify back in the office.
Subsequently, I’ve heard that these design partners have been aggressive proponents of the new system within their respective organizations. When it rolls out, they’ll be the first ambassadors – not because someone tells them to, but because they were involved in the creation and rightfully see the end result as the result of their work as well as ours.
And that’s how your users become champions of your product.
