Why designing for healthcare is the worst in the best way possible

If you’ve been in the design realm for a while, you know that there are three major industries that struggle with innovation: education, government, and healthcare. User experience is rarely even on the radar for these guys.

Have you seen the interface your doctor has to deal with on the daily? It’s something nightmares are made of.

I recently took on a project for a healthcare insurance company with the goal to challenge the idea that the healthcare industry is a forgotten one.

The Project

Initially I was brought on to the project to make their current iOS app look androidy and slap on some OS conventions. The development team was already heads down and making swift progress.

Design had to catch up.

Well…

Being a self proclaimed “User Advocate Maniac” at heart, I couldn’t bring myself to “make it look androidy” and call it good, especially when there was so much room for improvement. As the PO would say: “She swung for the fences.”

What we knew

“Not a lot TBH”

The iOS app was a year old and had one round of user testing when it first came out and from that testing we identified some needed improvements. The current app was 40% native and 60% web views. We had a general idea of age, common devices, and user archetypes, but nothing concrete. We didn’t have access to any analytics other than sessions. My god, I have never yearned for heat mapping so bad in my life.

I needed this to happen

What we didn’t know

“A lot TBH”

We didn’t have our finger on some vital information, such as, our users primary motivation(s) for using the app, user engagement level, under which circumstances was the app used most, or users delights vs frustrations with the current app.

Assumptions

We had to make some assumptions to be able to push forward into the black hole that was our lack of user data. One was that our primary audience used the app on a fairly regular basis, approximately twice a month. We also assumed that we had a relatively evenly divided user market of single vs family group members.

Timeline

Like I said, the dev team had already started, and I’m not talking about just backend set up, they had just about finished styling the log in screen when I began, per the old design. Not to mention we had a testing schedule set for mid-November, just a few short months away.

Wireframes

The initiative was to shoot for the stars but keep our feet in reality, meaning that, we could structure and design as if we could do everything but the dev team would lay down the law at the end of the day.

Side note: As you can imagine, without a lot of data to go off of there was already some hesitations around what design decisions should be made. We implemented best UX practices, conventions and drove decisions based off data when we could.

Everything that was going to be shipped to development was marked for MVP and everything beyond that was marked for 1.5. We weren’t quite confident enough to call it 2.0, and well, it really wasn’t 2.0.

Design chunks

In trying to catch up with the dev team we took an agile approach to getting the job done. We decided to do the individual app features/sections in chunks. Which equated to about 3.5 rounds to get the design out the door.

Note. I have a pet peeve with agile processes, if not planned properly. Designers try and create a system to work with as they flesh out the design, though, without the foresight of the whole product, they run into unforeseen hurdles which forces them to break their own set conventions or revisit them holistically.

I wanted to take the directive of keeping the UI as autonomous as possible from either OS. Thinking many of the changes could be carried to both. This would also eliminate future effort in having a specific design for each. I did a good amount of research to find other apps that take the same initiative or are moving in that direction, some being: Duolingo, Dashlane, Gmail, and Acorns.

Education and the power of pitch

Most of the big wigs in the company weren’t familiar with how Android did things. This was really good, in a way, because it left less room for them to challenge their preferences but it also required more education on my part.

Stakeholder presentation

During the presentation to over 30 people, I strove to educate as to why each of the design decisions were made. Comments came back about business requirements and best practices. “That’s the way android does it” and “we’re going to test that” addressed most of the concerns.

Then we did that a few more times…

Overall there was minimal pushback and people were excited about the new design direction.

They ended up liking it so much that we are taking everything we have done for Android and implementing it for iOS.

Design sign off is not where this story ends. The devs were on a tight timeline too and whether it was because of time, data, or the 3rd party vendors they had to work with, there were some things that just couldn’t be done for MVP that were only discovered post-handoff.

(Left) We had little to no time to focus on this feature. Though we did remove the megalithic amount of text you had to scroll over to even get to your personal statements.

(Right) Presented in the phone, in front, is how we wanted to organize the information but with limitations on the database side we were left with using the terrible programatic language that it spit out.

This was a huge bummer :(

Testing

This GIF epitomizes my feelings for this project

The script we constructed was meant to navigate the user through each of the app features with a goal to understanding what they thought of the new experience. We also had some very specific points to touch on:

We tested a few concepts with Invision. Pulling these up on a secondary phone so the user could compare the 1.5 dashboard against the MVP they had just interacted with.

Results from testing

We learned a lot. You get it.

As you can see we learned a ton from just the 8 users we tested. Some of the things we’ll need to go back to the drawing board for, though others will be more easily tackled. We plan to correct any defects and a game plan is already in the works to address the feedback we received.

My take aways

This type of project was really challenging, as a designer, with all the legalities and restrictions we had to work with. There was a lot of criteria to follow and list items to be checked by numerous teams.

Challenging projects like this put what we do in perspective. It’s not always blue sky and if it were I probably wouldn’t want to be a designer.

Being a User Advocate Maniac should always be our first and foremost goal but it’s the other pieces to the puzzle that also validate what we are striving for in the end.

There is no business without users and no users without business.

What’s next

The team and I have already been making movement to get more agile testing sessions implemented earlier into our process such as interviews, surveys, card sorting, 30 min on/off site application testing, etc. Along with this, we are trying to get services set up to have more robust, ongoing, analytics. That way, in the future, we can make more informed decisions and create the best possible experience through iterations.

3rd party vendors with no APIs or SDKs for us to use presented some, straight up…roadblocks, and there are several areas of the app that still require that we take the user to a web view because of this. Until they update or find a workaround these pieces will continue to be mediocre at best.

Funding and dedication

The big wigs must first realize how vital user testing and analytics are to creating a great product. Once they see the value of buying in to having a great product, only then, can we begin to move mountains within this industry.

This UX team has some awesome stuff in the works to pioneer that buy-in. It’s a slow and difficult process for a company of this caliber and one that is set in a legacy way of thinking.

Well here it is. This is what you have been waiting for.
*Lion roars through circle*

So why is designing for healthcare the worst in the best way possible?

The bad:

Legacy/Tradition — makes for dated processes and hinders the creative workflow

Siloed departments — collaboration takes a back seat between departments

Project disconnects—Web and mobile don’t work in tandem and each project owner has their own list of priorities. This makes for major disconnects across brand.

Pore analytics—Mostly due to PHI concerns. Health information is some of the most protected information out there but it makes a UX designers job very difficult when trying to make design decisions.

Follow up—Not only are we making a lot of initial assumptions but due to the lack of data the only way we can validate them are by following inquiry trends to customer service and mind you this is not an easy thing to do.

It gives it a real feeling of:

Cross your fingers, push it of the ledge, and hope it flies.

Where is the light in all of this?

Like any good designer, I love a challenge, and not only in the spectrum of design but also in processes. Because of these hurdles the team and I found ourselves collaborating on how we can better the processes in the future. We’re already having meetings with the other departments to see how we can improve how we work together.

This project has also put me into a position to work with our UX manager and help advocate for more user testing and setting up the entire structure on how we incorporate that on a project to project basis.

Sure when you have 4 piece puzzle to put together it’s nice. But when you buy that expert level puzzle with over 1000 pieces you’re much more satisfied with the end result even if the picture is exactly the same because you know what it took to get there.

In the meantime hit me up with what might of helped this process or critique on the design.

Please ❤ if you enjoyed the read.