Wizards, Warlocks and Forms

Another interaction design lesson reinforced and illustrated by a recent project was the need to beware of wizards.  Not the kind with pointy hats and long beards, although those should be carefully investigated to be sure you're not dealing with the warlock variety.  In truth, I don't know the difference other than warlocks always seem to be bad and wizards can be good or bad.  Or is a bad wizard automatically a warlock?  Who knows?

At any rate, the wizards I'm concerned with are the kind we often use to present forms in a linear fashion or to walk a user through some sequential steps during a setup, registration, shopping or other process.  They are often helpful in making sure that pre-requisite choices are made in the right order.

However, and here's the lesson, we must be careful not to present multiple forms that are not order-dependent in a wizard format.  Often this will lead the user to stop during the completion process when they come to a question they cannot answer or are uncertain how to answer.  It would be better for them to skip that question and go on to some others they can answer.  But if they think they are in the midst of a wizard or sequential process, they'll often stop cold.

Some of the cues that make users think "wizard" are "Next" and "Previous" buttons on the page, numbered forms, a progress indicator across the top or down the side of the page and so forth.  There are of course many visual design cues that can give the appearance of a wizard format.

When you want to enforce sequential order use these kinds of design elements and of course make the pre-requisite fields required to force completion.  You'll often use a "setup profile" type of format when you want to capture a number of required fields up front and then present the optional fields afterwards.  Another technique is to apply this format to multiple sections which each have some required fields upfront which are then followed by the optional or non-required fields.

But what to do when you really don't have any "required" fields and order doesn't matter?  You can use instructions before starting the form and on-page to remind the user that order doesn't matter and that they can skip around all they want.  You can offer a "check progress" or "percentage complete" tool that shows them where there are unanswered questions without having a progress meter that can make the forms look too linear.  You can use "save as draft" or "save" buttons on the pages and avoid the "next" and "previous" buttons.  If it won't  make too long of a page you can also put all the questions on a single page.

This last technique can be improved by good organization of the questions into orderly sections that help the user think through the information needed.  Think of it as IA for the form or just good old-fashioned form design.

So how did we solve this issue on my recent project?  We divided the information up into multiple sections that could be completed in any order.  However, within each section there were required fields that prohibited saving until they were completed.  We also used "Save" buttons on the pages with a "completion-checker" tool that made the user positively indicate that any empty sections were left that way on purpose.  The "Submit" button only appeared as part of the check results to avoid inadvertent submission of incomplete forms.

Remember, wizards can be your friend if used correctly but turn into warlocks when they confuse and unnecessarily constrain the user.  Beware!

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.

Busy. Simple is in the eyes of the beholder.

I've been busy.  Busy working on a client application.  Busy taking care of the family.  Busy supporting my wife who has a "touch of cancer".  Seriously: it was a small lump, it is now gone, and a little radiation therapy should make sure it never returns.  Discovery, biopsy, diagnosis, surgery all in about 3 weeks.  That'll keep you busy.

On that client application I really tried to simplify a repetitive task by asking the user to only do it once.  Then we'd let the smart computer remember that once and re-use the information when needed.  Smart?

Sort of.  Conceptually it was "elegant" I suppose.  However, it was way too different from the user's mental model to be of much usefulness.  So we went back to the old "inefficient" way that makes sense and doesn't confuse anyone.  Since the task was an infrequent one (once a year) I probably should have left it alone.

However, since the application will be used every year, the real benefit will be designing the "re-use" process so that it re-uses what is good and provides an easy and efficient way for the customer to edit and update the information.  That's the part we really need to simplify and get right.

I'm still busy. Too busy to write.

Used Cars and Legacy Software

OK, you can see where this is going right now.  Here's the whole debate over re-use, repair and getting something new in an easy to understand analogy.  The way to think about used cars or legacy software is not "how much is it worth after I fix it?" but "how much does it cost me to get what I want (or need)?".  It's a cashflow question, not a value question.  In both cases you're probably not selling anyway.  So what difference does it make how much it is "worth" to someone else?  You're never going to realize that worth in cash or otherwise.

On the other hand, the cost to replace the car or the software is something you'll have to realize.  You'll realize it as the money flies out of your pocket.  You'll realize it as the debt incurred to acquire the new stuff continues to erode the value of the new stuff.  I'm not advocating a "never borrow" strategy, just pointing out that many of us forget to include all that interest in our thinking.

If you think about refreshing the user interface or adding some new behaviors to an existing application kind of like aftermarket accessories or repair parts for that older car, you can put this idea into perspective.  For instance, my old Mercedes doesn't have cup-holders.  I think I'll add some rather than get a new car just for the cupholders.  A trivial example to be sure.  On the other hand, the hydraulic suspension needs repair and that can make you think twice.  Worth it?  Well, if it costs $500 and I think then I have a car "worth" $3000 that I have repaired for 1/6 of its value, you might not think so.

On the other hand, if I think I've spent only $500 to keep what was originally a $60,000 car on the road and serving me perfectly well, I might make a different decision.  The functionality and features are all there, they just need a little refreshing to keep being really useful and enjoyable.

A lot of my interaction design work is that kind of refreshing.  I'm taking a valuable, useful and proven software system and restoring its utility by re-concepting and redesigning the interaction idiom and user interface.

Often it is a very cost-effective and efficient solution for the enterprise.

VOICE

For many years I studied singing and enjoyed performing in operas and musicals of all kinds.  The single most important thing any singer learns (or at least hears) is to sing with your own voice.  Don't copy anyone, don't make up a sound, just sing with your voice.  The uniqueness of your sound is what makes you memorable, enjoyable and marketable.  You don't even have to be "good" so much as you need to be distinct.  Now, there are some limits to how "bad" you can be, especially in operatic singing, but being unique trumps almost everything else.

If you ever get a bunch of opera buffs together to discuss singers, there will be all kinds of opinions about who is the greatest, who is lousy and so forth.  And many well-known and even famous singers will be in both groups.  But those singers are all recognizable and memorable and that's why they're being discussed.  The pleasant, in-tune, pretty but cookie-cutter singers don't get the leading roles and aren't memorable.

The same principle holds for software applications.  Your application needs to have a distinct voice.  It needs to have a voice that is distinctive, recognizable and memorable.  And I'm not speaking strictly from a branding perspective.  The application with the strong voice is better for the users AND the brand.

Distinctive, clear, unambiguous and memorable are all great attributes for a user interface and an interaction design to have.  An application with those attributes ends up being easier to learn and easier to remember.  Now, there may be some who disagree with or don't like the voice of the application, but even so, they've paid attention and remembered it.

Voice.  Strive to give each application a clear, distinctive voice.