UX Rant: MA Health Connector

originally published 1/13/2015

First off, please don’t take this as a rant against Obamacare (or in this case, Romneycare). This is simply meant to expose the stunning lack of UI/UX know-how present at the offices of the Mass Health Connector and to provide suggestions for ways to (easily) improve the overall user experience.

The Mass Health Connector required existing members to reapply for coverage at the end of last year due to the fact they redesigned the website. Rather than complain, I took this as an indication of improvement, since the previous website was all but unusable. A little strange that they weren’t able to reuse all our previous information, but whatever. No big deal. I was looking forward to seeing the new site. Plus, I was on top of things. It was only Monday, December 15th and we had until Tuesday, the 23rd to (re)sign-up and make our first payment. What could possibly go wrong? (hint: a lot!)

My first indicator things were going to continue to suck should have been evident from the above pop-up window itself. Who puts a close button in the bottom-right corner? Convention exists for a reason, people!

I (re)created my account, (re)entered my family’s info and (re)selected the plan I was already enrolled in (Blue Cross — pricey, but the only plan that covered my family’s vast catalog of conditions). Oh, and in the process, I discovered a nice example of the importance of maintaining nomenclature consistency. Peep this:

There’s a lot going on in this screen, but for the moment let’s just look at the Subscriber Information panel. Notice the first bullet refers to my ID number as a “Subscriber ID.” Fine. So far so good. But look at the example given and you’ll see they call it an “Enrollment ID.” And it’s not like they’re unaware of the discrepancy. They even mention it in the instructions! “You can find your Subscriber ID…when you log into your account and look for the number under ‘Enrollment ID’.” Unbelievable. If it’s a Subscriber ID, why are they calling it an “Enrollment ID”????

If you look at the Insurance Bill graphic in the lower right corner, you’ll notice another number — “Member ID.” Is this the same as the other types of ID’s? Who can say??

To complicate matters further, the actual ID number begins with “RefID,” as in Reference ID. So they have four different names for one number — the single most important number a user needs to know to (re)create an account. And if the only numbers that matter are the numbers that come after “RefID,” then why display “RefID” at all? They shouldn’t.

When you log into your account you encounter yet another instance of “Application ID.”

The problem here is the organization is assuming users will intuitively understand that Application ID and Subscriber ID are the same thing and will forgive the label variations. This is, of course, impossible. Nothing good can come of this sloppiness.

UX Rule #1: Inconsistent nomenclature can only lead to user confusion.
But I digress.

I made my payment using my bank’s routing and account numbers, signed up for auto-pay, in an effort to make my life a little bit easier (or so I thought), and congratulated myself on being such a responsible husband and father.

Then came the email — at 5:30PM on the night before payment was due.

This made no sense. I realized the website wasn’t going to help me. As much as I hated to, I would have to resort to an archaic form of communication. I would have to talk to a person. There wasn’t time to do anything else. Thankfully, I was connected to a rep more quickly than I would have imagined possible under the circumstances.

The rep told me something I hadn’t expected, “Your payment didn’t go through because you signed-up for auto-pay. We can’t do auto-pay on a first payment for a new account. Go back and resubmit payment but leave off the auto-pay.”

Which brings us to UX Rule #2: Don’t offer services you can’t deliver. Especially when you already know everyone is creating a new account — because you told them they had to. The most logical solution would have been to remove auto-pay as an option. Second to this, just ignore the auto-pay selection and send users an email: payment was received but please wait a month before signing up for auto-pay. Is that so difficult? You guys went the absolute worst route, because it involved the least amount of customer notification, which is to say, none. You simply rejected my payment without any explanation why the payment was rejected, not even in the rejected-payment email!

UX rule #3: The quickest way to deliver the message that you don’t care about your customer is by not delivering any messages at all.

Okay. Deep breath. I did as instructed. Then, since it was the day of the deadline, I called their office again to make sure this time payment had gone through. The genuinely wonderful rep I spoke to told me I had nothing to worry about. Not only had my payment gone through, I had actually made two payments! Frankly, this was unnerving. There’s no way this could have happened. It was hard enough just making the one payment! Okay…well, could she please refund the extra payment? No, she couldn’t. She said, “Once the money is in there, it’s in there.”

And here comes UX Rule #4: Never take people’s money if you have no way to give it back to them when it turns out the money is rightfully theirs to begin with because — among other things — that’s called stealing.

But not to worry, she said, the extra payment would automatically be applied to our next month’s bill. Great, I thought, no problem. I always have an extra $1700 just laying around anyway. Then she asked did I realize I needed to make my dental and medical payments separately? I hadn’t. She guessed I hadn’t since I overpaid for the (not one, but two) months of medical coverage by the exact amount required by my dental plan.
“How was I supposed to know I needed to do that?” I asked.
“I’m not sure,” she said.
Some of you more astute readers (more astute than me, at least) may have noticed the following copy in the image above: “…you will need to create a payment for each of your plans. You will have a different Billing Account Number for each plan.”

“Do you have both account numbers?” She asked.
“I don’t know.” I replied. “I have a bunch of different types of numbers, but they’re all the same number.”

UX Rule #5: Be sure you’ve provided any information you know you’ll require of your users. And place it prominently in a logical location where users are sure to see it.

I went back and made the separate payments and the next day checked my status, which seemed to contain a mixed message: application complete, enrollment pending.

Now comes the kicker. When trying to login, I unknowingly used the wrong password. Since there wasn’t any feedback from the browser when I clicked the “Sign-In” button, out of frustration I clicked it a couple more times, the way we do when we’re trying to get the doors on an elevator to close. Big mistake.

Suddenly, I got the message below.

UX Rule #6: Provide fair warning. Before doing something extreme (like, say, locking someone out of their own account), provide ample warning this is about to happen. Insert popups that require additional interaction to prevent the lockout from happening (e.g. clicking an OK button to dismiss the popup). Because chances are, the person you’re locking out is not a hacker, but the applicant himself.

Unable to take much more, I gave up and prayed everything would be okay. Later that day, the Health Connector made a public announcement: they were extending the pay deadline by a week.

What a shocker.

In case you’re wondering, everything worked out. I was soon approved for payment and coverage (though at this moment I still have no way of checking to see how much extra money is in my account). Oh, and also, despite having received all our medical cards, the website still says my enrollment is pending. Well played, Mass Health Connector, well played.