Learning from other people's mistakes

"There, but for the grace of God, go I" - John Bradford

When faced with coming up with new site ideas or designs, it can help to look at examples of brilliant design.  When examining the specifics of a Google map interface, or how Apple designs its sales pages, you know that teams of the brightest minds have worked to compile some of the best content available today.

There are times when bending to the extreme can be just as helpful, and this is where the fine people at webpagesthatsuck.com leap to the rescue!

I came across this site while taking a lynda.com course from Sue Jenkins, and it continues to provide both laughs and lessons.

Vincent Flanders compiles a list of laughably bad websites and while mockery on the internet is nothing new, the author actually includes a clear explanation of the errors being made and why to avoid them.

An example is this review of the gif-laden interpretation of the afterlife.  Perhaps this was meant to be an artistic piece and not entirely an educational web page, but the lessons to be learned here are substantial.  Apart from the obvious (avoid flashy graphics that could cause seizures) are subtler lessons about not taking away the users ability to scroll under any circumstance and to include some navigation so they can derive context from your content.

Of course, part of the fun is in gawking at the painful mistakes of others, though the opportunity to do so while actually learning something about design is worthwhile.

Living with complexity

Don Norman's book The Design of Everyday Things has become a touchstone for those of us with a penchant for design.  It has introduced hundreds of thousands to his elegant view of the world and uncanny ability to pinpoint the essence of why some things just FEEL well designed.

His most recent book, Living with Complexity continues along those same lines, though pursuing a contrary tack to popular thinking.  Despite the growing popularity of stripped down, simple designs, Norman argues that simplicity is not always the right direction to take for a design.

Norman references Tessler's law of the conservation of complexity, which states that every application has an inherent level of irreducible complexity.  The only question is who will have to deal with it: the user or the developer.

He argues for a moderate view saying that some complexity is OK, even preferred.  Objects that are too simple can be boring, while things that are too complex are confusing or upsetting.

This discussion of simple versus complex is playing out now in the mobile software space.  Sophia Voychehovski, a UX designer for Turner, says the idea that mobile users are 'on-the-go' and therefore don't want or need the capabilities of the desktop site on their mobile device is false.

She said that users today don't want or prefer a stripped down version for mobile.  They don't want things simple in this context...they want equivalent functionality presented in an intuitive way.

Going further, overly simplified software also faces the danger of feeling too flimsy.  The lean startup concept of the minimally viable product has led to a series of software attempts that are flashy yet flimsy in the hope of attracting further funding.  In some cases, I find that overly simplified interfaces seem to feel more gimmicky than elegant.

It can be too easy for companies to see the work of Google and Apple and assume that a stripped down interface is what symbolizes a modern company.  Their examples, while simplified, reflect deep design work that caters to the well-researched needs of users...and the requisite complexity is just a layer or two away for those experienced users that crave the ability to tinker with the specifics.

Life has no error messages, Norman points out, and in this way software should emulate life more closely.  In life, if you try to fill a five gallon bucket with eight gallons of water, it'll overflow and you'll see water spill out.  There is no error message, you just see the result in front of you.  Instead of scolding the user for not following the parameters of its software, well-designed code should assist the user in how best to continue.

It is specifically in that moment, right as the user has taken a mis-step that they are most receptive to learning: they can learn best when they face the need to learn.

This reminds me of the implementation model Alan Cooper discusses, in which a software interface reflects the inner processes of the software instead of presenting only those options that correlate with what the majority of users are trying to accomplish.  The two men's ideas taken together advocate for software that helps users complete their goals while reflecting the requisite complexity behind the tool being used.

Striking that balance between elegant simplicity and overwhelming detail continues to be a challenge for user experience designers, and Norman's book helps to crystallize those issues into a continuing discussion of the merits of each.

The Inmates are Running the Asylum

Alan Cooper begins with a clear analogy: in all other construction disciplines the architects and engineers plan the construction strategy and the craftsmen execute that strategy.   It is only in software that the craftsman is also the architect.

This becomes the basis for his premise that The Inmates are Running the Asylum. Cooper argues that we are deficient in our development process, not the development tools themselves.

"Programmers aren't evil" he insists, "they work hard to make their software easy to use.  Unfortunately their frame of reference is themselves, so they only make it easy for other software engineers, not for normal human beings."

Alan Cooper, being a former software developer himself, discusses why he believes software developers ill equipped to design usable software:

Clearly, one side of software - the inside - must be written with technical expertise and sensitivity to the needs of computers.  But equally clear, the other side of the software - the outside - must be written with social expertise and sensitivity to the needs of people.  It is my contention that programmers can do the former, but it takes interaction designers to do the latter.

The intuitive thinking here is that since developers know the software at it's most granular, then would be best equipped to ferret out usability concerns.  While intuitive, Cooper shows the fallacy of the argument throughout the book.  The skills that make for excellent programmers are not complementary to those needed to uncover and address usability issues.

Software developers (who he refers to as Homo Logicus) are different from normal humans.  Cooper defines the specific characteristics that make for great software developers work against them when trying to address usability issues.  For example, developers:

• trade simplicity for control
• exchange success for understanding
• focus on what is possible to the exclusion of what is probable
• act like jocks

On the third point he says that obsession with edge cases makes great programmers, but poor usability.  Normal people care most about likely uses/situations, "whereas programming is defined by cases at the edge of the paradigm, design is defined at the center."

I've found that it can often be easy to be lulled into the belief that working with a product on a daily basis means that you instantly know how new people will use it.  While it's tempting to believe that's true, it's also completely wrong.

Jared Spool says that the best companies (Apple, Disney, Netflix among others) are great companies because of their focus on feedback among other things.  He says he tests companies by asking random employees if, in the last 6 weeks, they have spent at least 2 hours watching someone using your design, or a competitor's design.  He asks this of everyone who influences the design.  Not just programmers or usability experts, but the entire team.

Great companies realize how easy it is to lose focus on what your users go through, and these sessions provide the opportunity for everyone on the product to see how people interact with it.  It's crucial to have people from all over the company participate, because those people will notice something that the UX team or the developers may miss from being buried in the details.

While the details can make something ordinary into something transcendent, they can also narrow your focus so much as to lose site of the broader picture.  It's crucial to have developers who obsess over those details...great developers have the genetic code that replays the details of a problem over and over again until the solution works itself out...but that same characteristic can also lead you lose sight of what's important: how typical customers interact with your product.

And no amount of brilliant design can bring back a customer who has tried and been turned off by your product.

Alan Cooper on Agile

I'm reading Alan Cooper's The Inmates are Running the Asylum, and his outlook on the use (or mis-use) of agile was especially poignant to me.

Alan Cooper, like many other designers, views agile as a potentially valuable, though horribly misused process.  The use of agile methodology as a reason to just throw features at users and let them design your product is insulting, inefficient, and ineffective.  If the design isn't done before the programming starts it will never have much effect.

"Just because customer feedback improves your understanding of your product or service, you cannot then deduce that it is efficient, cheap, or even effective to toss random features at your customers and see which ones are liked and which ones are disliked... 

[This manager believes] that his customers don't mind plowing through his guesses to do his design work for him.  There might be lots of ["power users"] who are willing to help this lazy executive figure out his business, but how many struggling [average users] did he alienate with that haughty attitude? 

As he posted sketchy version after sketchy version of his site, reacting only to those people with the stamina to return to it, how many customers did he lose permanently? 

...The biggest drawback, of course, is that you immediate scare away all [the average users], and your only remaining users will be ["power users"].  This seriously skews the nature and quality of your feedback, condemning you to a clientele of technoid ["power users"], which is a relatively small segment. 

I am not saying that you cannot learn from trial and error, but those trials should be informed by something more than random chance and should begin from a well-thought-out solution, not an overnight hack.  Otherwise it's just giving lazy or ignorant businesspeople license to abuse customers."

Design, he argues, is tasked with creating a product that can be built and perform well; that can be distributed and sold profitably, and that makes a success by being something people really want.

Far too often the paradigm of agile is used as an excuse for managers to get more code quickly...somehow arguing that lean practices and agile methodology are good reasons to forgo the crucial work of considerate thought and design.

These people, while acting on a good faith basis to prevent over-analysis and reams of documents from delaying the actual development work on a project, have failed in the other direction: no planning and no documents at all.  While well intentioned, this is the same mistake just taken to the opposite, perverse extreme.

This is not an improvement, or striking a bold step toward progress...it is blindly fumbling your way toward completion, making completely avoidable mistakes along the way.  I think Cooper encapsulates that nicely in the above selection.

Don't Make me Think!

Steve Krug is as adamant a defender of simplicity as you'll find anywhere:

The point is, when we're using the Web every question mark adds to our cognitive workload, distracting our attention from the task at hand.  The distinctions may be slight but they add up, and sometimes it doesn't take much to throw us...The fact that the people who built the site didn't care enough to make things obvious - and easy - can erode our confidence in the site and its publishers. (Don't Make Me Think, p15)

In their relationships with others, people keep an internal account of good and bad deeds done to them by others.  That account isn't a concrete list of things, but more of a general sense of whether this person has treated him/her well or not.  It's a concept Steven Covey calls an Emotional Bank Account.

The evolution of technology has gone much faster than the biological evolution of the brain.  Because of that, a fundamental portion of our brains can't distinguish between actual faces and faces shown on a screen.

Likewise, that same part of the brain can't distinguish between interactions with technological objects and other people which fosters a tendency to develop feelings about those faces and objects.  (Remember the last time you cussed at a computer? Kinda makes sense now, doesn't it)

One of the ways to help build a positive relationship between the user and your site is to pass what Krug calls the trunk test in his book Don't Make Me Think.

He argues that thoughtfully designed sites should make it easy for you to find most of the following six elements (though not every one is on every page): Site ID, Page Name, Section and subsection, Local navigation, "You are Here" indicator(s), and Search.  On the left is an example from the book.

He calls it the trunk test to equate arriving on a new site to being abducted, blindfolded, thrown into the trunk of a car, then driven to a field and dropped off in unfamiliar territory.

Since Google is responsible for getting most people to new unfamiliar sites, he says the same sense of disorientation happens to people when they encounter a new site, and having most of these elements easily identifiable and available can help ease users quickly feel more familiar with their surroundngs.

I found when designing my first wireframes from scratch that these guideposts were incredibly helpful.  There is a lot of web design that should be new and innovative, but this book helps to ground the beginner in the basics of those helpful conventions that let users feel more at ease.

Running technology

This is the story of how something as low-tech as putting one foot in front of the other wouldn't have become a hobby for me if not for technology.

You see, I was always the slowest kid in class. Not intellectually, but physically. I'm velocity-challenged. One year, in elementary school we had something called "Field Day" where the whole school did different physical activities for ribbons. Let's just say parents were not surprised when I came home with only a participation ribbon.

About 5 years ago I was working in a newsroom in Phoenix and I got a call from Nike. They wanted us to try out their new Nike+ system, so they asked my shoe size and sent me a pair of shoes with a tracking chip in them. The chip allows you to track how fast you run, how far you run, and shows you graphs of how much you've progressed.

I tried it for a week, and I was hooked. For all those times the PE teachers in school had made us run, it took a tiny little chip to pique my interest. Instead of feeling like the slow kid, I just felt like I was accomplishing something, and those graphs proved it. First 10, then 20, the 50 and a hundred miles!

I later moved around and stopped running as much as I used to. It was just in the past year or so that I decided to get back in to running. I'd decided to quit smoking, and running was a good complement to quitting. If you want a quick reminder of how bad smoking is for you, try smoking a bunch of cigarettes one night, then going for a run the next day.

I realized, though, that I didn't have a plan. I knew I didn't have it in me to just go outside and run a couple miles, but I didn't know where to start. That's when I found the "Couch to 5K" running plan (sometimes abbreviated C25K). This plan, posted at coolrunning.com, has helped thousands of people running a full 5K distance (about 3 miles) in around two months.

The plan has you walk a bit, then run, then walk to catch you breath, then run...and each week the amount of running increases and the amount of walking decreases until you eventually can run the whole way.

The concept was clear to me, but I still didn't have an easy way to know when to run and walk. I didn't want to jog around with a slip of paper and a stopwatch, timing each motion exactly. That's when I found the brilliant Robert Ullrey. He had the idea to create a Couch to 5K podcast, and this idea alone makes him a superhero in my book.

Instead of jogging around with a pad and a stopwatch, he just recorded some upbeat music, and tells you in the podcast when to walk and when to run. He even included a 5 minute warm up and cool down (which I still do now). All you need to do is press play and go. I've tried to find him on the Internet to email him a note of thanks, but the site was posted several years ago, and he doesn't seem to have any working contact information anymore.

Thanks to the podcast, I've run several 5Ks now, and even ran a 10K in Atlanta on the 4th of July. I had set a goal of running it in under an hour, and I did it! But I seemed to stop improving. Running was getting a bit tedious, and it felt like no matter how fast I ran when I trained, I just couldn't run much faster.

For Christmas I got the Polar FT4 heart rate monitor. I chose it because it has a strap that goes around your chest to measure your heart rate, and a watch that displays it and stores the data. An added bonus: the strap talks to most cardio equipment in the gym, so you can just wear the strap, and the machine knows its you, and shows your heart rate on the display.

So, I decided to run another 10K with this fancy device, and it taught me that I've been running too fast. My maximum heart rate is 191, which means I should be training at around 133 to 143 beats per minute. Another series of calculations showed me that my optimal fat burning zone is around 151 bpm. Problem is, every time I ran, my heart rate was, on average, at 171. I'd discovered why I was getting burned out: I was running too fast.

At first, keeping my heart rate at 151 was really challenging. I was barely running...it almost felt like I could walk faster than I was running...but after a few weeks I could run much faster while keeping my heart rate at the same level. This meant my body was getting better conditioned to running, and it made running longer distances immensely easier. Tedious, because I barely felt like I was moving at first, but definitely doable.

Now I'm training for a half marathon (it's coming up on March 7th!) and that heart rate monitor (along with the beginner's half marathon training plan from coolrunning.com) have been my new savior. I did a 10 mile run last week, and I wouldn't have been able to come close to that if I were still running so fast.

So, now I'm not that last one to finish anymore. I may never win a trophy for running, but I did win a second place medal at my first 5K...my first ever award for anything physical in my life. And I owe it mostly to technology. Oh, and Robert Ullrey.

Gmail protects me from myself

The lists of common-sense things to do to protect your computer have been around for years: choose a secure password, don't download suspicious software, constantly run and update virus protection, protect yourself from spy ware.

Despite knowing this advice, I haven't always followed it. Sometimes I download stuff that I haven't checked thoroughly, or I have a simple password to access things I don't use very often. And, for all of my online life I haven't had a problem. Until recently.

Somehow my email was compromised and everyone on my contact list was sent a link to some strange Russian porn site.

That should be the end of it...now my email is done for, and I've got to come up with another address to use. But no...Google sniffed out the problem and did a few clever things to help protect me.

First, they noticed the account was sending out a lot of messages, and stopped the account from being able to send anything out. Then, in order for me to log in again, I had to jump through a lot of hoops (asking questions about what I put down as my personal information) then sent a text message to the number I had listed as my phone number and made me enter it in.

Then, once I had regained access they encouraged me to set up 2-step access. I've always been interested in information security, and the nerdy things smart people can do to keep information safe. The US intelligence agencies use special rooms called SCIFs (pronounced skiffs) to discuss classified information and have specially configured blackberries that allow for access to classified email systems. Google, of course, can't reconfigure the equipment we use, but they can take

advantage of the equipment we have.

Once you're forced to change your password, Google asks you input information about your phone, and if it's a blackberry, iPhone

or other certain smart phones it encourages you to download a program that generates a random 6 digit number every minute.

To configure the program, you take a picture of a QR code (like the one shown to the right) with your phone, and the software translates the image into the information it needs to assign the random numbers to your specific account.

Then, once your phone is configured, you need to enter the 6 digit code the first time you log in to your account. Google recognizes the computers you use on a regular basis, and only makes you put in the code about once a month once it's configured.

Then in a final turn of brilliance, they find 2 ways to help you access your email should you phone go missing. First they ask for a backup number they could send the access information to (as a text message or even a voice mail) and then they employ a form of encryption developed almost a hundred years ago: the one time pad.

US intelligence agencies needed a way to communicate secret information, and a guy named Gilbert who worked for AT&T had the idea of using a randomly generated series of numbers to encrypt messages. The sender would have a list of numbers on a small pad of paper and would shift each letter down the alphabet a number of places. The recipient would have the same list of numbers, and could decipher the message by undoing the change the sender made. After each message, you destroy the page you used and sue the next list of numbers for the next message.

Since the only two people who know how many positions each letter was shifted, and the number is random each time it's virtually impossible to crack. Google takes advantage of this, and as a last resort, if you lose access to your account you are given a list of 10 numbers you are supposed to keep in your wallet. If you don't have you phone, and the other techniques don't work, you use this one time pad to get back in to your account. Clever right?

I'm relieved the geniuses at Google protected me from my, well, dunceness.