health care

Kaiser Permanente: a micro case study in design


If you are designing websites and mobile applications I hope that this article helps you.  I’ve been designing information systems for healthcare and other industries since 1992.  If there’s one thing I’ve learned over the years it’s that the best websites and mobile applications are designed with specific needs of the end user in mind.  Anything more than that risks making the users’ lives more cumbersome.

In terms of your daily work and project management, it means you’re going to be spending all of your project’s resources focusing on a few key features.  Any additional features not critically important can take priority later.  But you’ll find that while a website and a mobile app can do a lot of stuff, the effort to add the “extras” is a waste of energy unless the key purpose of the application are met first, and met in an excellent way.

If you can strike the balance between the presentation of critical information and “nice to have” information then you’ve done something helpful to both your company and the user.  If you inundate the user with more than that then you risk imposing extra process and burden on the user that can, as a worst case, prevent them from doing the very thing you intend them to do while visiting your website.

I recently had a chance to look at Kaiser Permanente’s web experience and realized that the website could serve as an example, so I thought I would share it with my fellow system architects and developers.

The Basic Use Case

Early in my career I worked as a system developer at a local hospital (and later as a health care IT consultant) for about ten years.  During my tenure I learned a critical design point.  For a patient using a health care organization’s website (and mobile app) there are five things that a website needs to do to the exclusion of all else.  They can be summarized in the following use case:

  1. tell the patient who they are and who their children are.
  2. tell the patient what doctors are involved and how to get a hold of them. Simple names, addresses and phone numbers will do just nicely thanks.
  3. tell the patient what their schedule is and where they can make an appointment. Digital appointments are good of course.
  4. give the patient access to their medical records.
  5. give the patient access to messages they get and send to the HMO, the doc, etc …

It’s also important to understand that, like any data-intensive web experience, anything more than that will actually distract the end user from their goal.  And, I submit to you that unless your website is first focused on a core use case like the one I’ve just described in the five points above, that you not only will “miss the mark”, but you may very well alienate the user.

So, with that in mind let’s take a quick look at Kaiser’s website and see how it stacks up.

What Kaiser Has Done (and not done)

Take a look at the Kaiser website:

This is what I see after logging in.  So, let’s take a look at the choices the design company made with building this website.  The only thing I see are LINKS to things.  But I don’t actually see any of the information I am needing as an end user – with the exception of my own name.  What I see are several data points that really don’t have anything to do with me and my doctor.  There are just extra bits of information my brain has to sift through:

  • Irrelevant links. a link for “Prospective Members”, “Media Representatives”, “Brokers”, “Job Seekers”, “Employeers/Administrators”, etc.
  • An invitation to do unimportant things. Links and information on a website (and in a mobile app) are calls to action. Links ask the user to click to go somewhere else.  Information ask the user to read content.  So, they must all be relevant items.

Irrelevant Links

Showing irrelevant links on a web page, like “Prospective Members”, etc. (in Kaiser’s case), tells the user that the website doesn’t understand that the person logged in is already a member. This leaves users with a sense that the website and by extension, the entire company, doesn’t really know anything about the customer.  A bad sign for a health care organization.

An Invitation to Do Unimportant Things

So, in the context of my use case – an established customer that needs to manage a relationship with my doctor, this is important.  A link “Shop Health Plans” appears to be a kind of “up selling” that leaves end users with some crippling notions.  Namely, that not only does Kaiser not know who you are, but that the user is being asked to shop for something completely unrelated to the site.  So, it mentally takes the user away from his goal, which is to manage the relationship with their doctor (see the five points above).

Are You Asking Users To Redirect Themselves?

Irrelevant links and calls to action away from the core purpose the user has are but two items that are explicit in the design of this example Kaiser website.  They also have implications and side effects in how the user feels about a website experience.  But, that’s not all. In Kaiser’s case, there’s also a high possibility that users will get a sense that the company is trying to actively direct the user away from their doctor.  Consider, for example, the fact that the user is already paying for the health plan.  Those are expensive products.  And when they get to the website to make use of the thing they purchased, the website is telling them, in effect,
I don’t have the information you need – go elsewhere.
While some may conclude that I’m being too hasty, consider this in the context of what could have been put right on that front page.  If Kaiser had insisted the main page contain only information that is relevant to the end user’s use case, it would have actually reinforced the idea in the user that the website is there to aid the user in doing what they really need to do: and that, quite simply is see a doctor.
I feel for the designers who put that website together because they probably spent a lot of money.  But, the key takeaway from this lesson is that website and mobile application development is not about spending money to get more.  It’s about spending money to reign in the options that are presented to the users to include only what’s right and relevant for them.  It’s far better to spend a million dollars perfecting the simple thing than to spend the same amount just adding content.

Digging In a Bit More

I won’t be going through the entire website in this blog post, but I’ll dive into one screen beyond the home page so you get an idea as to what I’m talking about.  Recall in the previous section that the user has already been “told” by the website that she has to “go elsewhere” to find information relevant to her: either by clicking on links or purchasing other products.  Pretty grave when you consider that the website, in the patient use case anyway, should be a single end point for the user: the place where they get to stop looking for things and focus on the critical task.  Again, in this case that simple task is to manage a relationship with one or more doctors – who are people.

So, after spending several minutes digesting the contents of the home page, and possibly clicking around on the wrong links, the user clicks on the link called “My Health Manager”.  They get this:

Now that seems a little better.  But, is it really? It depends entirely on what happens when a user clicks a link on this new screen.  They have to click something else now, because after all we still don’t’ see anything related specifically to the simple five point use case I wrote above.

Already, the website is running the risk of making the user feel like they have to search down rabbit holes to get something simple done like schedule an appointment. Each click of a link, remember can take a minute to load (or more) depending on the internet connection.  I’ll leave the detailed link analysis to somebody else.  But the point is that it’s an experience that can drive people away from a website and company.

But what’s noticeable here is that on the Kaiser website, none of the top level or second level pages actually tell the user any information about the five items I mentioned above.  So far, the only the thing the website has done is make the user hop through hoops and left them with a sense that the website is an “information trail” (or trap, depending on how yo view it).  In this case, you have to ask: is that really what you’re after in a website that is intended to help people who are already sick or need medical care?

Failure to understand that users don’t have that time or don’t care about exploring your website just for the sake of exploration is perhaps the biggest design miscalculation a company can make.

How This Relates to Mobile

The thing that mobile devices force system designers to do is simplify things.  I will save analysis of Kaiser’s mobile application for another post.  I haven’t even seen it yet.  But I would venture to say that I’m going to get the same kind of “data run around.”

The fact mobile devices restrict choices for designers is a good thing.  It forces them to prioritize the information presented to the user and the specifics of the use case much more carefully.  The irony is, too, that the end result is a software product that is actually much more maintainable in the long run.  It’s just plain simpler.


2 thoughts on “Kaiser Permanente: a micro case study in design

  1. Hi, My name is Robert Schilling, student and software developer from Austria. I found your Github account rschilling ( I saw that you are not active on Github so may it possible that you change your account name? Thank you in advance!

    Regards Robert

And now it's your turn ... comment here or on Twitter (@Androider)

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s