Usability‑Engineering Projects: What Are the Common Misunderstandings?

At the beginning of this month, Ilkka Juuso and Ilpo Pöyhönen published a book entitled Medical-Device Usability: Human Factors for Medical Device Development, which simplifies the process regarding the application of usability to medical devices for new developers by providing a thought-out walkthrough of what is involved and how the expectations from the essential standards affect their work and why.

When I spoke with Ilkka this past week, I asked him, "What are the most common misunderstandings developers encounter when starting a usability‑engineering project?" Here is his complete answer:

By far the easiest mistake to make is to think that usability in medical devices is just about an interface that is pleasant to look at and use. That will be a part of it, but far more important is the safety of that interface. An aesthetically appealing user interface is nice, an interface with all the controls in intuitive places is a great start, but what actually matters the most is that it is difficult to use the interface in the wrong way, leading to real harm to patients. That may sound counterintuitive from a general usability perspective – after all, usability typically talks about the ease of all use – but safety and the safe use of a device really is paramount when it comes to health. In an optimal situation, of course, all these rings align so that a safe interface is also intuitive and appealing, and thus hopefully even safer to use. In our book, we approach usability engineering from the viewpoint of safety, but also bring in lessons from the field of general usability engineering, which is useful to a discussion of medical devices.

The second mistake to avoid is keeping usability engineering as an isolated activity, run once and then forgotten about, without much impact on the development or maintenance of the medical device. In the book, we show how usability connects to the overall quality management and risk management activities of the organization, and how usability can actually inform the whole path from an initial product concept to a finished device and beyond. Our message here is that usability engineering is not just something you have to do, it’s something you should want to do because of how it can add to your knowledge of your user, use environment, and the use of your device – and bring benefits to all of these.

For those working in the medical device industry, do you agree with Ilkka's perspective regarding common mistakes? In your organization, does usability connect directly to quality and risk management?

Human-Centered Design (HCD) -- Does It Benefit the Agile Process?

Just this month, Joe Montalbano and Brad Lehman published a pioneering new book entitled, Human-Centered Agile: A Unified Approach for Better Outcomes, which functions as a guide on how to apply Human-Centered Design (HCD) practices to an Agile product development model that is used widely throughout industry and government, where it is applied primarily to software and technology development efforts. This has been an ongoing industry challenge due to the fact that HCD prioritizes time spent understanding the problems to be solved (time spent in the problem space), while Agile prioritizes a fast hypothesize-and-deliver model (time spent in the solution space). 

I spoke with Joe and Brad this past week and asked them: “How does Human-Centered Design (HCD) benefit the Agile process?” Here is their complete answer:

Is there any more overloaded and misused term than MVP? Theoretically, in Agile the MVP is a vehicle to test a hypothesis using lightweight code until value is proven. Teams can pivot. Teams can iterate. Teams get actionable feedback with every release and can be responsive.

The real world isn’t always like that. Not every team can pivot. Not every release is lightweight. Not every failure is graciously accepted as a learning opportunity. Oh, and did we mention that production-quality code can be expensive and time consuming?

Bringing HCD into an Agile delivery workflow gives teams a chance to do their learning earlier in the process and do it less expensively. It lets teams explore multiple solutions and mitigate risks by making informed decisions based on what their customers actually want, not just what an executive hopes they want.

So, what does Human-Centered Agile provide?

Earlier learning — Discovery lets teams identify real customer needs, and validate the problems they are going to spend money solving. Concept Validation with lightweight, disposable prototypes and mock-ups (paper drawings, wireframes, etc.) allows teams to test and refine their solution concepts with users before the first delivery, shifting learning left.

Cheaper learning — The cost of engaging with users for Discovery and Concept Validation is far less expensive than it is to write some production-quality code and then release it to get feedback. 

Lower risks —  The costs of building a product are not the only risk a team takes when launching a product. Releasing products that frustrate customers can harm their relationship to the product, whether they are first-time customers trying it for the first time, or experienced users looking for improvements. 

Unfortunately, too many teams and programs think that HCD and Agile are simply incompatible. They aren’t! We wanted to show everyone that they are actually well-aligned in purpose, and can be done together with some adaptation. This requires a change in mindset, but neither the change in thinking nor change in work practices are as dramatic as you might think.

What do you think of Human-Centered Design? Have you used HCD within your Agile process and workflow?

Reusable Visual Models -- Are Your Product Development Teams Using Them?

In September, Penny Cloft, Michael Kennedy, and Brian Kennedy published a book entitled Success Is Assured: Satisfy Your Customers On Time and On Budget by Optimizing Decisions Collaboratively Using Reusable Visual Models. This book teaches new thinking and methodologies to convert the chaotic front end of product development into a convergent process of set-based learning and continuous innovation – a game changer for companies that depend upon a steady flow of innovative products.

I recently spoke with Brian Kennedy about the book and asked him: “What are reusable visual models and why do they make a difference?” Here is his complete answer:

Each of those three words “reusable visual models" pack a fair bit of meaning. As “models," they are representing knowledge about the real world. They are capturing what we know how to do, what we know is possible, what physics allows. In addition, they are capturing what we are trying to achieve or what value we are trying to deliver. And then they are capturing the cause-and-effect relationships between what we know and what we want.

In complex situations where we must engage people with expertise in different areas to make decisions, having models is helpful, but only if all the stakeholders can understand those models. That’s where the “visual” comes in. We need those models to be visually understandable to people without needing to know specialized notations or languages that are only understood by people in certain fields. It is not good enough to just explain what you put in your model… you need those experts in different areas to really understand the model such that they can critique it and find the holes in it or the bad assumptions in it based on their own area of expertise. Finally, to maximize the benefits of such models, it is obviously best if they are “reusable” in similar situations in the future. For many that means capturing them in a known place that can be searched. Most companies, however, have “lessons learned," “best practices," and other such databases… but they experience very little actual “reuse.”

The first key requirement for “reusability” is that it was useful in the first place -- that your team of collaborating experts was able to use it to make the decisions they needed to make. If the knowledge you capture does not change the decisions you make in the future, then it has no value. So, when you make similar decisions in the future, you should be able to use those models to better make those decisions. That’s where the “set-based” aspect of those models becomes important: the models must be designed to capture the design space not a particular design (a particular point in that design space). It is hard to reuse a design to make the right decisions on a different design trying to satisfy different requirements. But knowledge about the design space -- knowledge about how what you know impacts what you want to achieve that is easily reused when making different decisions about different designs trying to satisfy different requirements -- is what we mean by “reusable." And just to stress that point, note that building “reusable" visual models is not just of value to future projects… it is hugely valuable on THIS project. Because invariably we will learn things over the course of the project -- and requirements and conditions may change -- and thus the decisions may need to change or be re-made. When you re-make those decisions, you want to make them considering all the knowledge you used before PLUS the new knowledge (the changes). That is done most effectively and efficiently with “reusable visual models.”

What do you think of Brian's explanation of these models and how they should be used? Are reusable visual models part of your product development team's process? More information about this technique and the book can be found here: SuccessIsAssured.com

Meeting Customer Needs is Not Enough

Lance B. Coleman recently published a book titled The Customer-Driven Organization: Employing the Kano Model, and I spoke with him about its content. My main question was: “Why is meeting customer needs no longer enough?” Here is his full response:

In an expanding global economy having international competition, meeting customer needs is simply not enough. Meeting customer needs leads to customer satisfaction but does not lead to customer loyalty, which is what keeps companies in business.

Delighted customers, however, are loyal customers. The Kano Model developed by Noriaki Kano describes delightful performance as that which surprises and excites the customer in addition to meeting their basic needs. To “delight” a customer, an organization or individual must become aware of not just what is asked for but rather what is needed. They have to look to the future as inspiration for innovation today.

Quotes from two of our greatest innovators born almost 100 years apart would tend to agree.  Steve Jobs is known to have often said: "A lot of times, people don't know what they want until you show it to them." Henry Ford is reported to have said: “If I had asked my customers what they wanted, they would have said 'a faster horse.'”

Providing delightful service is more than just a nice thing to do, it is an imperative for business/professional survival both for the organization and for the individual. What I have tried to share with readers of my book, The Customer-Driven Organization: Employing the Kano Model, was threefold  -- why a philosophical paradigm shift is required to provide truly delightful service, how to practically apply the concepts espoused by the Kano model, and finally, why one should care to do so.