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

 

Developing software that is intuitive and meets user needs calls for a close partnership between a vendor and a couple of key customers.

 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:

  1. Users must be fully invested in it. Half-hearted participation won’t cut it.
  2. Users must use the software in as close to a real-world way as possible, as soon as possible. That is the only way to know if developers have hit the mark.
  3. Be agile. Effective collaboration among core development team members is just as important as with co-development partners.
  4. Do not get wedded to an idea or approach. Adhering to preconceived notions can undermine any software development project.
  5. Two co-development sites are much – I repeat, much – better than one.
  6. Listen. Your co-development partners are providing critical perspective and feedback, even if it is not necessarily what you may want to hear at any given point in the project.
  7. Be prescriptive. Your co-development partners know what users want to accomplish, but your team has the software development expertise.

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.

This article is shared by www.itechscripts.com | A leading resource of inspired clone scripts. It offers hundreds of popular scripts that are used by thousands of small and medium enterprises.