My Favorite Three Product Experiences in 2016

Let's face it, 2016 has not been the easiest year. I'm writing this day after we lost Princess Leia, and everyone seems ready for the ball to drop in Times Square in a couple days. At least my beloved Cubs ended their long championship drought.

To balance out the negativity, I felt like sharing some positive during the year in the form of some amazing products. These are examples of products that stood out to me as a User Experience specialist. And no, I was not involved with these products in any way (although I wish I was).  

Hala Stand Up Paddle Boards:

Over the summer, I was invited out to do a little Stand Up Paddleboarding (SUP) and quickly realized how much I missed being on the water with a paddle in my hand. I decided I was going to invest in an SUP and get myself on the water as much as possible. I knew I wanted an inflatable board for storage purposes, but I didn't know much else. The local retailer showed me the Hala SUPs, and I immediately fell in love. 

What immediately struck me was the backpack that comes with the board. Most of the other boards come in duffle bags that look like they are difficult to carry around. The Hala SUPs come with a backpack that also has wheels. This allows the paddler to carry it just about anywhere at 20 some pounds, or to drag it through the airport for the epic trip they are about to embark on. The idea of taking the board up to a lake 2 or 3 miles from civilization just triggered my outdoorsy sense of adventure. And what a bonus if I wanted to bring it along on a trip that was a bit too far to drive. 

I can tell you that this SUP got the job done when I went a few miles up a dirt road to a lake in the middle of the San Juan mountains. In just minutes, I was on the water enjoying the solitude. And when it looked like the weather was going to turn, I was packed up within minutes and driving away.

Every time I was on the board this summer, I felt like someone was reading my mind when they designed the board and the backpack. It is easy to tell the product is targeted for that adventurous, loves to travel paddler. The designers at Hala did their homework in understanding their users, and developed a product that I know I will enjoy for many summers. 

Progressive's Mobile App:

One of the low points of 2016 for me was getting rear ended in a car accident in stop and go traffic. Luckily there were no injuries, but it is still a scary experience to be in that situation. As we waited for the patrolman, I started thinking about insurance, getting my car fixed, and what a pain the whole thing was going to be. 

I opened up my Progressive phone application so I could exchange my insurance information with the other driver, when I noticed there was a menu selection to start a claim. Interesting...I could get my accident claim started right there on the side of the road. All I had to do was answer a few easy questions about the accident. Then it allowed me to take pictures of the damage as part of the claim report. I clicked the pics with my phone, and within 5 minutes of opening up the app my claim was submitted. 

Did Progressive have all the information they needed for the claim? No. But they called me the next day to gather what they needed from me. What impressed me was that they kept the questions simple, and it kicked off the whole process with very little thinking on my part. Wondering if my back was okay and if the passengers in the other car were fine was a much larger priority for me than filling out a detailed set of questions about the crash on my phone. 

The application asked for just what was needed in a stressful situation. It did not add any stress to my situation. The fact I was so impressed with the design in that moment should say a lot to group that built and designed just enough and not anything more. 

Barracuda Luggage:

A friend of mine showed me their new Barracuda luggage while in Chicago recently. I was immediately blown away, and was lucky enough that someone checked it off my Christmas wish list. 

This luggage is a travelers dream. Are you tired of searching for a place to plug in your phone at the airport? It comes with a battery pack in the suitcase. Having trouble finding a place to store your luggage? It is collapsable and comes with a bag that you can hang up in your closet. Airline lose your luggage? GPS tracker! And I haven't mentioned the nice, ergonomic handle that makes it a little easier to navigate those tight crowds. 

I can tell someone who has had a lot of headaches while traveling really thought through these problems. It is another example of a product where I feel like someone was in my head and knew exactly what I needed before I realized it. Suddenly, I'm looking forward to traveling more...even if that means more TSA in my life. 

Bottom Line:

The common thing that brought my attention to these three products was how much they grabbed my attention with a great User Experience. It is easy to notice a bad design and complain about a bad product. It is also easy to overlook a good user experience, because it is almost invisible and just fits what someone needs. To feel like someone interviewed me as part of the user research process for their product is a testament to the hard work that had to go into it. 

I'm all about doing my homework when it comes to User Research within UX. I feel like a lot of places are forgetting this or shortcutting this process. So a tip of my hat to these three products that made my 2016 a little better. 

Which Design Tool? Does it matter?

I have already written about the importance of knowing which tool to use in User Experience when discussing Personas. The design process can vary depending on the context of the problem to identify and solve, and it takes a little trial and error to figure out what to use in a specific situation. Lately, I have seen a lot of debate online about which design tools are better:  Axure, Omnigraffle, Balsamiq, the Adobe Suite…even whether or not a designer needs to be proficient in HTML/CSS and JavaScript. 

I believe it is similar to choosing the right tool while doing construction: it really depends on the context of the situation. 

When choosing which design tool is best for you, there are some important questions to consider. Here is a good checklist to get started:

  • What are the goals for this particular project? 
  • How much time is allotted?
  • Who is the audience of this particular design? 
  • Is the purpose to gather feedback on a new concept or usability test a baked out feature? 
  • What is the budget? 

If the need is for a hi-fidelity prototype then take the time to learn Axure or HTML/CSS. Balsamic and Omnigraffle are more than adequate to get wireframes “on paper”. A white board is a fantastic tool to sketch out new ideas in a collaborative space. I personally have had a lot of success designing in Powerpoint - even with interactive click points. With all these options, I wonder if it really matters which design tool is used. 

In my opinion, the most important outcome of a design artifact is that it starts a conversation. Whether it is with your Product Manager to put some visuals around a concept, a detailed design artifact for a User Story that the developers are going to work on, or the end-user who is validating the design through usability testing. All of these scenarios should lead to two conversations 1) whether or not the design is moving in the right direction to solve the problems at hand and 2) how to improve the design to get to the right solution. 

I have to agree with this Tweet from Patrick Neeman (find the tweet) when it comes to this discussion:  


Getting caught up in which design tool is better or if you are using the right one takes away focus on the design and the design process. I would prefer to focus on collaborating with my colleagues to identify and solve the correct problems instead. I enjoy expending my energy on meeting the end users whose lives I am trying improve. 

So if you’re having the right conversations, improving your designs, while meeting the project goals - then you’re probably using the right tool for the job.

What Automobile Technology Evolution has helped me realize about Health IT, UX, and Patient Safety

  My source of inspiration

My source of inspiration

It is amazing (and sometimes scary) what can go through our minds during a solitary drive. While taking a solo road trip through beautiful southern Utah, I starting thinking about cars. I guess it makes sense seeing that I had been in one for hours as I was approaching Bryce Canyon National Park. I felt a lot of appreciation for some of the safety features that I did not have on my previous cars like the rearview camera, proximity sensors for merging, and bluetooth to safely handle incoming phone calls. I was in awe over how much the automobile has really evolved. 

There were already a variety of different steam and gasoline powered cars that had been invented before Henry Ford came along to introduce the fairly affordable Model T in 1908. Those initial Model T’s had no wheel brakes, optional windshield wipers, no radio, all while having a max speed of 45 mph. I’m guessing it was a heck of an upgrade from getting around on horses. 

From a safety perspective, the evolution of the automobile was fairly slow: seat belts were not a standard feature in any car until Saab did it in 1958. Not that it mattered much since it took nearly another 30 years for them to be required by law in the United States. The progression has seemed to move faster since the first airbags were added in the 1990s. Now we have those cameras and proximity sensors. Human error may be removed completely in the near future since we may not have to even manually drive cars

That is not to say driving a car is still a perfectly safe endeavor. Accidents still happen. Console designs can still use a little work. One of my friends recently shared her story of a near accident while she was changing the internal temperature. Instead of a knob, the control was a button that required more of her attention which was not on that other car on the road. After over 100 years of evolution that has given us some amazing achievements, safe driving technology still has not been perfected. 

This mini-revelation got me thinking about healthcare IT, patient safety, and User Experience. On their own, each of these fields are still relatively new:

  • EMR giant, Epic, was founded in 1979. 
  • The first book on usability that I ever read was Jakob’s Nielsen’s “Usability Engineering”, which was first released in 1993. Don Norman’s “The Design of Everyday Things” was published 7 years earlier. 
  • The infamous "To Err is Human: Building a Safer Health System” report that launched numerous patient safety research initiatives just turned 15 last year. 
  • And the stimulus package that created the Meaningful Use initiative and boosted the Health IT world was passed in 2008. Which is around the same time I first heard the term “user experience”. 

I have been working in the unique crossroads of Health IT, Patient Safety, and UX for over 10 years. It has certainly been a chaotic ride. I have often wondered how many more stories from clinicians about the poor usability of their software that I can stomach to hear. How much longer can I continue to beat my head against the wall as I see designs cut down due to technical and business constraints. How much more finger pointing between clinicians, hospitals, and vendors will continue on as the patients have little say on the situation. 

The reality is: These are still young fields, and I have been living in their adolescent phases. Of course it is chaotic. Of course there are complaints about HIT usability. Of course the culture change that has to follow rapid technology advances feels like it is moving like a glacier. If 100 years of automobile evolution hasn’t made driving a perfectly safe endeavor, how is it possible we have made Health IT perfectly safe and usable in 20-30 years? 

Looking at the big picture, amazing steps have been taken in these last 10 years. I am so much more efficient at wireframe design and recording usability tasks because of the tools now available to me. There are companies with Chief Experience Officers. There are many new organizations that are focused on patient safety initiatives and health IT improvements. The occurrence of ICU blood stream infections has decreased. Good user-centered design practices are no longer a nice to have in healthcare, but have become a competitive necessity. If you like to follow the money - over $4 billion was invested in digital health start ups last year! And frankly, my Twitter feed is overwhelming most days when I look at the amount of information that is available to me in just seconds. 

I guess if I took anything away from my road trip, it’s that I need to not be so frustrated that the junction of health IT, UX, and patient safety are not in this ideal place where I want it to be. We have come a long way, but there is a lot more work to be done. All of us - clinicians, health systems, vendors, designers, developers, etc - have to work together to evolve our fields in the right direction. Just the fact that the AMA is asking the ONC to change EHR certification to focus on “usability, interoperability, and safety” shows me that we are indeed continuing to evolve. So let’s roll up our sleeves, stop pointing fingers, focus on the patients that need our help, and go build great healthcare products!

I am really excited to see where this evolution will bring us in ten years…

Do Your Users Trust Your Software?

I always enjoy the opportunity to pick the brain of a healthcare provider and get their perspective on all things Health IT. I received a bit of enlightenment in a recent conversation with a clinical informaticist. We discussed Meaningful Use, interoperability, “big data”, and other topics that are creating a buzz in healthcare. Our conversation eventually moved to User Experience, and I was pleased to hear he is a big fan and supporter of UX. As we discussed the importance of building usable software, he made an interesting statement (which I’ll paraphrase): 

“All those nice designs and patterns don’t matter if the clinicians don’t trust the data in the system.”

The statement was focused on the importance of data integration and interoperability. But the word “trust” really caught my attention, causing me to pause and reflect. Building trust has always been in the back of my mind when I’m designing, but it is easy to forget about it during the daily grind of throwing together wireframes, gathering design feedback, and working with development teams. The problem of the day can narrow focus to the point where I’m looking at a single leaf in the forest. This was a reminder of one of the necessary goals in providing a solid user experience solution. 

Building trust in software is especially important in healthcare. As I learned through many early career interviews with anesthesiologists, healthcare providers do not want to deal with a “black box” when it comes to technology: “Why is the system alarming?” “What is wrong with my patient?” “Is your system giving me the right information I need?” There is already enough stress in providing proper care. The last thing they need is to question whether their software is providing the right information in the right context. 

The bottom line is no matter what the application does, how many features it has, and how “nice” and well designed it looks: if the users cannot build trust with the system they will not use it.

There are no shortcuts in establishing trust. It is something that needs to be prioritized in the design process. I believe a key factor is to focus on the initial intuitiveness of the application to help make a good first impression. Eventually, steps have to be taken to maintain that trust over time. 

Here are some suggestions on how to go about building up that trust:

  • Do your research: I bring this up all the time when discussing UX. Without doing the proper user research, you will not be able to identify where users may be having issues trusting your application. Do not design in a vacuum. While you are researching:
    • Run “hallway tests”: Grab a co-worker (or neighbor, or friend, or family member…anyone really) and have them look at your low-fidelity design. Do they know what they are looking at? Can they figure out what to do? If not - time for some rapid design iterations before grabbing the next unsuspecting test subject.
    • Test with new users: First impressions go a long way, and users that are new and unfamiliar to your system are ideal to test how intuitive an application is. New users should be able to navigate and work their way through a well-designed, intuitive application with very little problems. Some errors may initially be expected if the software is particularly complex, but you should observe those errors occurring less and less. If they are still struggling after the second or third task in a usability test, then it may be time to go back to the drawing board. 
  • Provide guidance: Sometimes the task at hand is going to be a little too complex to accomplish without a little help. Great software will provide well placed help text, tutorials, or other guides to help the user navigate through successfully. One of my favorite guides are the videos on my Macbook that show me how to use the trackpad for tasks like bringing up Mission Control and Launchpad. I recommend working closely with whoever is writing up the product documentation to brainstorm creative ways to help users learn the system. 
  • Follow up: Not only do you have to make a good first impression, but you have to keep working and improving to maintain the trust that was gained. Go back and follow up with users that have evaluated your designs. Hopefully the latest application updates addressed the issues they had, and you will be having much happier conversations. Follow up discussions are always a great chance to find new improvement opportunities. But this is also important in order to establish a personal rapport. Users appreciate this attention and knowing that you care about their experience.

Following a good user-centered design process and having empathy for users will naturally make these suggestions much easier to accomplish. I think the effort is worth it - I would much rather have people using the products I have helped design.

My Favorite UX Tool

I have enjoyed watching the maturity of the UX field over the years. When I went from curious observer to Usability Engineer, the only tools I had were PowerPoint for design and a Usability Study template to test those designs. Over ten years later there are a wealth of applications and research techniques available in the UX Designer’s toolbox. As exciting as it is to see this growth, it can be be overwhelming as well. Like a plumber or carpenter, it takes years of practice to know what to grab out of the toolbox for the task at hand. Through my years of experience I have found my favorite to pull out of the UX toolbox are Personas. 

It may seem interesting to some that I would pick a deliverable which causes debate on how much value it truly adds. I believe when created well and utilized appropriately, Personas are a key factor to building a successful User Centered Design process. In a way, it is logical: Personas are representations of actual users. And User Centered Design is…well, design that is centered around the users and their needs. 

I have had a lot of success using Personas as a way to train my teammates on our users. When I present a new one to my teammates, I make sure I explain who provided the inspiration behind them. Their goals, their frustrations, and why they are using our product are all highlighted. A well presented Persona can save everyone a lot of tedious usability study recordings, and yet still get a feel for what makes the users tick. 

Not only are Personas great for raising user awareness on the development team, but I have seen them used successfully in other departments. Service and Support managers utilize Personas I have written as part of their new employee training. One of the coolest and most bizarre moments of my career was watching a Product Manager put on a wig and act like one of our Personas as part of a Sales Training course (he nailed it). Admittedly, watching one of our salesmen sweat during this exercise while painfully losing "the deal" with one of our more sassy Personas was kind of fun. 

I am not going to spend a lot of time on the basics of writing Personas. There are plenty of templates out there that serve as a good starting point (just Google Persona templates). I will provide 4 tips on how to make your Personas great:

Make sure your Personas are based on people you have met:

This may seem obvious, but it can be obvious when a Persona is based on assumptions and second hand information. Using only secondary research and assumptions will lead to a generalized Persona that is hard to relate too. A big part of the reason to use Personas is to help the team identify and empathize with the users. There is no need to make the difficult climb to a User Centered Design environment that much harder. It is also difficult to identify and prioritize user needs around a Persona that is too general. Generalized Personas are usually a sign of a lack of focus on priorities. 

Get out there and talk to the people living and breathing your product on a day to day basis. I actually believe you can create a great Persona just talking to 1 or 2 people. Some will say you need to talk to 5-7 people, but I would suggest creating a second Persona so you can capture some of the differences in personalities of your user base. Face to face interviews are ideal, because it is easier to pick up on the personality quirks that make each and every one of us unique…and thus making your Personas unique. 

Capture the Emotions:

To quote Amy Cueva, “Emotions matter”. None of us are robots, and neither are any of your users. (Although, it might be cool if we re-check this statement in about 10-20 years.) Sticking to the facts about a job does not really capture the reality of the situation. People get frustrated when things do not work well, and get a great feeling of satisfaction when they accomplish a difficult task. Avoiding the negative emotions and finding ways to trigger the positive emotions are part of the goal of good Experience Design. 

Capture these emotions as part of the Persona write up. Tie them to their work goals. Write a narrative about their daily life. What makes this person get out of bed in the morning? What are their aspirations? How can the experience you are designing make their day better? A great story captures the attention of your audience and helps get better buy in for a design. The most powerful healthcare presentations I have attended usually involve a story of how a medical error damaged someone’s life. 

Now you have some Experience Goals to focus on along with your prioritized user needs.

Do not let your Personas get stale:

People change and so should Personas. As a product matures and changes, so will the use of the product. A mistake I have made is putting up Persona posters in my office, and then leaving them there. If it appears that I forgot that I put them there, why should I have expected my teammates to remember them as well?

Ideally, Personas are called out in requirements and user stories so they cannot be forgotten. Regular check-ins with teammates to make sure they understand which users and their needs they are addressing helps as well. I recently started writing, “what am I thinking today” thoughts for my Personas as a way to share recent feedback from User Research Interviews. If you have a Persona named Beth, then start a “WWBD” campaign to raise awareness. 

Personas are not a Primary Research replacement:

The interviews have been conducted, the Personas are written, and the development team is buying into them. No need to keep up the User Research, right? Wrong! User Research never stops, and nothing can replace the power of interacting directly with your users. The market is always changing, meaning the goals of your users are probably evolving as well. Getting complacent can cause a big miss in learning about new user needs and requirements. Get out of the office!

In Conclusion:

Following these steps can help create a very powerful tool to pull out of the UX toolbox. My favorite aspect of Personas: they are a great empathy builder. Telling a good story, capturing emotions, and even role playing have made this a very fun way to help my teammates realize there are real people out there relying on us. And ultimately for UX, it is about the people we’re designing for.

The Ebola Miss: A System Breakdown

Unless you have been living under a rock, you probably have noticed there has been some panic over the ebola virus making its way to the US recently. One of the major aspects of of the coverage has been around the case of Thomas Duncan, the patient who died from ebola after the ER initially missed the diagnosis. 

Naturally, there has been a lot of blame going around on how such a thing could be missed. What intrigued me was the initial statement from Texas Health Presbyterian Hospital Dallas blamed their EMR for the miss, and then the statement was retracted days later.  The follow up statement from EPIC saying there is “no flaw” in their system has caused strong reactions, ranging from scathing to defensive to general eye rolling within the Health IT community. 

It is no secret that there is a lot of dissatisfaction with EMRs and Health IT in general. I have already written about the AMA jumping in with their recommendations to improve EHR usability. To add to this, a new report is indicating that nurse satisfaction with EMRs has hit a new low. Through my many years as a UX designer in healthcare, I have personally heard all kinds of horror stories of poor EMR design. These problems make it is very easy to point the finger at the EMR vendors. The reality is, poorly designed health IT systems are just part of the problem. 

Healthcare is a system: it consists of various clinicians with various specialities, working together in high stress environments, using different tools and technology (including EMRs), with different rules, regulations, and reimbursement policies hanging over their heads. Oh yeah, and the most important piece at the center of all of this is the patient needing treatment. The University of Wisconsin SEIPS model provides an easy way to see the complexities of a healthcare system.

Let’s look at the Environment piece of the situation. The ER is an overwhelming place to work. A patient with a fever is not going to stand out in such a crazed environment where mistakes can easily be made. Add the cultural aspect where doctors are trained not to assume rare diseases and “look for zebras”. Let’s be fair - when have we ever discussed the issue of ebola in the US before this (and no, the movie “Outbreak” doesn’t count.) These factors were just part of the systemic error that caused the ebola miss. 

Vamsi Aribindi explains the systemic breakdown of the situation very well. He points out four (not one) errors that led to Mr. Duncan being sent back home when he should have been immediately admitted. A lying patient, missed communication, a crazed environment, and a key piece of information not on the physician screen of the EMR were all holes in the swiss cheese

What bothers me about the situation is that there continues to be a blame culture in healthcare after years of Patient Safety research have shown errors such as this are to system breakdowns. There is usually not “one throat to choke”. I realize that pointing blame is basic human nature, but the discussion should initially start at how can we avoid this from ever happening again. Once the appropriate investigations are done, the key lessons need to be shared for the entire healthcare system to benefit. 

It is important to remember EMRs are just a tool in the healthcare system meant to treat patients. Many have treated EMRs and technology in general as a “silver bullet”. Unfortunately, silver bullets rarely fix big systemic issues, especially when they have their own set of flaws. 


Prioritize Design with Principles

In the world of software things rarely work out in an ideal fashion. This is especially true when operating as a UX “army of one”. My experience as the lone UX Designer has taught me that I cannot accomplish everything UX in the same manner as I did when I was part of a great design team. User Research reports turn into executive summaries, fewer design concepts get developed, and other UX deliverables become nice to haves that just don’t happen. Through the frustrations I have learned the importance of prioritization and focus. 

One of those UX deliverables that becomes a nice to have is a UI Design Pattern Library. Design Pattern Libraries are a great tool to promote consistency across a product or an enterprise of products. When done well it can lead to a smoother, easier to learn user experience. However, they take a very long time to develop making it very hard for one UX designer to give it the focus it needs. 

I was glad to see Peter Hornsby’s recent UX Matters article on using Design Principles over standards and patterns. Not only is creating a Pattern Library a lot of effort, but I have to agree that patterns can lock designers and developers into the way things have always been done. I believe that User Experience is a group activity. Which is why I like to encourage developers to challenge my designs, and find ways to deliver the best possible user experience within our technical constraints.

Design Principles create a foundation for the open ended discussion that pushes for a better experience. They become a guide during design reviews. When tied to specific emotions, they can help build empathy for the users within the team. And ultimately, they can help create a desirable design culture.

Here are a few simple design principles that I particularly like to live by. These are inspired by Lean UX principles, the HIMSS elements of a usable EMR, and over 10 years of design experience:

  • Safety First: This one is the most important principle in the healthcare domain, as patient lives are at stake when software or a medical device is not run properly. Design solutions need to make sure we protect our users from causing themselves or others harm. It should be hard to make errors, yet easy to recover from them.
  • Know who you are designing for - This is one of my favorites as it focuses on the importance of User Research. Know the personas, their goals, their workflow, and have empathy for the roadblocks they come across. 
  • Build what is relevant – A good design solution solves a specific problem or problems that have been well researched. Do not build “cool” features that do not solve an actual problem - that seems to only work for Apple and social media applications. This principle goes hand in hand with keeping the designs simple so as to not overwhelm users with information overload
  • Prioritize! – Once you know what is relevant, focus on the primary tasks and the important data needed to complete those tasks. Make the most critical data easy to see and access, and show anything secondary elsewhere to reduce clutter. This is another principle that relies heavily on solid User Research and keeping designs simple. 

This is by no means a complete list. These principles are some of my favorites that I work with to deliver usable designs. I like to keep them simple, sweet, and easy to explain. I also make them easy to see by placing the list in places where the development teams have their meetings. 

Bottom line - a solid set of principles are very important tool in the UX toolbox, especially for the lone UX designer.

AMA Makes Usability Recommendations

It is no secret that the usability of many healthcare IT systems are subpar and causing a lot of users headaches and anxiety. This is especially true with EMR systems. For years, I have heard complaints first hand from nurses and pharmacists about how much extra work it takes to navigate these systems. It seems an even larger voice is speaking up about it: doctors. 

The American Medical Association (AMA) caught my attention recently when they released a framework for their top 8 usability priorities for EHR usability. This is coming not long after a RAND report showed increased physician dissatisfaction with EHRs, and a lot of talk about health organizations wanting to switch vendors

The 8 recommended ares of improvement listed are (view the full report here): 

  • Enhance physician's ability to provide high-quality patient care
  • Support team-based care
  •  Promote care coordination
  • Offer product modularity and configurability
  • Reduce cognitive workload
  • Promote data liquidity
  • Facilitate digital and mobile patient education
  • Expedite user input into product design and post-implementation feedback

Two things caught my attention when I read the report. The first was a strong call for better User Research from the vendors. In order to reduce cognitive workload and enhancethe ability to provide high-quality care, there needs to be a real understanding of the clinical workflows that need to be supported. The AMA specifically calls out bringing user input in the product design lifecycle - that is a recommendation for User Centered Design. UX Researchers everywhere rejoice! 

The other item that caught my attention was the item on product modularity and configurability. In other words, we need better interoperability between systems. This is a hot topic of discussion in the Health IT world right now. The reality is, not one piece of technology can do it all well. AMA President-elect Steven J. Stack, M.D states this nicely: 

 “Now is the time to recognize that requiring electronic health records to be all things to all people - regulators, payers, auditors and lawyers - diminishes the ability of the technology to perform the most critical function - helping physicians care for their patients,”

For a while it seemed usability was just checking a box or a competitive differentiator in healthcare. But there has been a push to improve health IT usability coming from the ONC and NIST standards. The AMA has a lot of influence, and now they have evidence to show this needs to be addressed. In my opinion, the AMA report is a signal that we have reached the point where good health IT usability is an expectation.

I’m glad to see this tipping point has been reached. What concerns me is how the industry is going to overcome years of technical debt to really provide usable, streamlined clinical solutions to all caregivers. It appears to be time for third party Health IT vendors to shine.

Building Empathy to Reduce Load Times

I don’t think anyone would debate with me that we live in an inpatient, instant gratification society. Technology has come such a long way that we get frustrated whenever something requires waiting. One of my favorite comedians, Louis CK, hilariously explains it: 

I will admit, a few extra seconds to wait for my fantasy football team to come up on my phone is really not the end of the world. But there is evidence that slow load times to access a site or application can lead to a poor experience. This slowness can cause someone to give up, leading to a lost sale on a retail site. In healthcare, this could mean less time a physician is focused on a patient during a visit or a pharmacist reviews fewer potential medication interventions during a day

Improving application performance and load times usually means tackling technical debt, which tends to be pushed backwards in product priority. So how does one go about showing the importance of fixing these issues? 

Make the product managers, developers, analysts, and testers really feel the pain to raise the level of empathy for the users. I have tried a little activity to help show the pain caused by slow load times. I call it the “Stop Watch Game”:

I presented a few colleagues a user scenario that involved running a search. I started simple: assume you are one of our users, and you need to create a list of patients on a specific medication in your facility. I instructed them to imagine they have pushed the Run/Load button when I say “go”. They wait and tell me when they would expect the result to load by saying “stop”. This was not done with the application up and running - just hypothetical. Using the stop watch on my phone, I timed the “go” and “stop” commands. My colleagues typically would let the simple queries only go between one and two seconds. I informed them of the reality by starting the stop watch, saying “go”, and then letting the clock run until the real average load time on our application came across. 

I could start to see the awareness by their impatience during that second round of this game. This exercise was even more powerful when I presented a search scenario involving a complex report where load times are naturally going to be longer. Once again, they expected quicker load times then the current reality. The Nielsen/Norman article states that at 10 seconds the user will get distracted and want to move onto other things. So naturally, I said “go” and made everyone sit there for 10 seconds. Talk about a fidgety group. I finally asked the group if they thought that maximum allowable load time was really good enough. 

I’ll admit a couple things: this really isn’t a very fun “game”, and there are other ways to build empathy for users in UX. Ideally, I would have everyone sit in on my usability studies and listen directly to the feedback from our users. Outside of how uncomfortable it would be to have 10 people watch you do your job, the reality is not everyone outside of UX has the time for observing that many studies. Sharing the results and videos from a study can also help, but I have found that is not as engaging as seeing it real time. 

I did the “Stop Watch Game” in a requirements meeting when acceptable load times for a feature became the topic of discussion. At the end of the meeting I had buy in from the team that they would include appropriate, yet realistic load times in the acceptance criteria and they would test to the metrics. I was able to sell the importance of taking on some technical debt in 10 minutes, without having to show videos of inpatient users. 

I like to call activities like this “empathy builders”. Building empathy with colleagues is such an important part of the User Experience process. I have found sharing the pain users have with not so usable software seems to resonate with colleagues more than metrics and usability requirements. 

If playing with a stop watch for 10 minutes is a way to build that empathy to improve the usability  of a product…then I’ll take it.

The Best Career Advice I Recieved

I was recently asked by a friend what was the best advice I have received in my healthcare career. My first thought was “wow, that’s a tough question!” As I was racking my brain, I could have come up with something cliche like “be passionate about what you do” or “be comfortable saying you don’t have the answer”. As I was cycling through my brain, I suddenly flashed back to an early point in my career:

“If you don’t spend time in their environment, how will you know how users really use your product?”

To give some context, I was very new to the world of User Interface design and was the lead Usability Engineer for a critical care ventilator. I was working with designs coming from the anesthesia device product line to promote consistency between the products and to ease the cost of development. The Product Manager shared his Respiratory Therapy experience by sharing the common ventilator settings that needed to be programed. Here is what the RTs do, here is what the other development team is doing, figure out where it goes on the display - no problem! 

But there was a problem: I had never set foot in an ICU. I heard a lot of stories, seen a few pictures, but I was designing off a lot of assumptions and from my knowledge of observing a few surgeries in the OR. Enter Terri, a former ICU nurse and great colleague and friend of mine that felt the need to not so gently guide me on the right path. I honestly can’t remember if those were her exact words, but the message rang clear. I was never going to make the best design decisions if I didn’t get a chance to observe the messy, real world environment of the ICU. It was an easier said than done solution, since most hospitals prefer that some random guy does not just walk into an ICU.  

My opportunity finally came through the unfortunate admission of my grandmother into the ICU. 50 plus years of smoking, high cholesterol, and COPD will usually require the need to be placed on a ventilator. It was an emotionally difficult time, filled with potential end of life care discussions. Since she was expectedly anxious, I decided to help the family out by spending a couple nights in the room with my grandmother. 

It ended up being a learning experience as I was immersed into the day to day life in the critical care environment. I was able to observe clinician interactions with my grandmother and the equipment in her room. Some things I noticed included:

  • Her ventilator was tucked into a corner, behind a lot of other equipment. I think I saw it touched once in 2 days. 
  • The nurses usually came in the room, checked my grandmother, checked her vitals, and looked at the IV pumps before leaving the room. They usually didn’t glance at the ventilator.  
  • If my grandmother coughed and trigged the high pressure alarm, no one came running in a panic…in fact usually no one came in. Alert fatigue is a real thing. 
  • A Respiratory Therapist would come in every few hours for a nebulizer treatment. They would check the ventilator, but hardly needed to adjust anything. 

Before this, I was designing under the assumption that the ventilator was under constant supervision, like an anesthesia machine. This was hardly the case. The ventilator was a life support tool that rarely needed to be adjusted compared to the IV pumps, catheters, and other equipment keeping my grandmother alive. You set it up, might make an occasional adjustment, and you just expected it to work. 

After that experience, I remember coming back to work and saying “I get it now, I really get it” to Terri. I understood the environment and each clinicians interactions within that environment. I saw how busy and overwhelmed the clinical staff was. I finally realized that what I was designing was a piece of a much bigger clinical puzzle to care for a patient. 

In the product development world, it is easy to have such a strong focus on the product that it is designed as if it is the most important part of someone’s day. The reality is, most of us are designing products that are just a tool…and may not be looked at for more than a few minutes over the course of the day. In healthcare, the patients really are the most important piece of that puzzle, not the technology. This is just one reason why User Research is so important in the development lifestyle. Good User Research shows the reality of the problems in a work environment allowing for smarter, more informed design solutions. 

I have had a few of these reality checks in my career (here’s another great exmaple). I would like to think these experiences have made me a much better UX designer as a result.

Just remember: “If you don’t spend time in their environment, how will you know how users really use your product?”