My continued fascination with Healthcare.gov

I really can’t wait to read the case study (novel?) on Healthcare.gov – the design, development, the rollout, the hearings, the politics, and beyond.  I wonder what would have happened if we’d had the internet when Social Security was implemented.

Members of Congress continue to compare the shortcomings of the website to ecommerce giants Amazon, ProFlowers, and Kayak. I find it interesting how suddenly members of congress are ecommerce design, analyst, and development experts. (I know, I know, we’re all “users.”)

Security of the site was a topic in the hearings today, with lawmakers buzzing over the fact that the site security was not vetted enough (according to a warning memo). Ironically, Rep. Mike Rogers R-Michigan told Health and Human Services Secretary Kathleen Sebelius that, “Amazon.com would never do this.” Welllll…maybe not intentionally. Remember how awesomely bad Amazon.com and Apple cloud services  were hacked last year?

Older articles published prior to the rollout show that Sebelius asked for patience, acknowledging there would probably be glitches in the coming days and weeks after the launch of the site. And that glitches are common, particularly in what the industry commonly refers to as public beta period. The key being that during a beta period, glitches and hiccups are identified and resolved as quickly as possible.

Sebelius also hoped that users would cut them some slack if things don’t go 100% smoothly, referencing unpopular updates to Apple products, “No one is calling for Apple to not sell devices for a year or to get out of the business because the whole thing is a failure. Everyone just assumes there’s a problem, they’ll fix it, let’s move on.”

It’s curiously amazing how consumers give tech companies leeway when using their products while they suffer through their growing pains. Apple’s iPhone wouldn’t let you  copy and paste text for over a year after it went on sale. Windows 8 Start Button anyone? How quickly we forget.

Also, large technology companies like Twitter, Facebook, Amazon.com and Google are used to rolling out new features and fixes all the time from small, nimble deployment teams. Obviously, many of Healthcare.gov’s problems stem from the fact that there were 47 different contracts awarded; so exponentially multiply the anticipated number of code flaws per person on the team x the teams x the different contracts and companies involved. Oh yeah, add all the different databases that had to talk to each other.

Clay Johnson of the Department of Better Technology, a company that designs and builds software for the government, has been doing a great job of pointing out “you get what you pay for” when it comes to government procurement processes (my summary, his is more eloquent and evocative) and building this kind of site. If Amazon.com was the government ecommerce website selling everything under the sun, designed and built the same way as Healthcare.gov, launching the week before Christmas, how do you think it would go?

I was reading the most recent blog post on Healthcare.gov “Healthcare.gov: Improving the Account Registration Process”  (yes, the site has a blog) which lists the biggest improvements the site has made to Account Registration since the site launched.

In combination, the following fixes are allowing users to successfully create an account and be able to continue through the application process.  We can now process nearly 17,000 account registrants per hour – or five per second – with an error rate near zero:

  • We replaced the virtual database with a high-capacity physical one, which allowed more efficient, effective processing and significantly reduced the error rates, or account registration failures;
  • We’ve optimized software configurations to increase efficiency in system interactions;
  • We added capacity by doubling the number of servers;
  • We swapped out a directory component for another that can process more transactions simultaneously;
  • We improved the efficiency of database look-ups through software changes;
  • And we pushed through a patch release with four software fixes to address users that were having a hard time logging in to their accounts. 

Unfortunately, the site crashed in the midst of hearings today, October 30, just when the congress person was pulling it up for reference. But if what they say holds true, 17,000 registrants an hour is no small feat.

 

Mobile is Eating Our World, Russ Whitman, SIC 2013

I recently attended a talk given by Russ Whitman of Ratio Interactive during Seattle Interactive Conference (#sic2013, #sicmobile). Russ and I actually worked together in the 90’s on a product called the “icebox” – an internet enabled kitchen appliance. (Basically, a TV with the internet on it with a washable keyboard and mouse). Oh, how far we’ve come in 15+ years. (And where are we going?)

The industry is now:

  • Big and Micro data; the small things and moments build big data – don’t discount micro-data
  • Personal and Enterprise data
  • Native and Web
  • Cloud and Local
  • Multi-screen beyond smartphones and tablets – TVs, cars, airplanes

Our world is made up of touch, mouse, controller and gesture interaction. Design and UX matter. The shift is worldwide, particularly with rapid adoption.

Consumers have a series of devices, no longer just one computer that stays in one room and does everything:

  • Tablets for reading, browsing
  • Smartphones for staying in touch, killing time, searching
  • PC/laptops as workhorses, transactional machines

The reality is we have screens in front of us every day, and we need to make them more useful. Whether it’s on your wrist, in your hand, on your desk, or in your car. Smart TVs are coming on strong. 67m Smart TVs were sold in 2012; 90m are projected to sell in 2013. It’s time to start thinking about branded, second screen experiences.

Digital video consumption grew exponentially through 2012 on non-PCs; more people are bypassing cable. Brands recognize this and are going digital only. Consider Netflix. They are the first non-TV network (cable or broadcast), to receive Emmy nominations (and awards) for their original series, “House of Cards.”

App downloads drive everything, they are not going away. Brands are working to build their own connected ecosystems through features and capabilities while keeping other brands out – aka “The Walled Gardens”  of Apple, Windows, Kindle/Amazon, and Android.

Why do people seem to use the same 5 apps? It’s a question of viewability and access. Consider how many app tiles/icons a user can see on the screen at one time, and how many screens do they have full of apps? What’s first, what’s last? We need to be smarter about bringing content forward – such as in contextual format, or time of day.

Also bear in mind that not all apps are created contextually equal. For example, a user may have and use up to 3 different note-taking apps, depending on the environment, the device, their immediate needs and goals.

When choosing between contextual experience over consistency – contextual experience always wins. A user won’t use your app or site if it doesn’t work for them in a a particular, preferred context.

The reality is that it’s software and it’s going to break. You can only test so much. Get real people in front of it, using it, as soon as you’re able and as much as possible.

Healthcare.gov, meet Congress

maketplace

The anal probe of Healthcare.gov continues with agency representatives involved in developing and building the site appearing before a congressional hearing to answer questions about the glitches in performance and site requirements.

Some interesting UX revelations thus far:

Features are now basic expectations: 
On two separate occasions different congressional representatives referred to online giant Amazon (and Ebay) stating: 1) Product comparison on Amazon is not as difficult as it is on Healthcare.gov, and 2) Amazon doesn’t crash the week before Christmas under the heavy load of users on the site.

1) Comparison capabilities. Amazon practically invented the ecommerce we know today. Once a feature, product comparison has now become a basic expectation of retail sites. Healthcare.gov has it, but it’s “difficult” to use comparatively. The UX side of me wants to know what portion of the experience made it “difficult to compare” insurance plans compared to the experience of comparing TVs on Amazon.com.

2) Obviously a working website is beyond a basic expectation. But in Healthcare.gov defense, Amazon didn’t launch less than 30 days ago to tens of thousands of users. And, despite ramping up, websites will get glitchy when there is heavy user traffic. Case in point: First day of the Nordstrom Anniversary Sale–trust me, they learned when no one could  check out online a few years back. Never did go back and buy my shoes.

I think an even more logical comparison scenario would be to try merge Amazon, Ebay, Etsy, Macy’s, Zappos, Best Buy, and Apple into one ecommerce website and launch the day before Black Friday.

Last minute requirements/unnecessary hurdles:
Apparently, it was a “last-minute” requirement to make users create accounts prior to being able to browse insurance products. OMG. Why, why, why? That’s the equivalent of making users create an account to browse ANY ecommerce site.  I would have punched the individual who mandated that. (Or the closest wall.) Can you imagine the shit-storm that created in the contractor ranks? The whole site was more or less bogged down due to concurrent registration. Fortunately, it’s been updated so that users can “window shop” insurance products without having to create an account first. Thank goodness. 

Business as usual:
Congressional members seem to be fairly alarmed that one or more of the agency representatives are looking at the website problems as just another day in the realm of website launches of this nature (aggressive deadlines, last minute requirements, multiple vendors, numerous database reconciliations, millions of lines of code to test, etc).

In her prepared testimony, Cheryl Campbell (of CGI) said that “unfortunately, in systems this complex with so many concurrent users, it is not unusual to discover problems that need to be addressed once the software goes into a live production environment.”

“This is true regardless of the level of formal end-to-end performance testing — no amount of testing within reasonable time limits can adequately replicate a live environment of this nature,” she added.

Notably, many Republicans equated the problem-plagued website to a failure of the Affordable Care Act (aka Obamacare) itself. As Senator John Cornyn, R-Texas stated, “Obamacare is coming apart at the seams and it’s time to put this broken law to rest.”

As a UX professional, I will concede that a poor user experience can negatively affect  brand perception in the mind of the user. But, as a UX professional that has seen the launch of many sites and interactive experiences, I confidently state there are always small glitches or scenarios that only reveal themselves, despite all the user flows, scenarios, Q/A and testing you do. Not to mention clients with last minute requests. (Anyone who says otherwise is lying.) Unfortunately for Healthcare.gov, this isn’t just any site. Not with people’s livelihood in play, as well as  political theater and re-elections in the balance as well.

And while the site is getting “easier” to navigate and glitches are being addressed, politics are still involved. Which means the entire nation is now getting an education on how websites projects are often managed, designed, tested,and developed. For better or worse.

Has Apple Lost it’s Mojo?

Apple-Tech-LiberalArts.SteveJobs

As a long-time Apple user (as in, before it was a cool company), the past couple of years without Steve Jobs has made me question the company’s ability to continue to “Think Different.”

Ben Thompson puts it out there in his recent post, “Whither Liberal Arts,” noting that Tuesday’s unveiling of the latest Apple product upgrades and reinventions didn’t have any of the humanity that was once a part of all things Apple. Thompson makes some pretty compelling points, and it makes me want to stick my head in the sand.

Is this button necessary?

WC_1

Behold, the water cooler, counter-top style–one of several versions in my office. What’s a little nutty about this particular design (and why I’m bothering to mention it) is that despite how basic it actually is (cold or hot water), the actual process of getting the water to dispense always gives me a little cognitive hiccup, no matter how many times I’ve used it.

If you want cold water to dispense, you push the blue button, labeled “Cold.” Similarly, if you want scalding-hot, first-degree burn water to dispense, you push the red button, labeled “Hot.” However pushing the button doesn’t immediately dispense the water. Pushing the button selects which temperature of water to dispense. In order to get the water to dispense, you have to push the large-ish gray button, labeled “Dispense.” (I don’t know what the little green light does. My assumption is that it just lets you know the unit is turned on. No pod-bay doors to open here.)

WC_2

4 out of 5 times I stand and hold the “Cold” button for several seconds, expecting water to fill my glass, and nothing happens. Then I remember I need to push the “Dispense” button. It drives me nuts. Particularly when the other water dispenser, a floor model, dispenses water when it’s “Cold” button is pushed.

If the buttons are intended to select the water temperature prior to dispensing, why do they have to be buttons that look like they’ll dispense water when pushed. They scream it. Why not  a  little semi-raised version that looks more like a selector than a dispenser? I did a quick audit of small-ish, counter top water dispensers and the “less-buttony/more selecty” design seems more appropriate for the intended function.

SN 12 Touchless
Manitowoc water and ice dispenser. Note that the “selection” buttons are above and to the right of the dispenser.

Got a similar water cooler or misuse of physical buttons story (or rant)?
Feel free to share.

Eeny, Meeny, Miny, Moe

Seriously!? Which button do I click on in order to submit payment successfully? And what happens if I click on the wrong button?

SecureCheckOut

I tried looking at it sideways, which is difficult to do. I moused-over the buttons to see if by chance there was an over-state that would provide readability. Nada.

By the way, it’s the button on the right.

Is the Hover State dead yet? Or just being redefined?

I sit in an “open office,” which is sometimes code for cheap, as in: shoving as many people and desks together in one area before you break fire codes and accessibility laws.  Sure, yeah, it’s a collaborative environment, which can also be mistaken for unintentional eavesdropping or creative drive-bys. (BTW, I blame Herman Miller for the open office space concept. Even if they are never implemented the way HM originally designed them. I may devote a post to my experience about a poorly designed green building and it’s open office space).

Anyway, earlier this week a project manager approached an art director I sit next to, and asked him if there were any hover states on a particular page he was responsible for designing. Naturally, as part of the open space concept, I inserted myself into the conversation. Long story short, No–there were no hover states. But we started discussing what exactly is the state of The Hover State these days? The Answer, “it depends.” (I think this is one of Jared Spool’s favorite answers.)

Back in the early days of the web design there were basically three, common visual states of a clickable link, button, image, graphic): 1) at-rest or default, 2) hover- or over-state, and 3) visited-state. (You could argue four, if you count on-click, but whatever.) The hover-state was used to visually indicate the “click-ability” to the user when her mouse “hovered” or “moused-over” a link/button/image. A UX professional would tell you that for an optimized user experience, clickable objects, more specifically links or imagery, should be visually differentiated from content to avoid confusion with lists, copy, captions, static images; the hover state was an immediate visual confirmation that the object could be clicked.

Fast forward to June 29, 2007 and again to April 3, 2010. The introduction of the iPhone and iPad. Hello touch. Hello it doesn’t sense my finger “hovering.” Hell, now what?

So far I’ve only mentioned clickable links or buttons. Touch interaction revealed: 1) there is no “hover-state” (as we know it) on a touch device and 2) what do you do when you have navigation menus or drop-downs that reveal (open) themselves “on-hover” in a desktop environment? Tapping on an nav menu or drop-down that had a hover-state attached to it resulted in a variety of visual and/or interactive responses, my personal favorite being a nav menu opening while simultaneously navigating to the corresponding navigation page before I even had a chance to look at the menu options to decide if the menu contained what I was browsing/looking for.  And it seemed that no two menus acted the same in the touch environment, which meant that not all hover-states were created equal in the desktop environment.

Fast forward to now:  responsive, adaptive, hybrid, mobile site, app design, and all things future friendly. With queries and style sheets we can do a better job targeting viewports and devices and delivering a more appropriate interactive experience.  However, I’d recommend a little interactive strategy planning up front. A quick audit of the topic reveals like minds; it seems that there are three logical options to start with:

1) Design hover-states for mouse events, and display everything on mobile

2) Design hover-states for mouse events, and gesture equivalents for touch. 

3) Don’t use hover-states.

Note that #2,  the key to implementing this approach is hover-state equivalency. In other words, if a rollover reveals a menu, ensure that a single tap reveals the menu, but no other functionality. A second tap (conceivably to make a selection from the menu) should result in the site/experience behaving accordingly. Similarly, tapping outside of the menu, implementing a close button, and/or time-out should close the menu, just as if the user had moused away from the open menu.

Obviously, with a “Mobile First” approach, how elements and objects work in a “mobile” scenario (as in viewport/breakpoint size) would be addressed first, and therefore would be more top-of-mind throughout the design process, instead of an afterthought.

Regardless, it would appear that the Hover State is here for now, but perhaps needs to be redefined in order to address the wider range of interaction capabilities that exist today. Google Glass anyone?

Healthcare.gov reminds us how not to build a website

3 years and an expected cost of half-a-trillion dollars ($638.81 million). And there you have it, Healthcare.gov.  If ever there was a website that was going to be met with more scrutiny than an anal probe, this one is the front runner. Since the October 1 launch, the site has been fraught with issues resulting in a bug list that undoubtedly makes a Q/A want to curl up into the fetal position and wish they were considered “non-essential.”

Okay, I know. It’s a government site. That’s the first problem. According to dobt.com (Department of Better Technology) in a blog post “How Healtcare.gov Went Wrong“, there are a multitude of issues within the procurement process which have compounded the creation, development and launch of such a massive website. To begin with:

A High-Friction, High-Overhead contracting process: There was no competition for the Healthcare.gov contract. The Dept of Health and Human Services used an existing contract it already had with CGI Federal. (Which BTW, is the same company that built the portal for Massachusett’s “Romneycare”; you’d think they’d know what the hell they were doing already.) The contract was “greased”, meaning reduced friction. The normal procurement process would have taken about 18 mos, so in an effort to save time the government opted to take a contract they already had.

Requirements Written By People Who Don’t Understand Technology or Procurement: If you want (an IT project) to be a total disaster, let Congress design the requirements and set the deadlines. Enough said.

Building a Battleship like a Website: The process leans toward a write-down-all-the-requirements-then-build-to-those-requirements type of methodology–which makes sense if you’re building a space shuttle or a battleship. But this methodology doesn’t work when it comes to building a website, especially one over 3 years, where tools and techniques are bound to advance.

Lack of Pricing and Availability: In a functional, real-world marketplace, companies that do a good job at low cost will grow. Those that don’t will shrink. In the federal IT marketplace this isn’t how it works for two reasons: the federal government doesn’t know how much stuff should cost and doesn’t do a good job sharing performance-based information. The fed will track contractor performance based on misconduct, but not poor performance. And they don’t track pricing information.

Inappropriate relationships between Congress and Contractors: Contractors can lobby the federal government, and CGI Group, Inc lobbied the fed on the Affordable Care Act though there’s little data on what or why they lobbied. Still, it’s a question of ethics and the procurement process.

Pile all this on top of what appears to be a site that was never run through load testing, user testing, accessibility reviews, browser support and optimization, well then no wonder. People familiar with using the web expect things to work, and when they don’t, it damages the brand and perceived value of the website or experience they’re visiting. Unfortunately, this isn’t some bloated internal database that only government employees will have to suffer through. (The first page of the registration process (once you get to it) has 2,099 lines of HTML code, but it also calls 56 JavaScript files and 11 CSS files.)

This is a website For The People.

Apple’s iOS7 reveals the challenges of designing Flat Design

Two very recent articles I’ve come across regarding Apple’s new iOS7 and the challenges it brings to UI design.

Unless you’ve been on another planet for the past month, Apple launched a new iOS embracing flat design–eliminating skeuomorphic UI and other effects like glossy highlights and drop shadows. For those of you who have been off-planet, skeuomorphic UI design is the concept of creating graphic elements that emulate real-world objects. For example, a yellow ruled notepad interface for entering notes. To be fair,  Android introduced the concept first but when Apple did it, suddenly people payed attention. Go figure.

Both Luke W (Designing for iOS7: Perils & Pluses) and Baruch Sachs (Flat Design Won’t Hide Your UX Sins) discuss how flat design challenges UI designers because many of the elements of visual language designers once used to communicate have been eliminated.

The simplicity of iOS7’s design language comes at a cost: a reduction in the amount of visual elements designers can use to create hierarchy and thereby understanding. … How people makes sense of what they see gives designers a set of attributes to play with to create meaning within a design. Elements like color, size, and texture can create similarity, differences, and hierarchy within a layout. When these elements are “flattened”, some of this vocabulary goes away.

Instead, UI designers designing for flat design have to be more cognizant of information architecture, layout, typography and the principles of design – basically getting down to the bare essentials – that make interfaces usable and useful without the former aesthetic distractions.

In flat design a clearly structured typography ladder has become more crucial to help a user differentiate between say, a primary CTA, a secondary CTA, and a non-CTA (plain text). Additionally, the placement of the CTA in relationship to other elements in the UI is even more crucial to give succeed in helping the user make confident decisions and interactions with the interface. If the UI implementation has no hierarchy or structure, looks the same and makes the user work harder to find their way through it, then it’s a fail.

As Luke W points out, intelligent flat design success probably ain’t gonna happen on the first round. Making something look and feel transparent and easy is actually very difficult. Which is what flat design UI takes in order to succeed. Just because a designer removes all the shadows and gloss, effectively making the UI flat, doesn’t mean it’s achieving it’s goal of helping guide and direct users in their tasks.

And, as Sachs sagely writes, flat design may not be the most appropriate UI solution for the project,

Sometimes flat design works, and sometimes it doesn’t. … To judge the best approach, you need to understand usage patterns. You need to know how people do their work.

I think what I appreciate most about flat design is that it takes us back to the roots of user experience practice and pushes utilization of the most basic, yet time-tested principles of UX design to the forefront again.

Truly, what is old is new.

Update 10/14/2013: Nielsen Norman Group (NNGroup) gives us their iOS7 User-Experience Appraisal