Somewhere in the chain someone was probably saying "It's not ready", but the brass said "Too bad, we go live on this date ready or not". Politicians are used to pushing things through the system as fast as possible and then patching them later. When your QA process is a court system that takes years to notice the bugs, software development is a somewhat jarring process.
They don't seem to have anticipated that people would want to simply browse the plans, rather than immediately sign up.
The only variables that go into a quote are location, smoking status, and age. My state is divided into a little over a dozen distinct locations.
Given the limited variables, plans and rates could have been put into static files on nginx servers, and served huge traffic with ease, especially if you add a CDN so most requests don't even hit the servers.
Add a little javascript at the front to determine which files to pull, plus a bit to calculate subsidies based on income, and you're done. You don't have to hit databases until someone's actually signing up.
I love the "it's not ready" excuse for why something is so hard to use.
In my experience, you have to TRY to make something harder to use.
In this case, like many others, I'm sure no resources were dedicated to design/UX, so the site was built exactly to spec by devs who had no consideration for usability.
Does anyone here file taxes? Just because a form is on the web doesn't mean it will be well designed, or easy to understand. Whether you agree with the politics or not, you shouldn't expect efficiency from the US government. I only expect the affordable care act to be as efficient or simple as medicare/medicaid and it sounds like I may have been right.
11 comments
[ 3.4 ms ] story [ 28.0 ms ] threadWould love to know which government contractor built these crappy sites
Service Unavailable
HTTP Error 503. The service is unavailable.
The only variables that go into a quote are location, smoking status, and age. My state is divided into a little over a dozen distinct locations.
Given the limited variables, plans and rates could have been put into static files on nginx servers, and served huge traffic with ease, especially if you add a CDN so most requests don't even hit the servers.
Add a little javascript at the front to determine which files to pull, plus a bit to calculate subsidies based on income, and you're done. You don't have to hit databases until someone's actually signing up.
In my experience, you have to TRY to make something harder to use.
In this case, like many others, I'm sure no resources were dedicated to design/UX, so the site was built exactly to spec by devs who had no consideration for usability.