Chopping Up the Snake

Here's the full post expanding on my last abbreviated entry.

Lately we’ve all seen “Gadsden Flags” with the motto “Don’t tread on me” and the image of a rattlesnake on it.  Early variants had the snake cut up into 8 pieces which originally represented 7 states from the tail forwards and the 6 states of NE combined into the head.  Originally it was used as a banner to rally the 13 colonies against the French and Indians in the war that was named for them and carried the motto “Join or Die”.   That wasn’t a threat, but a recognition that if the colonies didn’t fight together they risked extermination.

While not nearly so momentous, a recent project highlighted the importance of keeping together those things which need to be together.  As the UX expert I was “certain” that breaking up their cumbersome process was more elegant and efficient.   Oh, I was so certain that I had achieved absolutely Palladian levels of Information Architecture brilliance.  Ah, grasshopper, you have much to learn.

Observe Proper Form

The project in this case was to take about 50 pages of paper forms and put them online into a web application.  The application will be used to gather information about all of the insurance plans that a company  will offer to its employees.  That information will then be used to develop another online application which the employees will use to enroll in those plans.

Analyzing those forms revealed that there was a LOT of repetition involved.  In short, there was a large set of common information for each type of plan (Health, Dental, Life, etc).  No matter whether there was 1 or 10 specific plans within each type, the common information didn’t change much if at all.

So, seeking efficiency, I proposed that the common information be completed separately, independent of any specific plans.  That common information would be applied to each plan with the option to specify any fields that might differ for any specific plan.  That simple change would drastically reduce the screen count, simplify and streamline the data entry AND map better to the way the staff that builds the enrollment applications thinks.  In addition, there were already other parts of the process which collected information common to or re-used in specific plans.  Brilliant!

Enter the User

It was brilliant except for one small issue.  That wasn’t the way the users mental model operated.  Their understanding of an “insurance plan” included all the information from front to back, including the common information, that defined each plan.   At the first wireframe review session we had with users, they completely rejected the concept of breaking plans into “common information” and “plan specific information” which I had created.   Guess what then happened?  

Listen. Listen. Listen.

My head did not explode.   My feelings weren’t hurt.  My professional pride was not wounded.  What happened was that the user’s comments and suggestions pointed the way to a better solution for them.  You’ve probably seen it coming for several paragraphs now.

We decided to simply carry forward the common information entered when the first specific plan of each type was entered.  Each plan will still have a number of repeated (dare I say, redundant?) screens, but they will be prepopulated from the values entered for the first plan.  That small change leverages the strength of computers to keep up with information and accomodates the user’s understanding of what each plan should contain.

Vote Early and Vote Often

The most valuable part of this whole process of Analysis, Design, Review was simply that we were able to give the user community a very early view of the proposed application and get their feedback.  By wireframing (visualizing) the design proposal, our expert users who had no software design experience were able to clearly understand the new application and to intelligently critique it based on their expertise.  This view was much, much earlier than they had ever had in this organization so the cost to modify the design was negligible. 

That is ultimately  the main lesson which this project reinforced: get your users involved as early as possible to validate, critique and shine the light of reality on your designs.  Your project will move faster, costs will be reduced and the resulting application will be more readily adopted.  It is of course the fundamental premise of User-Centered Design and one which bears fruit through constant repetition and practice.