Design Thinking

This week’s lecture was addressed by Steph Mellor, a senior executive designer at ThinkPlace; it was quite insightful in that it introduced to us — in a very approachable manner, and with awesome Captain Planet references — the concepts encompassing a new way of creating solutions: design solutions.

Design Thinking is a way of looking at the world that tolerates ambiguity and manifests itself in the form of processes, methodologies, activities and synergies. Unlike most conventional methods of meeting challenges, design thinking promotes doing so without any assumptions: this is to say, design thinking professes approaching problem situations without prior bias, and to treat each individual situation in the particular context in which it exists. Moreover, a fundamentally unique feature of design thinking is that it is human-centric.

Design Thinking: A Dance of Fire and Nice

Design Thinking differs from most other methodologies of addressing problem situations in that it has, at the core, a human-centric foundation of interest. Additionally, it follows what can only defined as a verisimilar form of the scientific method: it comprises of multiple interrelated processes that define specific manners of meeting specific issues with complete regard for the specific context surrounding the issues in question; it focuses on observation, finding patterns from these observations, formulating educated notions to explain these patterns, creating solid methods to validate said explanations in a repeatable and palpable manner, and then making a final assertion, plan, or course of action.

F6.large
(Image courtesy: http://www.lifescied.org/content/5/1/7/F6.expansion)

To put it simply, design thinking — being human-centric — aims to create solutions that dance around humans, unlike making humans dance around the solutions. This is a critical factor in the success of engineering and computer systems, especially those intended to provide a service or utility for its users.

figure_2_CHW_592_488

(Image courtesy: http://ssir.org/articles/entry/human_centered_design_and_the_last_mile)

Case-in-Point: MetaVision Intensive Care Program

iMDsoftMetaVision.jpg
(Image courtesy: http://www.metropolitanmed.com/images/products/lg/iMDsoftMetaVision.jpg)

MetaVision ICU program (Katayama & Katsuyuki, 2011) was a software package developed by a US firm called iMDsoft as a specialist critical care application program. It collects information from an array of medical devices and full patient medical records, and is loaded with a knowledge-management and decision-support system that is intended to support administration of medications to patients in Intensive Care using IV infusion pumps. The Queensland government (McDonald, 2014)(Moore, n.d.) bought this package and planned to use it in over nine hospitals before a major bug was discovered in the package; one patient risked death due to this flaw which caused a large volume of drug-administration for the patient.

Upon the discovery of this fatal bug, investigation revealed that it had increased the likelihood of death for certain patient by 60-90 percent; a staggeringly dangerous figure. Analyses found that despite of the large scale of the knowledge-base and decision support system, there was simply too much data flowing through the ICUs for the system to be able to handle; the methodologies used to titrate specific dosages depending upon specific circumstances required what doctors later described as intuitive knowledge gained through experience. The program ended up being largely scrapped, and manually over-ridden as a result.

There was a gap (Weissman, 1992) in what the system was designed to do, and what it should have been able to do. This gap was that of a subjectively valued intuitive sense that humans seem to develop — a veritable spider sense, if you will. How could it be reasonably expected of the developers of the software package to bridge this gap? This was a rarest of the rare incident; the system worked just fine everywhere else, and even in the same hospital — with the exception of this one incident there were no signs of a malfunction.

The problem lay in the fact that the system was designed with the underlying objective of streamlining workflow in ICU, to drive down operational costs incurred by having to put nurses, doctors and attendants on the payroll, and to drive up profit — from the perspective of a purely administrative point of view, this seems reasonable, however, a system that focuses on the system is setup to fail. Brook’s law talks about the efficacy of adding personnel to a delayed project backfiring: a solution that aims to make stakeholders dance around the solution is not a solution at all. A software project can only be called truly successful if it can cater to the needs of the people who would be affected by the deployment of the project in the real world.

systemfailure.jpg
(Image courtesy: https://squatuniversitydotcom.files.wordpress.com/2016/02/systemfailure.jpg)

Designing the bridge for the gap

Design thinking can be seen in software engineering practices such as Agile development: a project is iteratively designed; a comprehensive risk-profile is associated with each iteration; the project is deployed to the market knowing that future iterations will probably be required. With Agile, and its early deployment paradigm, the products can go through the most rigorous forms of testing and feedbacks, that is, human usage. A partial full-scale deployment that is at the core of Agile enables users to really use the product, thereby putting it to real test. Knowing that multiple iterations are probably going to be required, the developers are geared to respond to feedbacks, instead of reacting.

Successful design thinking can be used to push the definition of systems engineering, especially for software engineers. Software is, after all, a part of a whole system, and not the system itself. Therefore, by having a comprehensive understanding of the position and function of the software components of a system, the software can be designed to engage the specific nuances as elicited by the specific requirements of the subsystem scope.

A good approach to bridge these gaps in the way softwares are built, the process encompassing designing softwares should take from some of the abstract concepts that go into making these softwares: a software engineering approach to software engineering, so to speak. Design solutions, and design thinking are enabling drivers for a such approach.

References

Katayama, K., & Katsuyuki, K. (2011). Development of a Clinical Information Management System for the OR, ICU and ER Using the MetaVision® System. THE JOURNAL OF JAPAN SOCIETY FOR CLINICAL ANESTHESIA, 31(2), 226–234.

McDonald, K. (2014, October 27). Bug in MetaVision ICU system potentially catastrophic. Retrieved March 31, 2016, from http://www.pulseitmagazine.com.au/component/content/article?id=2127:bug-in-metavision-icu-system-potentially-catastrophic

Moore, T. (n.d.). Health software brings risk of death. Retrieved March 31, 2016, from http://www.brisbanetimes.com.au/queensland/health-software-brings-risk-of-death-20141026-11c6nj.html

Weissman, C. (1992). THRESHOLD DETERMINATION FOR ICU QUALITY IMPROVEMENT PROGRAM CLINICAL INDICATORS. Anesthesiology, 77(Supplement), A324.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s