Sunday, October 24, 2010

Designing Drugs

Making medicine for pediatric malaria victims is one of my projects. Our team must design the medicine in order to save lives.

Some problem background. Malaria sickens about 250,000,000 people and outright kills close to 1,000,000 every year. Most deaths are pregnant women or children under the age of five. For every child killed, the disease cripples or mentally impairs perhaps another ten kids. There's no immunity -- victims may suffer malaria multiple times yearly -- and vaccines have been "five years away" for the last fifty years.

We in the U.S. have forgotten malaria was once a scourge here too. We eradicated malaria in the 1950s and 1960s. We killed it with fire, poured oil on swamps, and sprayed entire cities with DDT. Mosquito-borne infections were such a big problem that my home town's mosquito control district existed until 1998.

Bed nets, insecticides, quarantines, abatement programs all work. But when infected, people need treatment to kill the Plasmodium sp. parasites swimming through their veins and laying eggs in their livers and blood cells. Let me restate: there is no immunity to malaria. Victims get it again and again and again every year. Exhausted victims just ... die.

Part of the problem is availability of treatment. Distribution and logistics in malaria-infested regions that are typically remote and rural are sketchy at best, and suppliers contend with black markets, thuggery, and graft.

For young children who can get medicine, its poor usability often bars effective treatment. The medications are giant pills meant for adults. They're meant to be taken in sequence over three days. The come with complex instructions, often in tiny print and in English. Parents and caregivers must break up pills and hope the dosing works for their kids. Too little, and the children remain sick while the parasites start becoming resistant.

The Real Problem

Packaging and package design are critical. We've one answer, depicted on the BioSUNATE™ site and below. Here are some of the design constraints:

  • Packaged drugs must survive the tropics. Heat and humidity degrade the product. In the pharma business, this is known as stability. A minimum two year shelf life is desirable.
  • The patient must take the full three-day course or it won't kill the parasites. This one's hard. In countries where it's possible to buy a single Tylenol™ from a pharmacist, multi-course treatments get broken apart and sold as individual doses, or patients keep some medicine "for later" instead of taking the full required course.
  • Illiterates must be able to use it. The package must convey the dose-to-patient match. Overdoses are as harmful as underdoses. Children, especially young children, are most often mis-dosed.
  • Ethnic and tribal divisions are rife. One people will refuse to take medicine which depicts another people on the box or label. It's not prejudice, it's identification: "Oh, this medicine is for Yorubas, not Igbos."
  • The consumer price must be low. Therapies run US$3-8 in countries where this represents between two days and two weeks wages. This forces the manufacturing price under a dollar.
  • It tastes bad. Really bad. Bitter as poison. Infants and toddlers will spit it out and hence fail to get the full dose.

These problems omit the rest of the issues with setting up a business, finding buyers and suppliers. Fun.

Fixing the Design

We're looking for other solutions, too. The packet design has some flaws: it's easy to split up for resale (three packets are required to complete the course). The taste mask for the active ingredients is bulky. The medicine must be mixed with food or drink and some patients are too sick to eat.

We are also considering development of a melt-in-the mouth medicated strip. Children may take it more readily than having to swallow something.

There's more about what we're doing at CURE Pharmaceutical's BioSUNATE™ site. Ideas are welcome; funding for the project is even more welcome. If you can help with either, contact us at

"Good design" doesn't mean texting your BFF faster or getting the latest game from the app store. "Good design" in this problem means gravely sick kids get the right drug course comprising the right doses of active compound. "Good design" here means a child lives.


WHO Malaria Home Page

Saturday, July 24, 2010

Goldilocks and the Share Bears

Working together on shared information has been goal of the software industry since ... forever. How hard can that be?

Very. The easiest way to share information is simply to give it to someone.  Consider three models:
  • Collaboration suites (SharePoint or Groove) or earlier portals (Plumtree)
  • FTP sites
  • Plain Old File Servers and their WAN cousins (DropBox, SkyDrive)
Sharepoint/portal porridge is too hot. They're great for building corporate departmental sites to contain and control information. They are, however, highly interactive, require developers and administrators to set up and manage, and have an overwhelming number of layout and design options. It's hard to simply put and find stuff with all the interface noise and clutter. Without a design and set-up, they're inert.

FTP porridge is too cold. Users must look whether files are new or old, and working with info means pulling files down to the local desktop. MS Windows can set up an FTP server as a folder in the file system, making it look like a local file set, but files on the servers don't behave the same way as true local files, access times notwithstanding. FTP is close, but clunky.

POFSes pretty much win. DropBox porridge is juuuuuust right. Set up is trivial, accounts are generous (how do these guys make money?), and files sync across dozens and dozens of machines among self, family, and friends, automagically, in the background. That's why DropBox, after several years in business, is finally getting traction in the consumer geek press this summer.

POFSes, done right, just work. They work the way people expect "sharing files" to work. No fancy interface like Groove (which did the same magic file sync), no setting up torrents, no DAV exposed, no "file sharing" monkeying around. Open the folder, work on the file, close the folder. Everyone else sees the same stuff. Just like on a LAN or your own computer.

The Real Problem

People have spent nearly 30 years in WIMP GUIs shuffling info around inside folder/file hierarchies. That's nearly 30 years of unlearning to do.

POFSes also map onto the physical sense of place. The language used to describe actions is place-oriented: "I put the file [over] there"; "she stuck it in this folder here"; "where did you save the sales report?" The notion of place is hard-wired into humans' physical selves.  Even Hansel in "Zoolander" gets it: "The Files are in the Computer."

Chopping information in weblets or interposing app/applets further confuses place with action. Applets add needless extra steps: the resource must first be found, then asked to divulge information. Sticking extra software or processes into the task mix is valuable when that software add control over detail, such as when sharing a calendar. Extra pages, links, access methods, etc, are annoying when the shared items are will understood and their normal operation is familiar, e.g. "open this PDF brochure."

Fixing the Design

Work with what people know. That's one of the basic tenants of good design, along with "don't reinvent the wheel". Trite, but true.

Follow the principle of least surprise. There are no surprises when sharing files in Dropbox. FTP shares as folder extensions have a nasty surprise: opening the file in the folder can cause the file handle to go stale. Saving the file returns a user-surly message which is unhelpful for resolving the problem. It's a message never seen when using "plain old files" on the computer.

Where problems do occur, help fix them. Dropbox users will have problems with conflicting edits. Dropbox doesn't try to resolve conflicts automatically. The system nicely labels conflicted files with the name of the person whose write caused the collision, so folks can call each other to work it out. This model works because conflicts are relatively rare, fewer than 2% of the accesses by my tests.

Drop-dead installation is the icing on the cake. Setting up an FTP or shared portal requires fiddling with logins and credentials on both ends, more with complex controls for permissions and access guards to secured areas. Dropbox pushes this responsbility out and uses a simplified UNIX-like sharing model: me, my friends, everyone else. Easy and done.


Groove Virtual Office

Setting up FTP folders on MS Windows

Dropbox review: File synching for your Mom at Techwizbackup


Thursday, June 24, 2010

Design Fetish and Function Failure

The most devastating comment Don Norman makes about over-design in The Psychology of Everyday Things is that a design is so good "it must have won an award."  The meaning, in context, is that the product looks great but is unusable — it's broken as designed.

Apple and Steve Jobs make a fetish of design.  Their industrial design tradition stresses beauty and  function, especially for casual users and folks who just "want it to work" like my 80-year-old dad.  Kudos.

Apple's new iPhone 4 is a triumph of design over function.  Its slender glass and stainless-steel case has wowed reviewers and fans from the beginning. It's sleek and chic and oh-so-unique.

Apparently it doesn't work very well, too.  The new iPhone dropped communications during Apple's World-Wide Developer's Conference, frustrating even demo-god Mr. Jobs. The problem was blamed on too many wireless signals in the room.

Today (24 June) the phone is being shown to lose signal when merely held "incorrectly":

The problem appears to mystify Apple fans and computer geeks alike.  How did Apple let this one get by?

The Real Problem

My son showed me the above video.  Inspecting the lower-left hand corner of the iPhone 4's case reveals the problem.  When held left-handed, the ball of the thumb covers up a small gap in the stainless-steel band that girds the unit.  This band is Apple's touted integrated antenna.

I'm a software-and-systems guy, not an electrical engineer, but I messed around with radios as a kid.  To anyone who's played with radios, the problem is immediately obvious: touching the gap bridges the antenna.

Antennae work by having a hunk of wire stick one or more ends out.  The free end lets the signal jump from the wire into space, which is why radio antennae are depicted as at right.  Even the goofy tech in Star Wars gets it: recall the antennae that festoon Cloud City's underside in "The Empire Strikes Back".  Their fundamental design saves Luke from plummeting to his death.

Antennae have worked like this since they were first invented by Heinrich Herz in 1888.  On the new iPhone, the user's hand placement appears to couple what look like two antennae on the case, turning them into a closed circuit.  No antenna, no radio signal, and the stylish, sexy iPhone 4 becomes a smaller, less-capable iSlab.

Fixing the Design

If bought already, put a piece of Scotch Tape over the antenna gaps on the case. Wait for someone to make a silicon rubber band that covers the iPhone's antenna/edge. It'll probably retail for $17.95.

Test with people who hold the product in alternate hands.

Put an electrical engineer who has radio experience on the product design team. Steve should be sure his engineer can say "no", then he should listen to him.



30 June 2010 - Apple reportedly is hiring antenna engineers.

2 July 2010 - Apple Admits iPhone 4 Signal Issue, Blames it on Incorrect Signal Display. But Will Software Fix It?

14 July 2010 - Wall Street Journal reports Apple's engineers knew of the problem a year ago, but Steve Jobs forced the design.

14 January 2011 - Computerworld says Apple has redesigned the antenna for Verizon's upcoming roll-out of iPhone service.

9 February 2011 - reports the newly redesigned antenna on the iPhone 4 suffers from "death grip" too.

Sunday, June 20, 2010

"Abort, Retry, Ignore?" -- and Die

All engineering failures -- and disasters -- have a critical human element.  This observation applies across the spectrum: the Challenger shuttle explosion, the BP Macondo well blowout, the aircrash that wiped out Poland's government.

That element: someone in authority overrode the safety checks and ignored advice of those who knew the risks.  Launch directors pushed the launch schedule, BP execs told the drilling engineers to proceed, an air force general told the pilot to land, all despite warnings from rocket engineers, the rig lead, and the pilot and ground control.

Why does this happen?   Because we train people that it's okay to go ahead anyway or offer an option to continue despite a system interlock or warning.

On a microscale, consider system security measures for privacy and identity theft prevention.  How often have users ignored warnings like the one at right:

This warning appears when Outlook 2007 connects to an email server over an encrypted channel.  The purpose of the secure connection is to prevent a bad guy from stealing email identity (login/password) and ensure mail privacy.  But there's no clue about that in this warning, and the temptation is to blithely click through in order to read mail.

Here's another example.  In this case, the browser fails to validate's security certificate.  Multiple reasons could lead to this warning: the browser doesn't know about's certificate authority or the certificate is self-signed.

In both cases, it doesn't matter.  The user is given the option to "go ahead anyhow" and since most people deem reading email as urgent-but-low-risk, they click through to do the task that's uppermost in mind.

Similar messages appear for expired certificates.  Certificates must be renewed periodically, and many business, particularly smaller businesses, forget this administrative chore.  After all, the customers can still get in okay, right?

It makes no difference if the URL location bar turns "green" or the little security lock icon appears locked when security is validated.  The user has already clicked through regardless.  The security interlock has been ignored.

Once habituated to clicking through for email, ignoring warnings for banking, e-commerce, healthcare, government, and other security-required applications becomes second nature.  The "go-ahead, make my day" feature has trained users it's okay and nothing bad will happen.

Until something does.

The Real Problem

Several things are at work.  The total system (browser, application, website, certificate authority) offers a way to go ahead instead of enforcing the lockout and requiring the user to go to lengths to verify the security of the situation. Second, the reasons for the warning are obscure as it's assumed the user understands how certificates work. The onus is on the user to evaluate the risk without complete information or understanding the underlying causes.  Last, the user is likely under time pressure or other constraint to make a decision quickly and "just get on with it".

In short, the overall design permits a dangerous action by someone who is uninformed about the root problem and who lacks the training and patience needed to understand the matter and judge risks.

The built-in assumption is that value and convenience override all. The lesson drawn and reinforced: it's okay to ignore warnings because likely nothing will happen. So thus, a security blow-out.

Fixing the Design

This one is simple: make the security interlock positive and hard.  Never make it simple for someone to obviate.  Will it inconvenience people?  Yes.  Will they take the time to fix it by calling and complaining?  Maybe.  Will they leave the application, website, or abandon their task?  Likely, but that puts the onus on certificate owners and application and website managers to keep their stuff up to date and working.

Make applications and sites work securely from any URL in the domain.   Certificates are inexpensive and serve to advertise and secure the brand.  There's no excuse for (for example) to cheap-out on a cert for the domain   Even if this domain isn't the final target (, buy a cert to avoid seeing this screen, then bounce the customer from the former to the latter.

Applications must offer an alternate path in the event of a lock-out.  The alternate path must inform the user what to do and whom to contact to correct the situation.  The information must be meaningful, helpful, and lead to a positive resolution of the problem, e.g., call this toll-free number to talk to our security division of customer service.  The goal is to correct the defect, not override it.

Last, inform the user about what's going on, what the risks are, and the "what to do next" alternate path. The generic security warning screen in Firefox 3.6 is much better than Internet Explorer 8 (above).  It cannot solve the problem with Amazon's website, but at least it explains why the problem occurred and offers a reasonable workaround, in this case, the URL of the correct site.

The first two references discuss the impact of and cite the same Carnegie Mellon University study, "Crying Wolf: An Empirical Study of SSL Warning Effectiveness".


28 June 2010 - Sean Kerner at eSecurity Planet reports a Qualys study suggesting that of 92 million active domains, 23 million were running SSL. Of those, 22 million had invalid certificates. See "SSL Certificates in Use Today Aren't All Valid".

Monday, May 17, 2010

Login AWOL

How do I log-in? Web sites that demand logins often make it hard to do so. Many make it hard to determine whether the user is logging in once inside the site. Why?

The New York Times gets it right. LOGIN and user session information appears clearly on every page. As a bonus features, a social tool drops down to show who's following you and what other Times readers recommend.

The Wall Street Journal used to be confusing and The Washington Post gets it wrong. It's in tiny type at the Post; LOGIN must be hunted down on the page. The WSJ has finally moved it from mid page somewhere on the right and it no longer disappears completely when the user navigates away from pay-walled pages.

Facebook gets it really right; it's the foundation of the whole business, of course.

The IEEE universe of websites is improving. To be sure, the IEEE relies on volunteers to create and maintain its collection of sites and services. Moving among societies and journals within the IEEE context used to be a LOGIN safari. A universal header and navigation control is helping.

Where is ACM's LOGIN? Buried somewhere under a tab. For a leader in Human Computer Interactions, hiding LOGIN is unfriendly to say the least and belies the mission to improve computing's utility.

Worse LOGIN encumbrances exist.

Some companies treat their customer's logins with contempt. For over a decade I held a login and profile at The Los Angeles Times site. In April 2010 and with minimal warning to its "valued customers", the paper ditched its logins in favor of those established on social networking sites, a cross-marketing play.

In an instant, The Times not only made it harder to log in but also severed the relationship between my identity and my editorial comments, news letters, and other onsite material. The site offered no opportunity to recover. Everything apparently needed to be re-entered and reconnected to LOGINs I may or may not wish to associate with my Times subscription. The frustration is best expressed by Search Engine Land's Danny Sullivan. He simply unsubscribed.

The Real Problem

LOGIN offers little value for many sites. It's a step to capturing demographic info which is usually sold and resold to marketers in aggregate. A login's approximate value: $0.37. Less than a postage stamp.

For the end-user or customer, however, LOGIN is a welcoming step. It signifies a willingness to belong and support a service or site, to join the community and identify with it. Signing up implies a social contract: I tell you about me and entrust you with that knowledge, you treat me like a friend and keep my info in reasonable confidence. No one likes a gossip.

LOGIN is a missed opportunity. Web 2.0 social sites and smart(er) vendor sites intertwine a welcoming LOGIN into the fabric of their information. It's not always about extracting maximum sales from a customer, but maximum value. A happy LOGIN tells three other LOGINs how to join; an unhappy LOGIN tells 20 others why they should keep away.

Happily, LOGIN registrations are becoming more streamlined. Instead of demanding names, addresses, phone numbers, birth dates (!), and other details marketers covet, a simple name/email/password triplet has become enough. Customers may volunteer additional info by optionally completing a profile later. People share more information as their trust in friendships and involvement grow.

Fixing the Design

If a website offers no premium for logging in, don't. Don't create user accounts. Don't demand identification or other personal information at all. Use a tracking service instead. Chances are the service is much, much better at it.

To create a customer relationship, optionally offer a login. Don't make it a requirement to complete transactions or find free information. I have abandoned many, many shopping carts because their sites forced me to register before checking out. No one has ever registered at McDonald's in order to get lunch. I have money and am willing to pay, what more is wanted? Pointless registration retards transactions.

Make it easy to log in and know I'm logged in. Don't hide LOGIN. Put it on every page if I'm not logged in. Replace the login box or widget with my name when I am logged in. And put the LOGOUT right next to my name so I know I can close my session, especially if I'm using a public or shared system.

Keep all the LOGIN/LOGOUT/User features in the same, visually-stable location on every page. Hunting for this information on a new page or section on the site is time consuming and annoying.

Last, treat login identities as what they represent: a social contract. They represent people and their good will. Friends never betray friends and a lifetime of trust can evaporate in an instant.


Sunday, April 4, 2010

Hurry up and Outsource

The program director handed me a thick document. "Could you guys look at this contract and give us a thumbs-up?"

"What's it for?"

"We're going with another service desk vendor. We need to sign this contract Friday."

It was Tuesday afternoon. "All my people are busy on other projects. Why the rush now?"

"We need it by Friday to make the deadline." (Whose?) "Just look at the technical stuff."

"We'll do what we can."

Wednesday, after some Quality Coffee and Fireside Time with his 120-plus pages, I returned it to the still-anxious director.

Bear bad news first. "Won't work. Don't sign Friday."

"What? Why? We've been working this out for more than two months."

"Look, sorry." In addition to several glaring contractual oversights (fodder for another post), the contract omitted a critical data requirement. The vendor's system had no way to know who was calling the help desk. Responsibility for the data exchange had been left out.

We went over the other details together. Not a good day, but not terrible. At least we caught it.

The Real Problem

Getting lost in requirement and design details almost always works to an outsourcing vendor's advantage. Design elements not explicitly spelled out in the contract become change orders.

Even at an agreed-to rate change orders cost a premium. They stretch out the contract because the customer has already bought in and fears losing the investment. They're the icing on the cake.

Software or system change orders are best. Now the vendor has an reason to start an engineering development project. New rounds of consultation with the system specialists, software engineers, architects, programming teams, project managers, and others begin, all billable. Even better is a change order so big the vendor brings in third-parties to fulfill the request and passes through their costs plus the vendors overhead. It's a rent.

Change orders also drive the in-house staff crazy. Wasn't the vendor supposed to take care of this problem? Why are we doing our work and their work too? Wasn't this supposed to save money?

Meanwhile, if the project is in implementation phase, good reason exists to miss the start-up deadline and press for the "on-time delivery" performance bonus. After all, the customer ordered the change; it isn't the vendor's glitch that made the project late.

The process design must be as complete as possible before contracting. It's especially hard when outsourcing services because the service boundaries may be loosely defined. The services drive the data and reporting requirements. Get these right before thinking about the details of, say, file transfer mechanisms.

Fixing the Design

Separate the contract into at least two pieces: legal boiler plate, and specifications, requirements, and design components. The boilerplate should reference the other document(s) as part of the binding contract.

Put the business and technical people to work on the design specs and the legal people to work on the boilerplate. Even if the final contract must be a single, unified document, the right folks will be looking at the right pieces instead of getting distracted by irrelevant work.

Go over the processes and hand-offs to find what information goes to whom, and who calls when. If it's within the team's skill set, I strongly recommend making a high-level UML Sequence Diagram to show these hand-offs. Flow charts can quickly become confusing and they obscure responsibilities.

Be sure the contract indicates who "owns" what pieces, of course. But also specify acceptance criteria on both sides, if possible.

The service desk project delayed three weeks until a new contract with the necessary changes went through.


Sunday, March 14, 2010

Problems On and Off

Some time ago my sister called with an urgent question. "The battery on my new iPod keeps running out. I have to leave it plugged in all the time."

"So turn it off when you're not using it."

"I don't know how to do that. There's no OFF button."


I hadn't an iPod, but I did have an iPod Shuffle. The Shuffle had a simple slider switch with three positions: off, on, and shuffle. On played recordings sequentially, shuffle arbitrarily. The volume control on the earpiece cable had clear labels: + (louder) and - (quieter). Anyone could understand the device's operation after experimenting less than 5 minutes.

I had no clue how to turn off her iPod.

I asked my son who also had an iPod Classic. "Oh yeah, hold down the play button until it turns off."


Keeping in theme, let me offer that my sister is not broken.  She's a Ph.D. psychologist (Fuller Seminary), holds a license to practice in California, and, at the time of her query, ministered to the mentally ill in California's maximum security prisons. She had purchased the unit to listen to recordings needed to fulfill her continuing education requirement. She could not turn off the unit because it has no OFF button.

The Real Problem

As do many devices, the iPod Classic switches on whenever the user presses any control button. It switches off only when the user presses and holds a specific button. Its design violates the natural mapping of a symmetric operation, ON/OFF.

Consider most houses' lighting switches. Switch placement is usually handy to a room's entrance. ON/OFF is simple and clear: a single movement and its reverse control the light. The action is symmetric and compact.

Now imagine a room in which any action — turning the door handle, touching a wall panel, opening a door, clapping — turns on the lights, but to turn them off residents must find, touch, and hold a small panel labelled light. What would happen?

That's right: the lights in the room would burn forever. Lamps and other devices, just like my sister's iPod, would remain on, constantly chewing power. No one would bother to turn them off because it was too much trouble to find the light switch.

There is no energy crisis. There is an OFF button crisis.

Today it's so easy to turn stuff on, so easy in fact that now many things turn themselves on. What people cannot figure out is how to turn stuff off. People have given up in frustration. They no longer care that stuff is still on and they just leave the room.

Fixing the Design

ON/OFF is a critical function. When something goes wrong, it's the "kill" switch, the switch of last resort. For example, automotive "unintended acceleration" incidents would halt (or happen less often) if drivers had the presence of mind to switch the ignition off. The engine would die and any mis-application of the throttle pedal would cease to speed the car. OFF saves lives.

Good ON/OFF control design must
  • make the control distinct (keep it apart from other functions);
  • make the control compact (locate it in a one spot);
  • ensure the control is prominent (put it where it's easy to find); and,
  • be clearly labelled (unmistakably identify it).
Will these rules ruin "smooth" industrial design? Perhaps. But the customers will be able to turn off their machines and the world will be a quieter place.


Special note: Happy Pi day!

Sunday, February 14, 2010

Deliciously Simple

I love In-N-Out Burger.

I'm in good company. Top chef Gordon Ramsay loves In-N-Out too.

The food is delicious. It's hot, freshly made from fresh ingredients (onion, lettuce, tomato, unfrozen meat, whole potatoes), made to order, inexpensive, and fast. What else is there to love?

Its design. Its design is genius.

First, the name of the restaurant tells you absolutely everything you need to know about it: they serve hamburger sandwiches and service is fast. If you wanted a crispy fried chicken caesar salad, you came to the wrong place, buckeroo. Why on earth did you walk in here?

Second, the In-N-Out menu reflects the brand's elegant simplicity. In-N-Out serves burgers, fries, and drinks. Period. If a customer cannot figure out this menu, they're really, really in the wrong place. That, or unfamiliar with the Roman alphabet and Arabic numerals.

Third, the restaurants are the same. In-N-Out has, from what I have seen in my wanderings, three store styles: small (now no longer being built), average, and a large version at travel centers along highway locations. The company knows everything about its stores, from how many staffers needed per shift down to the number of palm-tree logo tiles needed to build the dining room.

Last, and most importantly, In-N-Out has a "hidden" menu. You can get a burger built any way you want. If In-N-Out has the ingredients and can figure out how to charge for it, they do it. If you are super hungry, order a "four by four". Low-carbing it? Order "protein style". Your vegetarian friends can order a "grilled cheese". For a special treat, order "fries well done, animal style". You'll need two people to eat it.

In-N-Out is the Unix of fast food joints.

The Real Problem

Needless choice is the enemy of fast food. Or fast anything.

Walk into a McDonald's, Burger King, KFC, Jack-in-the-Box, Taco Bell, or Sonic restaurant. I almost guarantee you'll peruse the menu for three minutes before you capitulate to the confusion and order the #1 SuperValueGulp combo. If you are someone's kid, Dad, Mom, or Coach orders you a McJacko King Meal #1 with a Little Ice Ogre Princess movie toy to shut you up.

Yes the goody-goody Diet Police have forced major chains to fluff their menus with "healthy choices" the public refuses to buy (it's fast food not health food). But the choice overload is not entirely accidental. The high margin items are fries and soft drinks, the loss leaders are meat and fresh items. And the soft drinks are self-serve, further lowering labor costs. You can select a nutritious, low-calorie meal from the Dollar-O-Rama menu but you cannot assemble it mentally, so you pick #1. Partially, this is why you're fat.

Proof? In-N-Out has three combo meals: my local McDonald's, eight (or is it ten?). Anything more than seven overloads short-term memory, and you'll likely go with the one in the top left-hand corner. #1. And who doesn't want to be #1?

Fixing the Design

There are two design lessons here.

The first is honest and direct. Make it simple. Make the choices distinct, easy to find, and valuably differentiable. Do you want the one year subscription for $80 or the two year subscription for $120, a $40 savings?

You can always generate value by cross-selling, upselling, or customizing. Keep the customer (or user) happy by telling him the choices clearly and making the results apparent. A happy customer/user is a retained customer/user, a confident customer/user. Happy people lower customer acquisition, training, and time-on-task costs. Build it into the business, workflow, or process model.

Customers value knowing that what they purchased came fairly priced. Clarity seems fair; the vendor isn't hiding anything. Saturn Motors started this way very successfully.

The second lesson is that the dazed and confused buyer will usually default to something (eventually, if hungry enough). If that something has lots of calming whitespace around it so it stands out from the noise, that's what s/he will purchase. The sales cycle will be longer, however, as the buyer's mental mouse traverses the maze of options before reaching the cheese.

Or the mouse could abandon its quest and walk next door to get a Double-Double cheeseburger at In-N-Out.


Sunday, January 17, 2010

Can You Feel Me Now?

General-purpose touch-screen devices have delighted users since the HP-150 debuted in the early 1980s. Today, three years after the iPhone's introduction, nearly all "smart" mobile telephones have touch screens and their interfaces force interaction almost exclusively through this means.

Which is great unless the user is a fat-fingered, myopic palsy victim.

I upgraded from a Moto RAZR v3 to an LG Xenon (AT&T) this year. I wanted the keyboard because I am fat-fingered, myopic, and now thanks to middle age, presbyopic (TANJ!). Despite the tiny keyboard, the interface seems to demand I use the touch screen to accomplish most tasks.

My daughter taunts, "Daddy, you're such a slow texter."

"Bite me, kid. I'm a QWERTY touch typist and T9 sucks at 1337."

The crux of the problem is this: the touch screen doesn't feel me. The screen's touch points, despite training, are inaccurate or unresponsive. Forget typing via touch screen using 'ABC' or T9 mode. Sometimes I jab it several times to get it to read once.

The reason is my fingertips are callused, their skin dry. If I lick the tip of my pinkie and use that finger, it works great. Of necessity I've personalized the phone with my own slobber. Ew.

For whom are these touch interfaces designed? Tiny, moist-fingered kogyaru? Racoons?

The Real Problem

Humans vary widely in size and physiology, as do the environmental conditions under which they work. Interfaces must work under these conditions, too, or offer clear workarounds when they cannot.

Vendors of course put the cheapest interface device into the phones because phones are disposable commodities. My LG Xenon cost nothing on promotion so long as I signed up for another two year tour of duty aboard the Death Star Phone Company.

The Getting Started guide that ships with the AT&T-branded LG Xenon is a thick pamphlet with little info. The 146-page version of the full manual, once hunted down online, offers a list of features matched to buttons and screen symbols, but no help for sending a text message when the on-screen send touchpoint won't react. After a hour's fiddling it turns out that pressing the SEND key (labelled with a green telephone handset icon) steps through the SMS select destination and transmit message sequence.

Happily, the HANGUP key (labelled with a red handset symbol) is the go back in sequence key. Except when it isn't.

Fixing the Design

Designers must consider more than happy path operation when the device offers multiple physical interfaces. By comparison, Microsoft does multiple interface paths well enough. They code and document keyboard shortcuts that make Windows fully usable without a mouse.

Test interfaces with various pointing device types, widths, and surfaces. Fingers may be wide or slender, wet, dry, greasy, sticky, dirty, bloody, or damaged and misshapen. Styli may be fingernails, real nails, pens, pencils, pencil erasers, screwdrivers, paper clips, dowels, coffee stirrers, and so forth.

Try operating them under common, real-world environmental conditions. Range from humid to dry and include insult conditions such as heat, cold, drizzle or rain, soda pop and coffee spills, oil, grease (skin lotion or sunblock), and paint (fingernail polish). Is the phone usable after Junior scribbles over the touchscreen with a Sharpie?

What is the workaround if the touchscreen fails to react altogether? For many applications, the phone is now bricked. Not so bad if a replacement is available, but potentially lethal in an emergency situation, say, after an automobile crash.

Document not just the feature set and the normal way of operating, but also the alternate, non-touchscreen method for getting work done. It's only paper.

And please, ship the real manual with the product. At least print the URL on the box.


Monday, January 4, 2010


"URRRRAGHH! DAMNIT! I KEEP GETTING PWNED!! I just can't play this game."

"What the hell, dude."

My second son had come home from UCSD over winter break. We had just rebuilt one of his machines to modernize it for gaming. We had set up his rig in my office so he could relax from his double major (Physics/Math) and lab responsibilities by playing "Call of Duty: Modern Warfare 2".

I looked over at his screen. He was playing online in a team. Target identifiers in pastel green and pink flashed over other players as they popped in and out of view. How handy: IFF for grunts. Totally unrealistic and totally useless for my son.

He's colorblind.

Not profoundly, but with enough red/green confusion to make the transparent target tags indistinct, and especially indistinct when they briefly flash during a mêlée.

In-game avatars are unbelievably swift and jumpy. Coupled with lag and server processing time, it may be too late to aim and fire anyhow, and especially too late if a player's reaction loop requires him/her to figure out something's color.

Double pwned.

The Real Problem

Between 5 and 10% of caucasian males are colorblind. Since most live in North America and Europe, their 18- to 34-year-old demographic is exactly who buys and plays games like CoD:MW2.

InfinityWard, CoD:MW2's producer, has knee-capped 1 in 12 customers.

It's just about unforgivable. Red-green confusion has been known since the 90s, that is, the 1790s. The US military started testing for it in the 70s, again, that is the 1870s.

To make matters worse, much of the in-game heads-up display renders info in reds, greens, and yellows with a high alpha blend, making them transparent. CoD:MW2 also places HUD items at the visual periphery of the screen. HUD placement and coloring makes them useless for colorblind players and difficult for everyone else, too.

Here's why: human peripheral vision has very little color sensitivity. Try it yourself: hold a small red or green colored lamp (an LED is ideal) a meter away and view it from the corner of your eye. I defy you to answer honestly what color it is when viewed from that vantage. It should appear somewhat yellowish-bright, nothing more. Now, try this experiment with the indicator lamps on your car's dashboard. You will appreciate (or despair) that the layout makes clear (or obscures) the meaning of each lamp.

Fixing the Design

Red-green confusion and its fixes are so well known that InfinityWard's design lapse is astonishing. This defect should never have made it to the marketplace — unless, of course, the company has a military contract to discover who's unfit for duty.

An easy patch: replace green with blue.

Next easiest: make a distinct mark or shape part of the target HUD; don't require the viewer to read it. There's a reason why financial statements indicate negative numbers in parentheses: they jump out without color.

Ensure peripheral information displays distinctly so it works from the corner of the eye. On a single screen, where the focal area and attention are close, vision detects color and shape reasonably well. As screens enlarge or become multipanel as in AMD's Eyefinity, moving visual cues outward will significantly degrade their color visibility.

And know the market. Don't kneecap your customers.