Hospitals are time consuming, stressful for patients and staff, and generally inefficient. One company working to change all that seems to have missed the mark for patient user experience.

The first job of a User Experience (UX) professional is to figure out who the customers are and into which groups they fall. After that identification is made,  the UX professional can separate the groups into those with similar characteristics and start testing. The purpose of testings is to reveal any broad challenges customer are having with the technology and specifically what is preventing them from being able to use a product or feature effectively. Testing consists of asking the user to perform simple tasks.  Take, for example, a movie ticketing website. To properly test that site, a user would be asked to complete one or all of these tasks; perform a search by title or location to find a movie they want to see, find a movie review, or buy a ticket. These tasks,  and many more like them,  are a necessity to understand the usability of a product, website or feature. This understanding helps UX professionals like myself make changes to improve product usability.

The other day I was speaking with a nurse who recounted one of the many reasons she no longer loves the profession she spent years pursuing. I came to understand from her the worst part of nursing is not changing a dressing or the long work hours. The worst part is not being able to connect with her patients. In the case of Michelle, who is deeply empathetic, the realization that her job had become more focused on charting than on activities involving direct patient care was disheartening. Charting is the tedious task a nurse undertakes to keep an accurate record of patient information such as their medical conditions, medication, plans of care and much more. Charts are also vital to keep the hospital running because they serve as an instrument for billing patients and insurance companies.

Michelle told me a story of how the hospital where she works implemented a system of electronic medical records (EMR) called AllScript. AllScript provided hefty tablet computers to her department so the patients can enter their own information upon arrival at the hospital.  Traditionally patients already fill out their paper forms so it seemed as if there would be little difference if the patients used a tablet instead. As it turned out, there was a big difference and it was noticeable as soon as they rolled out the new system. The patients had problems with the small boxes, low visual contrast, unfamiliar interface and more.  The problematic tablets are still in use and rather than streamline an outdated paper-based system,  the tablets have caused so much confusion the nurses now come into the lobby to help the patients fill out the forms. Not only is this inefficient, it also is dangerous.  The patients give the nurses their answers aloud which could lead to patient omissions due to embarrassment, not to mention an obliteration of patient privacy.

One detail we pay attention to in User Experience is a Mental Model. Its origins come from computer science. According to Harvard University professor of Psychology, Susan Carey, in a 1986 journal article she wrote titled,   “Cognitive science and science education”, “A mental model represents a person’s thought process for how something works.”

A simple example is what we’ve noticed with roadway round-a-bouts;  those big round circles used to ease road congestion. Depending on from where you come,  you either expect to yield to people entering the round-a-bout or you expect they will yield to you. Your mental model is shaped by your prior experience or expectations.

In the hospital that switched from a paper-based system to tablets, the Mental Model is that most everyone knows how to use a paper and pencil to fill out forms. The problem comes when you hand them something unfamiliar like a tablet when they expected to use something familiar like pen and paper.

Now, let’s go back to the User Experience professional’s first job, which is to learn who the customers are.  In this particular hospital, a large number of patients use Medicare. Medicare recipients are, in large part, Americans who are 65 or older. One shared characteristic of this user group is that, because of their age, they have had to learn to use computers in their lifetime, rather than being born a digital native. This means that some have had a hard time adapting to technology.

The problems for the patients, staff and hospitals using this system are numerous. This program has added time and stress to an already broken system as well as safety concerns and embarrassment for it’s end-users. Unfortunately, a lack of proper user testing and methodology before product launch leads to failed outcomes like this all the time.

A temptation exists in tech work environments to do your job and only that job without thinking about the entire landscape of the project, or the end-users.
It’s usually not your fault, lot’s of projects get planned from above but the projects vision isn’t communicated well. In fact in most environment it’s not communicated at all.

In most environments web work is task based. Each person is given a piece of the vision puzzle to work on and once your task is complete it gets tossed over the wall to the next team member who takes your piece of the vision puzzle and runs with it.

So what happens when that piece of the puzzle is confusing to the next person? Worse, what if the piece was confusing or communicated poorly to you? It’s like the old game of telephone but the final product here isn’t a badly mangled phrase it’s a product that needs to ship.

If teams don’t communicate well at the outset of a new project the whole program is at risk of failing or falling behind due to the lack of membership.

This is how we run a lean UX process for small “as built” features at Nova Southeastern University where I work.

This is a basic sketch of how we employ a User Centered Design by working one or two sprints ahead of the development team in a “Sprint Zero” approach.

1. Meet with end-users and build user profiles based on the info gathered.
2. Have a stakeholders meeting with the whole team to look at the old “as built” feature. The whole team at Nova includes User Experience User Interface Team, Business Analyst, Project Management, The Developers and anyone else I’ve forgotten. Just invite everyone okay.
3. After the Kickoff we have a post-mortem and sketch out ideas, later I mockup the best of them into clickable wireframes.
4. Test the wireframes with users and make any changes aka iterations.
5. Test the wireframes again, make final iterations.
6. Polish the wireframes into high fidelity mockups (also clickable).
7. Deliver the final assets to a development team and shepherd them through their process.
8. Attend weekly sprint demos making sure the product or feature is being developed as intended.

Working with a strong Business Analyst to build and refine the Business Requirements Document is key to the success of this approach. Yes, the BRD will change as we build and test. Yes, that’s what I said, the BRD is not static. Sorry BA’s, I’m a heretic I know but unless you make updates when you uncover things you didn’t think of in the beginning the process won’t be as successful.

Did I mention invite everyone? You get the picture.

It was the long pause that tipped me off.

My name is Ryan Roy and I’m a User Experience professional, UX for short. People in my field go by a lot of titles, sometimes we’re called UX UI developers other times Visual or Usability Architects even Information Architects. I’ve even seen one gentleman with the title UXDNNG. The whole profession goes by a number of different names that in the end really mean about the same thing.

We speak for the voiceless end-user.

Unfortunately my profession has done a little to educate the masses about what we do and why. For a profession whose member have a mandate to make things clearer and easier for the end-user we’re awfully bad at educating the world about what we do everyday.

“I test web products with customers revealing flaws that prevent ease of use. Then I make improvements and test again, repeating the process until I’ve establish ease of use.”

Have you ever been asked this question?

It’s natural in anything we do to seek an end point, a goal so you know when a jobs done .  Eventually I pick up my car from the shop and it’s fixed. Eventually the contractor  finishes and gives you a final bill. What about your website though? Is a website ever really finished? After calling for additions to their new site, (adding new products, text and upcoming events) my client asked me

“When will my website be done?”

They realized it was becoming a regular expense to make all of these additions. It’s natural to want to look for a definitive answer. We have a beginning, middle and end to most everything we do on a daily basis; so it’s understandable that a client paying for a website to be built would ask when it is going to be done. The answer I give is, “your website is never really done.” Yes, sure there is a “go live” date when the developer pushes your site live and says it’s done (hopefully after a lot of testing ) but that’s just the start of the relationship with your website.

A website is like a car. When you go to the dealer and buy a car it’s unlikely that you would ask,

“When am I going to be done adding gas and oil to this car so that it just runs forever?”

It’s just not going to happen. You put miles on your car and then you change the oil. You get a flat tire and you replace the tire.  You park under a mango tree after a car wash… you go back and get another car wash. It’s true that you can build a website and never make a change to it the same way you could buy a car and never fix the flats, change the oil or wash it, but both your site and your car will eventually break down and become useless.

Yes, the bad news is your site is never really done, but if you take care to keep it current it with small changes and update your content regularly you can get a long life out of your website before it’s time for a redesign. The practice of making small updates is known as “Incremental Change” in the web community, but I like to think of it as a part of regular maintenance.