Confusion is a word we have invented for an order which is not understood.
— Henry Miller
This series of posts explores the common, but painful, issue of companies that have lost control over their Engineering teams. In the previous post, I talked about the zombie project, or “The Never-ending Story”. In this post, we’ll explore another virtual train wreck to add to our inventory of examples.
The Magic Bullet 
Our next example is familiar to those who have made it to the end of a long software development project, only to find out that the finished product is completely unusable by the end customer. Let’s play “fly on the wall” for this next one – like any train wreck, it’s horrifying to watch, but impossible to look away.
This particular project had the ambitious ambition  of uprooting the healthcare world. The new application would give the patient full control of their own health data, instead of entrusting it to the healthcare-industrial-complex of mega-corporations bent on profit and exploitation . Nothing inspires Engineers more than a David vs. Goliath, sticking-it-to-the-man type of story. Of course, the promise of untold riches for the company and all of its staff based on viral uptake didn’t dampen their motivation either.
Every aspect of the workflow had been thought through by the Engineers and Product Managers. The Product Managers, some very bright ex-Engineers, were confident that their design would set the industry on its ear. Unfortunately, their combined experience in healthcare consisted primarily of their own visits to the doctor, which as young, healthy people, weren’t very frequent or involved. No one had bothered to consult even a single nurse or doctor .
The user intake flow ensured that the patient had full control and met all federal privacy requirements. Before an account could be created, the patient had to agree to the Terms & Conditions of the account. An email would be sent to the patient while she was in the doctor’s office so that she could approve the activation when she got home. The hitch was that privacy laws prohibited the doctor from putting anything in the system until they had the patient’s approval. The result was that, for the current visit, nothing could be entered.
This presented a bit of a Catch 22: when the patient got home to agree to the creation of the account, it would be empty. This could get rectified at the next visit, but that could be several months. In the meantime, the patient’s health record would be a blank screen, which as you might imagine, doesn’t lead to the most compelling user experience or the kind of frequent usage that the UX people like to call “stickiness”.
Unfortunately, this shortcoming was discovered only a few weeks away from the launch date and the system had to go ahead as planned. The app launched with a whimper, from which it never recovered.
What went wrong?
In this project, the team built a key user flow that didn’t actually work in the real world. The issue is pretty obvious. Had they walked through and documented some real user journeys and vetted them with real users, the completely useless system would never have passed initial requirements review, much less getting a few weeks away from “go live”.
As in our previous example, the team had no idea what a real Customer needed or even their normal work processes. They needed to spend a lot more time on steps 1 and 2 before proceeding further. Visually, their flow looked like this:
Despite this, they proceeded to fill the subsequent stages with their own injected requirements and assumptions. There are a couple of items that should be part of the discussion with Customers as part of the “Needs and Requirement” that are passed down:
- Personas – the team needs a documented profile of the different types of users – in the case of the health records, it would be personas such as Patient, Doctor, Nurse and Medical Receptionist. For each user type, there needs to be a description of who that user is, what’s important to them, details of their technical capabilities, etc. There are many good examples of Personas on the Interwebs – I’ve included a few links in the References section below.
- Real-world flows (or User Journeys) – the team must document what the standard business flows are for each Persona, both in terms of what they do today and what they will do in the new world after your software is live (if that changes things). Again, there are many good examples of these and I’ve included some in the References section below.
The presence of these two items would have completely prevented the catastrophe outlined in this post. If we add these items to the Customer Membrane model, it looks something like:
This version of the Customer Membrane model also adds some detail around what “Designs / Capabilities” entails. Items such as wireframes and prototypes (both of which are very easy to create with modern tools) allow the Customer to assess how the system will work before expensive Engineering effort has been undertaken. These items (even in the absence of Personas and Real World Flows) would have also solved the problems outlined in this post .
Over the next few posts, I’ll share a few more examples. Please leave your thoughts and comments below.
This post is based on or excerpted from the upcoming book “De-Engineering the Corporation” by Darryl Ricker
 This is in reference to the “magic bullet” from the JFK assassination and not the handy miniature blender. If you recall, the theory was that the single bullet identified by the Warren Commission had to take an impossible path to explain the damage it caused. In this case, we are referring to a system where the flow is equally impossible – that is, it isn’t workable for a real user.
 Repetition intended (for no good reason).
 This was the opinion of the Product Management team, not my own.
 or even someone who played one on TV.
 Just to be clear, to be effective, the wireframes, storyboards and prototypes need to be shared with the actual Customer. Anything less does not provide the real benefit of these artifacts.
User Journey examples: