To Build Software that is Easy to Use, Engage the Right Partners

You don’t have to look far to find software that is difficult to use, especially in healthcare; electronic health records (EHR) systems are the bane of many physicians’ existence. Mobile computing and app stores have shown us a different way. When we download the Uber application, for example, Uber doesn’t send a driver to teach us how to use the app. It is intuitive – no instruction required.

Of course, enterprise software is more complex than hailing a ride and healthcare has some of the most complex workflows of any industry. But should that condemn us to applications that are challenging to use and require tremendous amounts of training? I think not.

Like most developers, I strive to make the applications my company builds as intuitive as possible. We have had our share of successes, but on occasion, we also have designed software that falls short of the mark.

Why is it so hard to build software that is easy to use?

One of the biggest challenges is that software must be intuitive to someone who hasn’t yet seen it. This immediately disqualifies everyone who works for your company. Even worse, it disqualifies your user community, especially your most vocal power users. They tend to push you to build software that is complex.

One of the best examples of this is the old Sabre system from American Airlines. Its user interface consisted of a prompt and a blinking cursor. A skilled travel agent could type a string of characters and quickly book a flight. This was super powerful, but it took years to master.

Of course, today we know there is a better way. We can search and book flights on our smartphones without any training, and certainly without a travel agent. This didn’t come quickly or easily, however.

How do you overcome the inherent forces that push you to make complex software?

I discovered an approach to developing intuitive software years ago, by accident. In the mid-1990s, I joined a small public company called HPR as head of new product development. I was tasked with building a next generation Case and Disease Management platform for payers. There was only one problem: I had no idea what case and disease management was, and nobody in my company did, either. It turns out that this was a blessing, although I can assure you it did not feel like one at the time.

I had to find someone who knew something about case and disease management. The only people I could find were payers – Tufts and Healthsource, an innovative health plan in New Hampshire. We worked closely with them to design, build, and deploy what became known as CareEnhance Clinical Management Software (CCMS), a revolutionary approach to payer-based case and disease management.

I had stumbled my way into a process for building intuitive workflow software, which I now refer to as “co-development”. It begins by selling a concept to two customers. In return for discounts, free services, and sometimes royalties, our co-development partners make their end user community available to us throughout the entire development process. They review initial mock ups and prototypes all the way through alpha and beta processes. Importantly, they also agree to be our first production sites. That way you have great reference sites from day one.

Selecting two partners is critical. When you only work with one, it is hard to tell what workflows and processes are “unique,” and which are common. With two, it is unlikely that both will have the same unique processes.

I was recently reminded how important it is to adhere to this “co-development” process. We had what seemed like the software equivalent of a tap-in putt. We wanted to add tools to our software that would make managing custom components easier and less prone to error during upgrades. This was also a tool for our company to use to manage our own software; we were both the developer and the end user. How easy would this be?

We stepped away from our co-development process and simply asked some of our team members what they needed. Then, we added what our engineers thought users might need and built it. It probably isn’t surprising that we missed the mark, and now we are in the process of building version 2, and doing it the right way.

So if you are considering employing this co-development process for your next software development project, here are seven tips to keep in mind:

If you are thinking that the last two items on the list are contradictory, you are right… and wrong. This is where the art comes in. Most users don’t know how to design software (and those that do, you don’t want as part of this process). Co-development doesn’t mean someone hands you a spec. Rather, it means you put yourself in position to build great software the first time, which is what every vendor should aspire to.

Paul Brient brings more than 20 years of experience in healthcare information technology including physician workflow automation, physician practice automation, payer-based medical management, pharmaceutical-based disease management and medical devices. Prior to joining PatientKeeper in 2002, Brient held senior executive-level positions at leading healthcare and consulting firms including McKesson Corporation, HPR, and The Boston Consulting Group. Brient began his healthcare IT career as the founder and president of BCS, an early physician office management software company. He earned his master’s degree in business administration from Harvard Graduate School of Business Administration with High Distinction (Baker Scholar). He also holds a bachelor of science in electrical engineering and computer science summa cum laude from Princeton University.