Earlier this week at our centre-wide, monthly meeting my colleague Lily Alexander took the opportunity to train us one of the most boring subject-matters that ever existed: ISO 13485. So sorry Lily, but it’s true.

What is ISO 13485?

From what I understand so far ISO 13485 is the standardized regulations around medical device manufacturing that implies the makers have adhered to a certain level of quality and are basically to be trusted (and held accountable). Devices can be certified. Teams can be certified. And organizations can be certified. Our Centre for Global eHealth Innovation is the first department at University Health Network to incorporate these standards into our process.

If you’re insanely curious or having trouble sleeping, read more about ISO13485 standards here.

Needless to say, I knew my mind would wander during this presentation, so I decided to take sketchnotes to keep my mind present. This is certainly one method for taking a boring topic and making it more interesting. But sketchnotes are a surface solution. A better method for making boring but important content better is to make it more relevant, and I guess Lily did a pretty good job because afterward, I wanted more.

Having recently adapted to the process over the course of designing one of our new mobile applications, I discovered it is not ISO I specifically dislike, but a couple things just don’t make sense to me process-wise. Here they are.

Documentation Fiction

ISO loves its documentation. Documentation creates an awful lot of waste (we are still discussing how not to print out every single page from Redmine). Otherwise, documenting designs is something most designers should be doing anyway. Save versions. Write down feedback. Leave a trail of how design decisions were made.

Documentation (a bit like time-tracking) exists on a varying scale of fiction.

For example, it is difficult to accurately document reasons for design changes when the changes are coming from the designer instead of from someone else making the request. Say, when the designer has had a stroke of insight. I challenge any ISO auditor anywhere to document a stroke of insight.

Granted, I’m sure creative insights are not impossible to document. They can certainly be documented as change requests, but is this a realistic reflection of what happened? People want to do a good job. They want their reports to be accurate. This is one of those things that as designers, we have to learn to let go of.

Not only that, but the extra work put toward documentation (work that does not go into the product itself) runs the risk of pulling time and interest away from making last minute tweaks and polish. Last minute tweaks constitute the final 10% of a product, perhaps the most important percentage that sets products apart from their competitors.

ISO doesn’t care about the Product

One thing I learned from this training is that auditors don’t care to see the final product, they care about the documentation. They will often never see the product, only the decisions that led to the creation of the final product. I’m not sure if I am suffering a lack of imagination, but I just don’t see how it could be possible to tell whether a product is fool-proof only by admiring its paperwork.

Documents are not products. And it is the product that should count. Perhaps it is that the product is only important in regards to ISO if there is a problem; the documentation would be used to trace the trail back to the source of the problem – in other words, to find out who should be blamed.

This doesn’t help teams build faster or more efficiently, doesn’t encourage innovation, and I wonder – does it actually make anybody safer or healthier?

Sooooo sloooooooooooow

I am falling in love with the Slow Web, but when I’m building or making or crafting something, I need to get into the flow of building. I need the spirit to move me. And I need that to happen so quickly I don’t register that I am actually doing work.

I don’t want to have to stop what I’m doing to document (and validate) what app I just purchased to test my designs on a mobile device, particularly if I’ve just upgraded my OS and the app I was using no longer works and I just need to get it done now so I can go have my 10pm dinner.

This requirement is inefficient and shows a lack of understanding of creative process. Designers and developers need uninterrupted time and space to get into the flow and process the work. The light at the end of the tunnel is that theoretically, this purchase could be documented between iterations or stages of flow, which is the process I hope to adopt myself.


I can see how requiring such extensive documentation will encourage (or at the very least scare) producers into doing the right thing and being careful. But it may also be to the detriment of the pace of advancement in healthcare technology. It is estimated that adoption of ISO 13485 standards results in a 5-50% increase in project effort. That is some range, and of course we are aiming to be on the lower end of the scale, but I wonder on which side we will actually fall.

Colin Gray, owner of an ISO consultancy, wrote:

“All management systems require internal auditing. Done well internal audits bring benefits by protecting against issues before they are found by the registrar, highlighting opportunities (and waste).”

This is absolutely true and luckily, I work in an environment where the three problem areas I highlighted above are mitigated by fastidious project and product management. In addition ISO seems to have a rule that says we make the rules, that is to say that we outline our process and how our documentation fits into that process. As long as we follow the process we outlined (which applies to Agile or User-centered-design, both of which we use at Healthcare Human Factors), we should be good. I think this rule of exception is lucky for healthcare.

The part that makes me uncomfortable is that a good creative process is hardly static. Designers are always folding in new sources of inspiration and co-conspirators to keep our ideas and our work fresh. Spontaneity is a key trait of my own process, and it is perhaps my favorite part about being a designer versus being a project manager. I fear that creative spontaneity will get lost in ISO paperwork.

I’m curious to know what others think. Have you worked with ISO 13485 standards before? What has your experience been? Do you think they improve medical device production, or hinder progress?