Inflating Expectations

I had to go check out Healthcare.gov after reading one too many articles like this one - which was by far the most balanced in its observations. The experience of going through the registration and submission process was fraught with deja vu for me.

The design is slick, web 2.0, senior friendly and demands very little from the user. While that's all good, its sets certain expectations of a frictionless finish. So when the submit option results in a blank page and you are left hanging there is a sense of deep disappointment.

What we have here is a building with a beautiful facade but missing plumbing and electricity. So familiar from engagements I have worked on over the years with big clients. The common theme is the idea of designing a system based on use cases and the oversimplification that follows from this premise. A user interacts with a system in a certain number of ways and workflows are constructed around them. 

This is fun work - a cross functional team can come together and build something that everyone can understand equally well. There is also the false sense of comfort that the needs of the customers are being fully considered and to that end the finished product will be perfect. 

The business of integrations that need to happen under the hood and the data flows to keep the systems of engagement in lock step with the systems of record,  are not given nearly the same attention - this is not use case driven stuff. Not everyone in the project team understands what this is about, the communication between technical and non-technical members of the project team become harder and frequently break down. The results manifest themselves as they have on Healthcare.gov where the scale of challenges (based on the stated objectives and not what ends up being delivered) is orders of magnitude greater than anything most of us in the IT business have ever encountered.