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.