One day at the checkout line I saw the "Check out with PayPal" button on the keypad screen.  I tapped it to see what would happen and saw that I needed to "link" my mobile number with my PayPal account.  Next time I was at a computer I started poking around to find out more.  I learned that I could pay with my mobile number OR I could use a PayPal card.  Do I need another card?

Then of course the obvious questions began:  Why do I need a special PayPal card when my PayPal account is already linked to my debit card?  What's the benefit for Home Depot or PayPal in this arrangement?  Is this going to cost me a fee of any kind?  How do I make this work?

Next time I am at HD I launch the PayPal application on my iPhone (which I rarely use) and see it gives me the option to add my phone number and create a PIN so I can login to the app without having to tap in my regular password.  Nifty! That'll probably be the PIN I use at checkout.  Well played, sirs.

At the checkout lane I choose the PayPal option again and confidently enter my mobile number and my PIN. Expectantly I watch the keypad churning away and it returns with "Card declined, try another payment method."  Huh?  What card? Nevermind, maybe it takes awhile for the PayPal system and the HD payment system to sync up, I'll try next time.

Next time is a couple of days later. (The garden needs a new fence.)  No joy, same "Card declined" message.

So I log into PayPal and look for a way to hook it up and make it work.  Digging into My Account I see I haven't actually linked my Mobile Number to my PayPal account in any useful way.  That login option on the mobile app was just for logging in on the phone, not much else.  I walk through the steps for linking the number, making sure the PIN is the same as the login on the phone.  Done.

Back at HD in the next day or so just to test things now, I try again.  Curses! Foiled again.  Still getting the same message that my "card" has been declined.

What am I missing?  Off to "the google machine" but I cannot find anything other than press releases and news stories about this great matchup between the two companies and how bold and innovative they both are.  Bold and innovative my left toe...more like half-baked and pretty damn frustrating.

At this point I give it a rest.  It's been 2 or 3 weeks of intermittent messing with the thing and since I'm skeptical of the benefit anyway, why bother?  Nevertheless, being an intrepid explorer (did you see that in the title?), I return to the battle armed with a new weapon: duckduckgo.com.  It's an alternative search engine that doesn't track or filter bubble you so the results are just the results.  I type in "Home Depot PayPal setup".

Towards the middle of the results is a link that looks promising.  Holy bullseye, Batman!  Here's a page that is the first step in setting up "In-Store Checkout" for my PayPal account.  It looks very similar to a PayPal page with some blue-gray coloring I haven't seen before.  I press on.

After a couple of clicks on "Continue" and "Start" buttons I am suddenly in a new site.  Well, a new PayPal site I haven't seen before.  Instead of the quaint and familar "/cgi-bin/" directories however I am in a "/webapps/hub" structure.  It's now ALL a murky blue-gray (how appropo) and there is a little "beta" label in one corner.  Nevertheless, I'm now in my account and looking at where I can change the settings for In-Store Checkout.  It knows I have a PIN and phone number linked already and lets me indicate that I can REMEMBER my PIN and will enter it at checkout.  Gosh, will I be able to remember that 4 digit PIN I created and had to look at about 100 times before I got this thing figured out?...\sarc.

I have mail!  Emails arrive telling me that I am FINALLY signed up for In-Store Checkout.  (Quick aside, until I found that sign up page I NEVER saw this whole thing called "In-Store Checkout" anywhere.  It was always just "you can use PayPal at the Home Depot store" and even the button on the checkout screen was labeled "Checkout with PayPal".  Hint:  use clear and consistent terminology and labeling so people know what they're looking for)

Now for another test.  Off to Home Depot to buy something small, like a piece for a garden hose perhaps.  Scan it, tap the PayPal button, put in my mobile number and PIN and...and...presto!  Finallly it works.  I get a paper receipt and another emailed to me (could have had it texted).  NOW we find a use for all this tomfoolery - electronic receipts.

I'm a big receipt keeper because I'm a big returner but am ALWAYS losing them.  Even though HD and Lowe's will pretty much take back anything (and Lowe's has the ability to look up transactions by CC if you lost your receipt), I like the certainty of having an actual receipt when returning.  IF I want to run all my HD transactions through my PayPal account, I don't have to worry about that any more.

On the whole, the signup process is too unclear, too complicated and way too cumbersome for most people to complete.  I only persisted because I work on mobile devices and use HD and PayPal alot and am intrigued by the mixing of the three.  Now, here's the kicker.

When you are logged into your PayPal account, you cannot for love or country find any information about signing up for "In-Store Checkout".  Only if you visit the PayPal home page when you are NOT logged in can you find a link under "Get to Know Paypal" that says "In-Store Checkout" and be on your way to signing up.

Why would I visit the home page and NOT login if I have a PayPal account?  If I visit the home page and do NOT have an account, following that link won't do me any good anyway.  In fact, I use a password-keeper so I never even really see the home page - I breeze right into my account.  So every time I was looking for this stuff while logged in, I had already passed the one chance I had to find anything.

Oh, and one last thing.  Searching for "home depot" on the PayPal site returns, you guessed it, nothing.

It's another example of being oh, so close, but not quite, mobile.

Kroger will print out a coupon with the QR codes for downloading their app on iPhone and Android as you're checking out.  It says the app will help me track my rewards like the points I earn to get gas discounts.  Nifty.  That's the same checkout system that I just entered in my Alternate ID (phone number) for my Kroger Card to track the points I'm earning...I'm really hoping they're linked some how.  Please?

Now I've downloaded the app and it wants me to login so I can track those rewards, see how many points I have and all the rewardy goodness they have to offer.

Do I have a Kroger username and password?  I'm not sure.  No worries.  I'll just tap this Sign Up button and sign up right here on my fully functional apped-up smartphone - it has a virtual keypad for just this sort of thing.

Doh! Seems I have to go to Kroger.com to sign up.  Is that a mobile site?  Aaugh! It's the full web site I see on my tiny phone screen!  The instructions on the phone for signing up even told me to "click" on the Create an Account button...I might have known.

Well you know how this is going to end.  I'm going to have to wait until I'm at a laptop and hopefully remember then to go create an account just so I can use the MOBILE app.

As the kids say, "Seriously?"

Hint to Mr and Mrs Marketing Person:  if you're going to release a mobile app, have a complete mobile experience available.  Enough of this half-a...er, hybrid approach to mobile interactions.

We're at that stage with mobile phone UI's and the unbelievable button-crowding you see in some apps and web sites.  The Apple iOS guidelines are a great resource and place to start.  It suggests you make each tappable thing at least 44 pixels square.  Human factors research determined that was the median/average/typical size of the human index fingertip.

Designers immediately started fudging that guideline and so you're seeing tap targets so small and crowded that my 3 year old can't help fat fingering them.  Her fingertips are about the size of of pencil eraser.  Those apps should have a big "Warning: Tappable objects on this screen are closer together than they appear" stencil on every page.

Now before you get your black turtleneck and beret in a wad Mr Designer, remember you can make the visual elements as small and dainty and elegant as want but give them a bigger tap area for the user.  And the mobile phone is a great design space for minimalists who love white space.  The more white space you use to separate elements, the more separation you can have between tap targets.  Either way you can make things much easier on your users and still showcase your design skills.

Always remember that the user is not like you and that there are some big fingers, fingers that might have a slight tremor in them, fingers that aren't always aimed accurately, fingers in less than optimal viewing conditions, fingers that are being used in a moving vehicle and other situations where a bigger tap target is going to really pay off.

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!

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.

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.