Plot 47A

by Cassie McDaniel

mcdaniel-plot47a
May 18, 2013

Getting a new name

I needed a new name for this blog once I knew it would no longer be about designing healthcare. “Plot 47a” sounds a bit like a graveyard plot, but it is actually the section of a community garden that my husband and I had when we lived in Surrey a few years ago (our allotment). We were 24 years old, pulling up weeds and watering the raspberry bushes every other day after work. Most of our friends lived in London, spending evenings in the pub. We did plenty of that too, but we are still romantic about our garden and the handfuls of strawberries, green beans and potatoes we got from it. It was something Mark and I built together that was completely different from the websites we built together at work. The garden certainly lasted longer than some of those websites.

Gradually, Mark and I began pushing harder in our careers until we were spending all our evenings coding and designing. New opportunities came for us to work on projects outside of work, and as those opportunities became more exciting and more lucrative, they were harder to turn down. A couple grand here and there paid for travel to see our families in Florida, Luxembourg and England. We weren’t making anything more than a few thousand, and we weren’t doing it solely for the money. We felt lucky that people wanted to work with us, and it was a chance to take the kinds of risks that were harder to do in our day jobs.

The other thing is that we were supposed to be doing as much work as possible in order to be great, advice I’ve heard from industry heroes over and over again. Working evenings and weekends on side projects or even work-work projects is the accepted standard in this industry. If you aren’t doing that, it’s easy to feel like you  aren’t at the top of your game. But there’s another side to this I haven’t seen until recently: Working really really really hard outside of hours – with sleepless nights, poor nutrition, slouching in desk chairs – maybe that is the way to get something started, but it certainly isn’t the way to keep it going. It isn’t sustainable.

For me, when I step back, a lot of the work I have done is so ethereal; I’m lucky if what I build lasts a year. And that is part of what makes it seem less and less worthwhile to spend more than my forty hours a week on digital doings. If I could take back some of those evenings I spent hunched over a computer and instead build a sheet fort with my nephews and read stories by flashlight, or watch a really inspiring, artistic film, or sit on the roof and look at the moon – those memories may not last long either, but at least it’s an investment with an outcome I know. I believe those memories contribute to a much richer life than a harddrive full of projects no one will look at or care about in a year or two. There needs to be time for play. For movies. For going for walks in the hail and cherry blossoms. For sewing projects. For paintings. For theatre. For friends and family. These are all things I have sacrificed time toward because I wanted to be a “good” designer.

It’s not that I regret my hard work, but lately I’ve been questioning the proportionality of it. The truth is, I’ll never be as good a designer as I would love to be, no matter how many hours outside of work I put into it, and I’m probably already as good as I need to be. That doesn’t mean I work any less hard, but I’m beginning to feel that my work is more concentrated, more focused, more deliberate. I feel like that should have been the goal all along: Quality over quantity. This is arguably a difficult strategy to take when you’re young and feel like everything you produce is crap, when you just keep making in hopes that something good will come of it. I guess that does happen eventually, but I hope the natural progression is toward a point where young designers can stop, reassess, and make sure they’re still doing the thing they love and loving the things they do. This is what I aim to do now.

All this said, I currently do work more than my forty hours a week, but I hope to get to a point where I can gradually stop coming in early and staying late and be strict with myself about how I divide my time between the things I value: yes, I need to do a good job at my work, I need my life to have some value beyond consuming, but it’s also super important to me to be a good partner, a good friend, daughter, sister, cousin, niece and an overall creative, well-rounded person. How can I be that if I spend all my time at the computer?

These are just a few thoughts to justify why Mark and I are giving up freelance, at least while we have full-time jobs. It’s almost crazy that I feel we have to justify it. We’ve been closing off projects and telling people we’re not taking any more work, trying to be strict about saying “No” (it’s really tough!), turning down family members and friends. A couple weeks ago, I finally refunded an initial deposit paid to me two years ago by an incredible client for a project we never really got off the ground.

I’m excited to see what doors this opens for us – not doors to new and better work, but doors to relationships and experiences (which may or may not improve our work). And hopefully, Plot 47a will become a place to document those creative thoughts and ideas, whether work-related or not.

mcdaniel-access
March 19, 2013

Brave New World

O wonder!
How many goodly creatures are there here!
How beauteous mankind is! O brave new world,
That has such people in’t.
—William Shakespeare, The Tempest

I’m a little sad, and a little excited, to share that this is my last week working at the Centre for Global eHealth Innovation on the Human Factors team. I’ll be leaving University Health Network to take up a new design position at Mozilla on their Webmaker team after the first week of April, which is pretty exciting for me! So I’ll be shifting my concentration from healthcare more to education, and I wanted to take a few paragraphs to reflect on my experiences here and where I’m going.

In January I wrote about the Disruptive Incumbent, which may appear to have been the beginning of the end, but in truth I’ve been sitting on this thought ever since I decided I would tackle healthcare design: how much can you change the direction of a heavy machine heading one way, when you desperately want it to go another?

While I believe there must be people working within the healthcare system in order for this system to change, I’ve had to question my own role as an insider. What are my own strengths? Where am I adding value?

Outsider vs. Insider

McDaniel-Outsider-Insider2
When I started I was very much an outsider, completely unfamiliar with the healthcare world. Then and still, I am comfortable with the contrasting laissez faire tech environment, am more used to experimental and sometimes haphazard creative practice, and I realize that through my experience in digital agencies, I often value the speed of innovation and “content” creation over its substance, believing that iterations will lead to incremental, meaningful impact.

To answer my own question, I believe my value at the Centre has been exposure; I have exposed people unfamiliar with design culture to a different way of thinking about problems, to new methods of problem-solving, and hopefully, to new ways of interacting with people that are necessary for great design (e.g., openness and forthrightness when it comes to critiques, quick iterations without hurt feelings, sharing of specialized knowledge and resources, and the idea that design is not magic – it is a process). I’m not just talking about the Centre, but also about new people I’ve met through this blog, through Twitter, and through community health events including Hacking Health. All of this exposure has built real value by contributing (even in some small way) to a culture change within healthcare.

At the same time, my projects, colleagues, and working environment have most definitely changed me: I am more cognizant of creating work that will have a real impact. I want to be able to measure that impact. I now think thoughtfully about potential harm my work may be inflicting upon users. These are not easy subjects to wrangle, so to have developed the skills and resources to cope with them over the course of one short year and a half is a huge advantage to me as a designer.

I have also been exposed to areas of design work I would never have come in contact with otherwise. I have watched users fiddle with my interfaces through a one-way mirror, watched patients enter an MRI machine, heard people well-versed in healthcare traverse this delicate landscape of healthcare politics, choosing which of their battles to fight. Even sitting side by side with a talented industrial designer and mentoring younger design interns straight out of school has taught me a lot about myself and how I work. It’s also been enlightening to face the challenge of encouraging other designers to join the healthcare cause, and to those who have stepped up: Keep at it. You continue to inspire me.

These challenges-slash-opportunities are often missing in your standard design briefs at your standard design agencies, and I feel lucky to know now that designers can deeply understand a complex problem, and we can influence complex processes.

I strongly believe this ability to affect change does not apply solely to designers. Anyone with insight that is willing to speak up – and sometimes fight for their beliefs – will be able to influence their environment. I hope that part of what I’ve been able to accomplish at the Centre is to have enabled the sharing of those insights as well as the ability to trust an insight without necessarily knowing where it came from. While design is a process, and its techniques can definitely be learned, the unstructured component of creative thinking (aka “play”) is also really important to anyone interested in doing things a little differently.

What’s next?

It’s the element of “play” that I want to focus on a bit more. I’m excited about shifting scenery and going to work for Mozilla’s Webmaker team, where I can help shape the vision for and build tools for people to play with content on the web.

A few weeks ago I saw Mark Surman speak about the Mozilla mission at Creative Mornings, and I was completely captivated. The Mozilla mission is to encourage web literacy, or the ability to understand how the web works, in order for users to be able to contribute to it in a creative way as opposed to simply consuming. I identify with the belief that the web should be able to be influenced by individuals who take part in it. This is, after all, what made me fall in love with interactive design in the first place. And not without irony, this “enabling” is very much how I felt about healthcare, too. How do we enable patients to become participants in their own care?

Also not unlike healthcare, part of my role as a user experience designer at Mozilla will be to think about what motivates certain behaviours and to imagine how we can create tools that makes those behaviours easier to accomplish or more desirable.

What will be changing, however, or at least what I imagine will change, will be that I won’t be facing the crazy inertia of a huge, complex system like healthcare that is – often rightly so – terrified of making mistakes. Education and the tech world are certainly still big industries to reckon with and are wrought with problems of their own, but in these worlds the individual consumer is granted more access, the importance of which I cannot stress enough.

Access

McDaniel-Access
Access allows people to be a part of something, to potentially change it because they are a part of it. I was lucky to have been given access to the health environment not knowing anything about it, but I know too many businesses that would love to work in healthcare and don’t know where to start. Their ability to access current work-streams, the hospital environment, and patients and doctors is extremely limited. Until that changes, I am not convinced healthcare will experience the benefits of a competitive and creative tech scene.

In tech companies, the sometimes fierce loyalty to openness and sharing has – I think – made strides for advancement easier to accomplish. (Granted, the opposite to openness, à la Apple, has also taken us places, but I’m not sure to good ones!) I’m impressed with the openness of Mozilla. For example, the Webmaker team has weekly phone calls  that any member of the public can join. Can you imagine this existing in healthcare?

It isn’t easy to maintain openness in the face of growth; we tend to have the natural desire to lock down whatever it was we feel made us successful, so that we can stay on top, right? But I really love that the value system of openness is baked into the culture at Mozilla, and I’m excited about what this means for my own potential as a designer to impact the world around me.

In the meantime, Healthcare Human Factors is still going to be doing some of the best work around in healthcare. I’ll still send anyone I know to their doorstep. They still have a crackin’ team of designers with communication, graphic, and engineering backgrounds, so I’m definitely going to keep tabs on them to see what they’re creating.

Sharing everything

It is in the spirit of openness that I want to share everything I’ve learned about building a creative team inside a hospital at Healthcare Experience Design Conference in Boston next Monday. I’m considering it my last hurrah in healthcare, at least for awhile! Do come out and hear what I have to say, and we can argue and debate about it afterward.

By the way, I’ll be keeping this blog, but will probably rename it eventually. Everything I’ve written about my journey in healthcare will still be here for others who want to take the dive and who want an excerpt of challenges they may face in this brave new world – and to those designers, I say you should definitely do it, the experience is worth it.

mcdaniel-disruption
January 17, 2013

Disruptive Incumbent

“You can’t create a disruptive business inside an incumbent business.”

Jon Lax wrote an insightful post about a month ago that I haven’t stopped thinking about since. Teehan+Lax have a “zombie product” they named Image Spark, an image collection service similar to Pinterest (but born way earlier). The service, with 90k unique visits, is not exactly dead, yet it is not alive either; there are no updates planned, no person driving it forward, no future plans. Teehan+Lax has decided to give up the ghost on this one for lack of infrastructure (and will) to sustain and nurture the product.

What interested me was something Jon wrote in the comments. “The issue isn’t having interesting problems to work on. We have a long list of ideas. It’s that you can’t create a disruptive business inside an incumbent business. Any idea will flounder without proper focus and a 3-4 year investment timeline.” Lax goes on to cite Basecamp as a successful product for 37Signals, which “got the resources (capital and human) it needed because it fueled the incumbent services business of 37Signals. It was able to take root because it wasn’t disruptive but highly complementary.”

So what I gather is that to succeed, a product needs:

  • 3-4 year investment timeline
  • focus, human resources, and capital
  • freedom from OR complementary services to an incumbent business

The last point especially made me think about initiatives amongst healthcare organizations. Can a single hospital or a single health startup disrupt the network of archaic but established practices in the health system? Can a department, embedded within a large incumbent organization disrupt the hospital’s own practices? Can an individual nurse, doctor, or designer disrupt a department? Is it true that only those innovations that complement the existing strengths of a system have a chance of making it?

Designers entering health and startups looking to disrupt healthcare would do well to consider how their skills or their businesses complement existing systems. It is easy to enter a new space thinking your skill or your product is so rare that it must be valuable; it is much more difficult (and humbling) to understand why your role or product wasn’t there already and to imagine what you can do to work within those limitations to still accomplish something meaningful. As ever, it is easier to criticise than to come up with a solution.

This is not to say we should be thinking smaller, but certainly more realistically. It is possible to think big as well as practically. In health, being a visionary doesn’t necessary mean changing everything, not all at once. It means using the resources you have to do the best you can during the time you have. It means knowing when to cut your losses on a project – as Teehan+Lax are doing with Image Spark – or to pony up the resources to keep it moving forward. Otherwise, products and projects become stale and just as useless as if they’d never seen the light of day.

On one final note, disruption is not always the real goal. We hear so much of that word from every  young startup that if we were all successful, our healthcare systems would be even messier, more chaotic and less effective than they are today. Maybe we simply mean to evolve the current technologies – to bring them up to speed, take them up a notch, or to complement them – or to create an environment where innovation can thrive.

I’m going to keep mulling this over, myself. It seems an important distinction. I welcome your thoughts!

mcdaniel-persuasion
January 10, 2013

CreativeMornings Toronto: Dave Meslin’s call to designers

“Designers are more powerful than politicians, lawyers, banks – because you can give a voice to relevant issues.” Dave Meslin

Dave Meslin, a local civic reformer, spoke at CreativeMornings Toronto last month about redesigning city politics to be more inclusive and participatory. He was awesome: He was a comfortable, informed speaker and during the talk he practiced what he preached by being open and inclusive, inviting volunteers to the stage to demonstrate his ranked ballot initiative (RaBIT). He also carried an earnest call to action for a targeted audience; he wanted designers to lend their skills to local causes. “Contact young activists,” he said. “Join an existing group.” He urged designers to go out and find a poster someone designed that looks horrible, tell them it sucks and that you want to help design it better. Why not?

Powerful persuasion

Meslin’s call to designers to lend their design skills to community causes implied designers do this for free outside their fulltime jobs, which is not a particularly uncommon request. I’m not saying this is right or wrong, but it was useful to see how a skillful politician persuades an audience to do something in his favor.

I often think of design as solely a communication medium. Complex and amorphous ideas are whittled into a medium that is concrete, actionable, usually simpler and more digestible. But persuasion, of the same ilk as Meslin’s, is also an important piece and I sometimes forget that. Getting the message across is about getting an audience to understand your particular perspective and then getting them to do something for you. I would argue that being a good designer is probably 75% persuasion.

Creating successful design work can be as much about convincing clients and users, funders, partners, bosses, colleagues and consumers that your work is worth reading, watching or buying as it is about making something that is functionally and aesthetically beautiful. If young designers could master persuasion, they are more than halfway to the ball.

Two kinds

I see persuasion in design broken down into two important techniques. In the first, a designer convinces their audience to open up to a possibility. This is the marketer’s playground – where the initial reaction to a visual is so important. Where the TV watcher doesn’t change the channel. The shopper doesn’t throw away your free giveaway. The web visitor doesn’t click away or get distracted.

The second act of persuasion is closing the possibility. Seems pretty simple, but so many projects miss this vital piece. What do you want people to actually do when they get there? What does Dave Meslin want us designers to do once we trust him? In healthcare, what do we want to happen now that we’ve got people to download our app? The design must convince people that the designer’s vision is worth investing time and energy into.

What does this mean for healthcare?

Dave Meslin skillfully accomplished both techniques above, but it wasn’t obvious to me at first. It wasn’t until I tried relating his call to action back to healthcare that I really saw what he was doing. During the Q&A I asked what challenges designers might expect to face if they joined old guard politics and tried to do things differently. He answered, None – or none other than we might face with our usual clients.

I was satisfied with that answer and leaned back in my chair thinking, Yes, that’s right, it’s not that hard, just do it! But is that the truth? Not really. Designers in politics, like designers in health, have a behemoth old guard to reckon with. You think what Obama’s digital team has done, for example, was easy? It has required an enormous amount of buy-in from the top as well as collaboration from all corners of the US and between many different departments rooted in their old way of doing things. The same is true in healthcare: the value of design can’t be realized without support in the right places.

Meslin’s talk revealed the power of persuasion, of willfully suggesting we forget what is hard about a task and do it anyway because in the end it will make a difference in our lives. This kind of persuasion is something we designers can get better at, particularly if we think hard about what we want our users to do once we’ve convinced them to be interested. Do we suggest they buy our product, join our team, sign up for our event? Do we suggest healthcare providers collaborate better, patients take better care of themselves, or that more people join our cause because it is something worth believing in?

I like that I believe all these are possibilities, and that maybe is the best trick of all. Thank you Dave Meslin for that.

November 20, 2012

Don’t kill a crazy idea before it’s been tested

Ideas that are different will challenge the way things have been done before, and they require courage and hard work to see through to the end

We love to think that designing is as simple as having an idea, sketching it out, putting it in Photoshop to create assets that can be built out into an actual application and handing those assets over to a developer, much like the process here. Those of us in production know it is never that simple; we have stakeholders, colleagues and our own internal demons to wrestle with, not to mention the requisite feedback iterations to ensure designs are translated correctly.

Often, the initial implementation of a design idea does not live up to the vision. The designer must convince their team to keep working on it, keep iterating, keep at it until it meets the goals you set for the project. This persuasion part of process is necessary to all design projects, but it is especially true of any idea that is not replicating what has been done before. Ideas that are different will challenge assumptions or the way things have been done before, and they require courage and hard work to see through to the end.

Years ago I worked on a flash website (remember those?) for the Transformers movie, where the screen was meant to crumple up like a paper ball and “transform” into the next page’s content. Unfortunately we waited too long to resolve how the navigation would work, and by the time it was finished and actually a realistic means of navigation, the rest of the team had moved forward on a different idea.

Something happens in design by committee. Without one person owning the vision, a team will turn vicious on itself, questioning every decision and sometimes – depending on the level of commitment to the project – getting stuck in an iteration loop, never able to actually ship something of significance. (Other times a team will give up and settle for sub-par work. Hard to tell which is worse.)

There is an obvious solution to the challenge of big ideas and lingering doubts: Test it. Get the users in and test the crap out of your crazy ideas.

Recently I saw a human factors colleague present one of my “challenging” designs during a usability test. Although the design was as simple as I could make it, it was still not the expected format, and there were no text descriptions, no animated tutorial, no training whatsoever. And our user? She just got it. Immediately. It made my day to see that this user and I were on the exact same wavelength.

Usability tests can be even more valuable than this, but the lesson to me as a designer is clear: Don’t throw away a big idea because you think it won’t work; you never know when you or your team may be underestimating the end user. Test it. Don’t get stuck in the problematic loop of wondering whether it would make sense to your users. Find out for yourself.

The design advisors table, photo by @mud
November 9, 2012

Building a Hackathon

Volunteers from Nascent, MaRs and the Hacking Health team

I recently reached out to founder Sahadeva Hammari to talk about his tool Collabfinder, which brings people with different skill-sets together to tackle projects, and we ended up having a conversation about starting hackathons. Saha had some questions about my recent experience on the coordination side of Hacking Health, and he was gracious enough to take notes, which I’ve edited and shared here.

Both Collabfinder and hackathons share the common interest of facilitating projects and collaborations, but there is a lot that happens behind the scenes that can remain closed off to participants and other event organizers. With so many hackathons right around the corner here in Toronto (see the bottom of this post), even talk of doing a cancer-themed hackathon, it is definitely a time to share knowledge as well as question the value of these events. As my friend Nadine said today:

“Is it me or does everyone have a hack-athon now? its like un-conferences in 2007.”

Last year I wrote about my experience at Startup Weekend, where I wondered whether we really needed more real estate apps. Despite the pessimism in that post, I was inspired by the Startup Weekend team and appreciate the fact that they work hard to bring people together. I also realize much is up to the individuals for the kinds of projects we choose to work on, but there are certain things we can do as organizers to facilitate meaningful work.

Am happy to share a few more thoughts below.

Saha: How did you get the word out to designers, developers and healthcare experts?

Me: Having a large, existing support network helps (we work in a large hospital and have many contacts in the community). We worked hard to build a core group of interested people and let the message loose on Twitter. The event spread quickly online through social channels.

Who were the mentors involved? What role did they play and how did you find them?

Both designers and clinicians acted as mentors to shepard ideas through product development. We had people familiar with healthcare as well as investors and business experts. They helped during the conference and some continue to have relationships with the hackers after the event is over. One of the valuable moments was during pitch night when one of the mentors stood up afterward and pointed out all the projects already in development in other places that perhaps these entrepreneurs didn’t know about.

How did you find and sell partners on the event? Did they cover the costs?

It was definitely an expensive event as far as grassroots go (in the tens of thousands) but the sponsorship outreach was pretty effective. The other major partners, especially those that helped with overall coordination, seemed to go straight to the Hacking Health founders. They could attach themselves to the cause and it was really for the love of the cause that we all put so many hours in.

How were the hackathon participants involved online before they met one another? How did you encourage them to use the online tools?

For the most part participants didn’t know one another prior to the event (I’m sure there were exceptions to this, relationships and interactions we didn’t see). Healthcare folks posted their project ideas to Sparkboard (a tool built internally by Hacking Health) along with the skills they needed to build those projects. Sparkboard was essential as a guide. Developers and designers could also post small profiles to Sparkboard and describe their skills, but this was less common.

A few weeks prior to the hackathon we also organized a meetup where participants could come ask questions and hear a sample pitch. This was useful to get the conversation started.

Two of our design volunteers, Mona Shah and Joanne Wong, hacking away

How did you facilitate teams coming together to work on ideas? How did that play out? Were there any surprises or things you would change?

Teams had the potential to meet other members at the meetup, but for the most part those who pitched an idea on the first night were responsible for bringing a team together, so that turned into a big networking event. At one point we rang a bell and had those teams already formed move to one side of the room, while those still looking for a team or members moved to the left. It was split pretty evenly.

We considered encouraging people to speak to at least three teams before making a decision to join one, but we had this idea a little too late in the process. Sparkboard was a good tool to build teams even into the first day of the hackathon, which was a little late.

The design advisors table, photo by @mud

I also helped organize a group of designer advisors/mentors there for all the teams to access. There were about twenty-five of us throughout the weekend. This was very popular. Designers embedded deeply into a team still had access to other designers to bounce their ideas off of and get feedback from, something designers don’t often get at a hackathon. And teams without any design resources could use us as well, which was the more common scenario.

Teams recognized the value of having designer mentors and used them. The most successful projects were when designers were involved in the entire process, from stating the problem to helping execute the final solution.

Why did designers have a role as mentors and advisors at the design table, not as full-time team members?

 

Getting designers out to a hackathon is no easy feat, but pitching it as an opportunity to hang out with other designers and be treated as “experts” is pretty effective. That gets them out to the event and once they’re there, they end up having a great time and really getting into the work. Alternatively, if someone is having a bad time, they have the option to come back to the table and work on a different project or have support from peers.

Website designed by @thepeej, built over the weekend

App screens designed by @ghostpressbed

There were also many skill levels amongst designers. Some could assist but weren’t experts. Experts seemed like they could do the most good by being a general resource for other designers and teams, and it helped to have one or two people that could identify the needs within the teams and allocate design resources based on that and our designers’ availabilities.

What kind of post-event management occurred? Did the participants continue building their apps after the event?

The prizes given to attendees and winners were deliberately chosen to help those winners continue the development of their projects (i.e. office space, mentorship, access to funding channels.) We also are planning a follow-up event to support those teams and have more networking. That will be November 30 at MaRs.

How much of the event’s success can we attribute to Canadians being so awesome and nice?

Not much, actually! The fact that the hackathon was about healthcare was a big part of it. Everyone has experience with the healthcare system and knows how much it sucks at times. I also think the fact that the projects were clinician-led helped. This wasn’t just people hacking on whatever, it was teams being able to work with people who could understood the problems from the ground level and could actually take their projects and have an immediate effect on healthcare. One student behind the WoundMeasure app said she would begin using the app they built over the weekend in her clinic the following Monday.

The WoundMeasure logo designed at Hacking Health by @britburger

So, in general, the theme of the hackathon, the online component that got ideas out in the open and made it easier to team up, the pre-hackathon meetup that introduced attendees to the process, and the involvement of designers as advisors and guides were all essential to the success of the hackathon.

Anything else?

I just want to reiterate that one of the clearest things we can do is have a specific reason for why we are hacking. My new buddies JJ and Shaharris are behind Canada’s first AngelHack (in Toronto) and they told me that although they are working with an international brand, they are not getting paid; they are putting in the work of organizing this event to bring exposure to the Toronto startup scene, which is something worth celebrating. I’m certain this is true of most hackathon organizers – we do it because we want to see change.

After Hacking Health, I believe the way to go is to target niche causes and niche populations. This is just one thing we can do to make hackathons fun and useful for everyone, and it may be a reason we are seeing more hackathons popping up around the city.

Some upcoming hackathons in Toronto:

Thanks again Saha for capturing our call!

November 2, 2012

ISO 13485: Healthcare Regulation

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.

Conclusions?

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?

October 18, 2012

Design Team at Hacking Health

We know design is an important piece of the applications we will be building this weekend at Hacking Health. We also know one of the most crucial aspects of great design is iteration, and that it is difficult to create a well-designed application in a weekend without great feedback.

This weekend, we will have a big group of design volunteers on hand to offer teams thoughtful design feedback. We’ll also be offering the teams’ (often lone) designers a chance to hash things out with like-minded folks outside their team, brainstorm ideas when they might be stuck, and share resources or give directions they might have not yet considered. We’ll also be happy to lend a shoulder to cry on when things aren’t going to plan, and start celebratory dance parties for design breakthroughs!

Our volunteers

Our volunteers come from a variety of backgrounds; some will have healthcare experience, others have agency experience, and others are especially adept at iPhone photography. All have worked in a variety of mediums, from wireframing big ideas, to building brands, to creating rich interactive experiences. One of our volunteers is flying all the way from Chicago to offer us her expertise! We also have the support of the talented agency here in Toronto, Nascent Digital.

Here are some things you might use us for:

  • Need an extra eye on that logo? Come get our feedback.
  • Don’t have time to make a logo yourself? Task us with getting you started.
  • Banging your head against a wall trying to figure out a user interface solution? We might have an idea how you can fix it.
  • Don’t have time for image correction? We can probably help.
  • Need some inspiration? We can definitely help.
  • Want to learn new tools or other ways of doing things? Ask us how we might approach it.

How to find us

We will be wearing black “Design Team” T-shirts and have a couple tables you won’t miss even if you tried. We will also be walking around to make sure everyone has what they need design-wise. Be sure to come find us if you have a question or if you just need a little break for creative inspiration.

Online critiques

We realize most teams will be toiling away every second and may not have time for an extended critique session. We also have a vibrant community online of both design and healthcare experts. If you have something you’d like critiqued online and shared with a larger online community, throw it online (you could use cloudapp, LayerVault, or any other photo sharing app). Let us know it’s there by tweeting the hashtag #HHdesign.

Prizes

We want to see well-designed applications as a result of this weekend, and we’ll even be offering a small (but big-hearted) prize for best-designed solution. Don’t hesitate to ask us for help!

If you’re a designer and would like to volunteer your time this weekend (Oct 19-21, 2012), email me or tweet at me.

September 21, 2012

Med 2.0, Sketchnotes and The Embedded Designer

I was so excited to have the opportunity to present some of my thoughts at my very first Medicine 2.0 (held this year at Harvard Medical School) about the culture of healthcare and how that needs to adapt to make room for better design. Five minutes is barely enough time to scratch the surface of such an institutional, widespread issue, but it seemed to strike a chord with the audience and I look forward to follow-up conversations for many months to come.

I was also paying attention to other people’s sessions, believe it or not. Have a scroll around my sketch notes.

The Embedded Designer: The Next Big Step for Healthcare Systems

Here’s the bootleg video of my presentation captured by our charming moderator, Gonzalo Bacigalupe:

My slides:



My abstract

Buy a copy of Distance 2 for the full 5,000 word e-book version of my essay on Embedded Design for five measly bucks or a beautiful print copy for $15.

Shout-outs

Kudos to my colleagues for their important work both creating and presenting at Medicine 2.0.

Very proud to say these are my colleagues.

June 29, 2012

Photocopier Experiments

I haven’t had much time lately, but know that many thoughts and posts are brewing and I can’t wait to finish them. Maybe the long weekend will allow me to get ahead of myself? (Happy Canada Day to my local readers!)

In the meantime, I wanted to share results from my photocopier experiments during my Play Day today. Each last Friday of the month, the Healthcare Human Factors team takes a day to play – to explore, finish, refresh, follow up, and otherwise revitalize our depleted energy. I’d never done photocopier art before, and have always wanted to try it, so thought I’d finally see if I could apply it toward a future poster project.

Although I’m never far from the handmade, this process definitely renewed my interest in the analog. And the truth is, this fuzzy space of creativity is where I think the good ideas are waiting.

You never know where the results of this experiment might show up… I might do some intensive photoshop over top of these flat images; I may add colour; I may use them as textures in totally different illustrations; I may inspire someone; it could end up in our annual report; it could end up on the wall as office art. It could even end up in some shape or form in our next app for chronic disease management.

You never know. That’s one of the things I really love about design. Alas, I also love offices with giant photocopiers and endless scrap paper.

Older Posts