My first guest blogger is a long time friend, Eugene St.Clair is CEO at Humanproof, a Human Factors Engineering consulting firm headquartered in Arlington, Virginia. He has 14 years of experience supporting the FAA, Navy, Homeland Security, and other government and commercial clients and strives to bring Human Factors Engineering and Usability testing to air traffic control, information management systems, and other large-scale systems such as ships, healthcare, and energy production. Using the disciplines of Human Systems Integration (HSI), Gene and Humanproof help to reduce total system lifecycle cost, human error, and improve total system performance and safety by addressing the needs of each user in the context of the task, system, and operational environment.
How to save a billion dollars tomorrow…
I will start by saying that I recognize there is no ONE right way to do anything. With that said, I also won’t hesitate to say that my way is better than yours. In all seriousness though, each method has its pros and cons and I offer up only a suggestion that may augment our capabilities, speed product development, increase user satisfaction and user adoption, and ultimately advance the progress of the human race.
I have heard much about development processes such as waterfall, scrum, spiral development, sprints, etc etc etc. I have heard much from software developers about how modules and tasks can be split up and built and basically after very few meetings and little understanding of the real requirements of the end product, everyone runs off and starts coding, building, and trying to figure it all out. This method is then mitigated by more frequent meetings and increased communication among the team.
I have been working in acquisition for years and have had my fair share of meetings where people design things by committee, drop and add requirements based on the time of day or proximity to lunch. After all this, what I have found is that all these processes focus so much on building features, moving data, and presenting information, readying software for test, and staying on schedule, people don’t seem to stop and ever look at WHAT they are creating and WHY. It is not until things start being put together, that we realize that the human operator has some things they may want to chime in on.
All these development methods focus on making sure electrons and information get from A to B in a timely manner and the project is a “success”. Then we start to see managers presented with things such as “here is how many requirements we can meet, here is what we can build by this date, and what must be left for the next version.” I hear things like “we met 99/106 requirements”. This success rate would be 93% and result in a grade of “A” in any school. Except, of course, as is often the case, some of those missing requirements happen to be on the users’ path from A to B in THEIR task flow.
My point is this. For all the time and energy we spend trying to find the best way to build things on time and on budget, we continue to overlook the 90% of value we could derive from spending more time up front in the pure analysis of user tasks within the system. In this process, you can identify specific task flows for users, match their mental models, and once you look closely, this work will result in the dramatic simplification of not only the software itself, but all the forms, templates, processes, and tasks involved with the environment within which a system may operate.
So often we provide usability testing on software that ends up having fractured capabilities and even missing functions in the middle of a user’s task flow. These holes in capability drastically reduce your system’s value, result in user frustration, and present serious impediments to user adoption and acceptance. What does this mean for you the developer? All the iterations in your team development, all the review cycles, all the reengineering, to get it right can be cut dramatically. It IS possible to get it right the first time, or at least get it 95% and then focus your energies on perfection.
While usability testing, like we do at Humanproof, can provide extremely useful design feedback on products that have already been built, and seek to improve user adoption and acceptance, the real opportunities for game changing software interfaces happen before the first bit of code is written or any single requirement is identified.
How? By focusing on the user’s task, environment, and mission/goals, we can first identify what they are really trying to accomplish. Then you begin to see, although they are asking for certain data, what they really may need is information in a specific presentation format, to support a specific decision. Once you start treating humans as decision makers instead of information integrators, you unlock the pure power of the human mind. Then, and only then, can you design something that truly helps them excel instead of simply using technology to replace an outdated, unsecured, paper-based system on the brink of extinction. Couple this with iterative usability testing throughout development (concept development through OT&E) and you will drive down development times while creating unprecedented user (and customer!) satisfaction.
In closing, if you think I am being overly dramatic in stating the potential savings from the early application of human factors and usability testing in software and hardware development, I invite you to email me directly. It has been my personal experience that this is the bare minimum that could be saved nearly immediately. Using examples from my own career and experiences of my peers, it would only take about 5 minutes and the back of a napkin to demonstrate this. When Human Factors practitioners and software developers work in close coordination, the benefits both in user satisfaction and cost savings are astronomical.