As a Canadian I was concerned about taking on US-based consulting customers as I wasn’t clear on what that meant from a Visa standpoint.  So I researched the heck out of this, including looking at the Bureau of Consular Affairs, the US Customs and Border Protection Agency, and the US Visa Service websites.  I spoke with an expert cross-border accountant to ensure I understood the tax situation too.  I thought I had my bases covered.

Earlier this month I collected my documents together as I was travelling into the US for business and wanted to make sure I wouldn’t have any problems at the airport.  I ensured I had a copy of my contract as I knew from experience that if they get really picky then being able to review the contract itself was very helpful.  I knew I was going to be crossing under the NAFTA agreement and I felt I had everything I needed.

You know those moments in your life when a small decision results in a schism in your life?  I had one of those moments when I walked up to the front of the CBA security line.  Two kiosks emptied out at the same time, and both agents called me over.  I decided to go right and thanked the agent on the left.  I wonder what would have happened in I had gone left ….

The CBA agent felt that since I would be earning money in the US I needed a Visa, which meant I needed to go into secondary containment.  No problem, I’ve had this happen before and came out the other side.  I had planned ahead and had over 1.5 hours before my flight was due to leave, so I wasn’t too concerned.  After waiting for 15 or 20 minutes I was called into the interview room and told that I did not have a Visa so I would not be entering the US today.  I was, to put it plainly, floored.  I explained that I was going to do a meet and greet and not actually do productive work.  “Doesn’t matter,” he said, “If a US company is paying you and a US company is benefiting from your activities, you need a Visa.”  OK, can we proceed with getting the Visa then, here is my contract showing the terms of my employment, just like the online resources explained.  “No good,” he said, “it is not on official company letterhead.”

I’m sorry?  What?

“Yeah, it has the same information but it has to be phrased as a request addressed to the CBA, and has to be on official company letterhead.”

The CBA agent carefully explained that I needed to call and make an appointment ahead of time, to pay the application fee, and to bring along all the documents including the letterhead one so I could properly apply for a Visa.

Well you can’t really argue your way into a foreign country so I took careful notes of what was expected according to him.  I then spent 1.5 hours being questioned about the details of my life, my family, and my desire to enter the country; was digitally fingerprinted; and finally escorted by armed guard outside the airport’s secure area.  Good day!

I have since called the appropriate people for clarification because the websites say things like

When a citizen of Canada requests to be a TN with an application for admission, the applicant must present a letter or similar statement signed by the employer indicating the position, salary, employment location, and requested length of employment. (CBP Website)

See that “similar statement” part there?  Yeah, ignore that – simply not reliable.

So the Consular office cleared things up for me.  They said that if I were to go through the application process as suggested by the CBA agent, here is how it would go:

1. Pay $140 application fee
2. Attend office for appointment
3. Wait in waiting room with all the other applicants
4. Periodically someone will come out and ask all Canadians to raise their hands
5. Everyone raising their hands would be sent home – they don’t give Visas to Canadians.  Stop wasting their time.

This made sense and jived with statements on their website like:

Canadian citizens usually do not need a visa as a NAFTA Professional.

So where does this leave me?  Simple – I need to bring all these documents with me (letter of employment on original letterhead with authentic signature, my contract, my university degree (not a copy, the original), etc) and present myself at the airport CBA again, on the day of travel, requesting to be granted access with a TN Visa.  I will then go through the evaluation and the CBA agent will decide if I receive a Visa or not.  There is no guarantee, nor is there anything I can do ahead of time (beyond gathering these documents) to help my chances of getting in.

So the moral of the story?  Speaking with someone on the phone is still a better way to understand Visa requirements than reading their FAQs, online resources, and all that other junk.

Another moral (can a story have two morals?!?): Sometimes one person’s bad day can spill over into your own – don’t soak up that negative energy!  A setback is only as influential as you make it.

Take for example this job posted on craigslist for a “User Experience Business Analyst“.  I actually came across this job opportunity through another avenue, though that avenue did not let me know that Fujitsu was involved, nor that the domain was related to transit.  It is not that rare to come across relatively secretive postings on one site only to be able to find additional details about the job on another site.  Sometimes the parallels are relatively obvious like specific position names or the wording of the position’s responsibilities. Other times the positions just “feel” the same. You develop a sense for these things after a while, I suspect.

This position sounds right up my alley – UX is a key component of business analysis. It is nice to see the overt combination of responsibilities in a single role. So how is this an example of a “flag” posting? What about it makes me say “Meh, too bad”, and move on?  Let me quote the posting … there’s something important right down there at the bottom.

Please address all email inquiries in .doc or .docx (WORD) format…

If your company only accepts applications that require the use of proprietary and expensive software, that in the end does not assure me that my resume, cover letter, and portfolio will look exactly the same on your monitor as it does on mine … well … that actually speaks deeply to a corporate culture that I am not interested in participating in.

Too bad, it looked like an interesting contract ….

• Word Smart (verbal linguistic) – capacity to use words effectively in speaking and writing
• Number Smart (logical-mathematical) – capability to use numbers effectively and reason well
• Picture Smart (spatial) – thinking in pictures and images and the ability to perceive, transform and recreate different aspects of the visual-spatial world
• Body Smart (bodily-kinesthetic) – expertise in controlling one’s body movements and handling objects skillfully
• Music Smart (musical) – capacity to perceive, appreciate and produce rhythms and melodies
• People Smart (interpersonal) – ability to understand and work with other people
• Self Smart (intrapersonal) – self-knowledge and the ability to use that self-understanding to enrich and guide one’s life
• Nature Smart (naturalist) – sensitivity to and understanding of the natural world

There have been additional areas proposed since Howard Gardner, Harvard psychologist, developed this theory of “multiple intelligences” almost 30 years ago. They include spirituality, humour, and creativity. The theory has not been well received and has not been clinically proven to be true.

So why am I writing about it? Well, I think it is an interesting take on intelligence and emphasizes the need to accommodate different ways of learning. And this naturally leads me to discuss learnability – see how I did that? It really does make sense in the end!

A key element of a usable and intuitively-used software product is that it is easily learnable by its target users. Often the target users are roughly defined as generalized roles and other times they are more thoroughly defined via archetypes or personas. Oftentimes a persona will include some description of the persona’s level of comfort and familiarity with technology and computers, to try to outline for the project team just how learnable the product has to be. If the target user is an advanced computer user who likes keyboard shortcuts then the team should design it differently than if the target user is a novice user who is uncomfortable with technology overall.

This is where the multiple intelligences comes in, or more accurately the multiple means of learning. When designing a product to be extremely learnable and easy to use, are we falsely assuming a particular kind of intelligence is used by the user? Are we, for example, assuming that all novice users learn in a manner consistent with a person with a high “word smart” intelligence? Are we imagining that clear, concise, and plain words in the instructions will help the user learn how to use the interface? I’m sure anyone familiar with user testing can relate a story or two where the user simply refused to look at the text on the screen when trying to figure out how to accomplish their task. Are these people then simply not highly “word smart”? Another example may be that we assume that including large pictures and diagrams in the interface will help the user learn how best to get their work done. We’ve all seen those “Quick Start” guides that come with new electronic products nowadays – are they a panacea or are they simply catering to people with a high degree of “picture smarts”?

Another question: are there areas of intelligence that we are ignoring, and if so what would that mean? Would it mean that no matter how pretty our design and how clear our words, some users just won’t understand how to use the system because they learn by doing (i.e. high body smarts)?  Should we look at self-guided tutorials then?

It might be interesting to look through the areas of intelligence and try to look at the product’s design from that point of view, to see if it is learnable from numerous points of view.

It might also be interesting to incorporate and expand on this idea when defining personas or users. For example we could focus more on mental models than on comfort levels with technology in order to capture learnability requirements. What if we began creating new types of intelligences that were specific to our product or software development – is there value in that? For example:

• Exploration Smart (curiosity) – eager to explore new ideas without fear of failure
• Domain Smart (subject matter expert) – very knowledgeable about the domain
• Interconnection Smart (integration) – easily grasps how things fit and work together to accomplish a greater goal

In the end this post is about looking at how we measure, design for, and evaluate learnability in our products. I suspect many would agree that a single approach does not seem to be robust enough to rely on 100% of the time. Perhaps there are new ways of looking at learnability and capturing this knowledge in our user definitions. Or perhaps Howard Gardner was a nut and this whole idea is out to lunch. If that’s the case then we should fall back on the universally-accepted theory of learning styles. Oh wait, that article alone lists at least 5 “models” – I don’t think people have figured this stuff out yet. So no harm in trying it out to see how it works – right?  I guess I would be highly “Exploration Smart”.

Last month I came across a cautionary tale related to consistency. If you create one way of doing something, there is a strong lure to re-use that way whenever possible. This reduces development costs and design costs – both good things to reduce when it makes sense. However this leads to times where your re-used design may be applied in places where it doesn’t quite fit. In fact it might even be applied in places that result in poor usability. This can be particularly true when you’re near the end of a project and “good enough” has become the best you can expect.

How do you avoid this? Ensure that your design is well tested by real users. It is an old refrain but it is a good one – test, test, and test again. If you find that design re-use is resulting in bad experiences, poor performance of the interface, or seems challenging to the user then you have some very strong arguments for updating the design. Without the testing you’re left with a bad feeling and perhaps some alternative designs that will be “looked at in the next release”.

Frankly the scam came on pretty hard and was fairly convincing.  I only have one computer running Windows in my house and it runs Windows 7 which I’m not terribly familiar with.  That sneaking doubt came into my mind as I listened to this fellow’s claims that it was infected.  In my first call I ended up sussing out the claim and found the faults that indicated that it was a scam.  I sent a message to a variety of places and the Peace Arch News contacted me and ran an article about my experiences.

Since then, I have been called a couple of times by the same scam artists.  This last time I decided to push back and see just what the deal was.  I also happened to record part of my conversation.  I spent some minutes with the initial call and then asked to be escalated to their manager.  That’s where the video picks up.

This scam is fairly insidious and convincing.  It also can be horribly damaging as you are giving them complete access and control to your computer.  I just wish there was a way to track these companies down to stop them permanently.

I’d like to take a closer look at these two options, and propose a few solutions for future project teams to consider.

Round 1 – Scope Wins
A product can almost never reach its full potential when it is first released, nor upon successive releases.  The truth of the matter is that people can envision the next cool or useful feature much quicker than anyone can code and test it.  In fact your competitors are most likely putting those cool features into their next version while you are trying to put out the latest version of software designed to hit feature parity in the market.  Not only does your product’s next version need the blinking lights and rounded corners – it needs to differentiate itself in the market.

So the idea of removing planned features, of putting out a product that actually offers less functionality than the competition is seemingly a hard one to get behind.  This is the wall that usability efforts often come up against.  Almost everyone agrees that having a usable and intuitive product is a good idea, if not a great idea.  However it is difficult to quantify the value of “usable” and “intuitive” for many UX teams.  The product is late, the existing customers are tired of waiting for enhancements, and the market seems to be moving too fast to keep up.  So naturally scope wins here – you want to put out a product with features, and no bugs (keeps those support costs down).  Best efforts will be done to incorporate usability efforts, but only when there’s time and resources available.

Round 2 – Usability Wins
People love great software. Today most computer users are drenched in software. They are inundated with new applications on a daily basis via appStores, product reviews, software suggestions from friends, and any number of online software repositories such as SourceForge and GitHub. So how do your users determine which software they will continue to use? There’s a strong hint in Apple’s AppStore – a random sampling of 5 applications is almost guaranteed to include 4 applications that claim to be “intuitive” or “simple”. The truth is that people aren’t looking for an application – they’re looking for a solution to their problem. And guess what? People want to solve problems, but they’re oftentimes not willing to work very hard at it. In other words, your software must be something the user will actually use. Call it intuitive, call it low barrier to entry, short learning curve – whatever. If your users aren’t enjoying using your software they will find ways to not use it – simple as that. And what do you call users that don’t use your software? That’s right – potential users a.k.a. “Back to Square 1″.

So where does usability come in here? In a general sense, usability helps to ensure that your users will find your software useful. If you aren’t running usability tests with neophyte users you’ve probably missing out on the fact that there’s a major problem with a part of your software that will result in the user getting frustrated and returning to other alternatives. If you’re not ensuring that the user’s goal is satisfied in the software then you can stuff as many features into it as you want but people still won’t use it. Features are important, but only if done right.

So Now What?
The two descriptions above paint a rather ominous picture. Don’t despair though – its not as bad as it seems. There are some things that can be done to avoid having to make the call between these two idea(l)s.

1. Bake in usability. When doing your project planning you need to figure out the scope of the project, the effort required to attain the milestones – all that good stuff.  It is extremely important that you also consult with a usability expert to find out how much effort is required from a usability standpoint to bring the project to a successful end.  Ensure that sufficient time is planned to allow for usability testing, design exploration, user consultations, survey – whatever is needed in your project.  Include that time in your project planning – they are vital project activities.
2. Take usability seriously – it is a skill. Don’t just assume that your Visual Designer will be providing a usable interface. Ensure that you get effort estimates and planning input from someone with both knowledge and skills in interaction design and usability.  This could very well be your Visual Designer, but don’t make the assumption that anyone working in the “UI” understands and applies usability and user-centered development best practices.
3. Incorporate usability into your requirements.  Requirements are a key part of software development.  They help guide the team towards the desired end point by describing the problem to be solved and how to solve it.  Should the requirements not also describe who is going to use the end product, in what setting, to achieve what goals?  ISO seems to think so.  Consider documenting interaction and usability-related requirements as part of your business and software requirements.
4. Leverage testing. Testing your software is an accepted and often required practice.  Leverage the fact that someone is going to be “touching” almost every part of your code while testing it.  Can you find users to help validate your software while also verifying it?  Sure it works as specified, but does it work as intended and as needed by actual users?  What is your release criteria for the end product?  Does it incorporate the idea of validating the end product?  Would your testing uncover a critical usability issue and can you hold up release until it is fixed?

But My Project Is Already Underway!

The ideas above are most helpful when planning a project, and fall somewhat short of helpful if you’re already enmeshed in the day-to-day grind of a project.  So is all lost for those projects that weren’t able to give some early thought to usability?  Not at all, but my advice gets a little less straight forward in these situations.  A few thoughts to consider:

1. What does success mean anyways? Look at what are the success criteria set forth by the key project stakeholders.  If the product were to come out with all its scoped-in features but fell flat in front of users as too complex or obtuse, would the project still be a success?  This is not a glib question – the answer will be yes for some of you.  There’s always release 2, as some say.  But often it can be possible to look back at those initial success criteria set out for the product and argue that some features could be moved to the next release in order to ensure that the first release is successful enough.  Hopefully successful enough to merit a second release.
2. Get some outside help. Don’t tell the UX union I said this, but I think it is SOMETIMES possible to bolt on usability, just a little bit.  That little bit is better than nothing and can often go a long way towards a better product.  Look into getting a limited engagement with a UX expert, perhaps just a simple heuristic evaluation could help.  Perhaps the team just needs some rough personas to help galvanize and focus their thinking about the user’s needs.  UX doesn’t have to be glitzy and involve fireworks – sometimes little bits help and the slush fund could be put to good use.
3. Involve UX in scope decisions. Your UX team should have the best grasp on what the user’s interaction needs are.  Your BAs (if a separate team) will know the user’s needs.  Together these two skillsets and knowledge bases should be used to help make the right scope decisions.  If a feature must be included UX may be able to figure out a quick and easy way to get it “good enough”.  It may not be the dreamt-of vision but it will get the job done, ensuring your users get their job done.  UX may also identify some features as being high risk in terms of design and usability.  Use this to help refine scope as you go.  Choose your risk rather than finding out once the product is released that you unknowingly gambled on uncertain design decisions.

Scope and usability are two competing ideas, but they are not mutually exclusive.  You can have both, given appropriate planning and determination.

Needed help figuring out what channels I record the most.  Help in IRC pointed me to the exact line of code where a related product issued the exact query I was looking for.

I am a strong advocate of Open Source projects and those who choose to work on them.  Just this week I was involved in a great example of how this different approach to software products can enhance the user/customer’s experience.I have (and love) a home-built PVR.  I run the massively awesome MythTV software that puts to shame a number of commercially offered PVR software products.  MythTV is an open sourced project, allowing anyone with the inking to review the code that runs under it slickly-themed hood.  I wanted to find out what channels I’ve recorded the most over the last year – to help me understand the family’s habits and evaluate TV bundles.  I knew enough to look at the database tables but not enough to figure out how to create a sql query to extract the info.

I hopped onto the mythtv IRC channel and asked if anyone knew of an existing query.  Sure enough the web client had the query tucked away in its code somewhere.  The suggestion was to just grab it from the code.  A minute later a participant in the IRC chat provided me with a URL that took me to the exact line of code in my web browser.  Now that was just awesome.  A little sql tinkering later and I had what I needed.

Contrast that with what a closed source product might offer in terms of supporting my need.  Can you imagine me calling a support center and being given access to the code?  Or even access to the database schema?  At best I could hope for someone to offer me the chance to pay a one-time fee to have a custom script written to extract that info from my own database.

A perfect example of how an open source product can offer a better customer experience than a closed source one.  I’ll explore this contrast a little more in future thoughts.

This is true though in many situations in our lives.  Oftentimes we are simply too close to the problem to be able to evaluate it effectively anymore.  At times this can become so strong that we can be blind to an optimal solution even when it is right in front of us.  We can spend a lot of time, money, and energy trying to solve a problem simply because we see no other option when in reality, a fresh perspective could point out a simple, elegant, and achievable solution.

Here’s another example – I really like to go for bike rides when the weather permits.  Here in Vancouver the weather doesn’t really permit all that often, so I’ve taken to wearing a couple of layers for my rides: one to wick sweat and the other to block wind.  In order to avoid overheating I wear a wind-blocking vest.  The combination works for the most part, but it usually results in really cold hands and arms.  Earlier in the spring I would wear gloves that quickly became too hot.  I persisted with this “imperfect solution” as I enjoyed the outdoor ride much more than a stationary bike inside – something was better than nothing.  I wanted to solve this problem though.  How could I continue to ride in cold weather wearing multiple layers, without overheating or becoming too uncomfortable?  I was certain that if I could just find the right gear I could figure this out: some kind of fancy wicking wind-proof top that could keep my arms warm but not too warm …  I was stumped though.  Everything felt like a compromise and not a solution.

Then my wife said something that stopped me in my tracks.  She and I were taking the kids out for the first ride as a family and she was considering wearing a long-sleeved shirt.  Wait – what?  A long sleeved shirt … that wicks … and covers my arms … and that can be rolled up if my arms get too hot … that blocks the wind … of course!  And the very next time I went out riding in the cold wind I wore an old long-sleeved shirt.  And it worked perfectly.

So my wife’s “fresh perspective” proved invaluable – it solved a problem that I, in my blindness, felt was unsolvable.  I was too close to the problem, had too much invested in it.

The trick is to open yourself up to your “external expert voices” – these points of view that have no background in the problem, no history, no knowledge of the blood, sweat and tears that have been shed in arriving at this point.   If you are stumped with a problem, find someone who hasn’t the faintest idea about what you’ve been going through and ask for their advice.  At worst you will get advice that you can ignore, but at best you will find you’ve been blinded by proximity, and a solution will come to light.  As any good BA knows – ignorance can be powerful.