Here’s the question: Does automatically generated interfaces — based on user skill, dexterity, and impairments — have a place in Firefox?

The University of Washington recently released a program called Supple. Essentially, it puts you through a small digital obstacle course — move your cursor here, click there — and then calculates all of your motor-skill constants: what’s the difference between your single and double click, how quickly can you target a button on screen, what’s your reaction time, etc. Once it has all of the data, it generates an interface to match your particular set of skills.

Although this loosely falls into the adaptive interface category, it doesn’t have the normal problems associated with adaptive interfaces because it only adapts once. (more…)

Question

A simple and effective concept from Toyota is Poka-yoke, or mistake-proofing. Products and Interfaces are context-sensitive — that is, products and interface features have a particular purpose , but I’m curious if you can share any generic context-agnostic approaches to mistake-proofing, or Poka-Yoke? Principles of Poka-yoke you can apply to anything; to any product or interface?

Answer

An interface is humane if it is responsive to human needs and considerate of human frailties.  We make mistakes.  No matter how hard we try to concentrate and prevent errors, errors will happen when our concentration wanes or when we are forced to do something that is beyond our cognitive abilities like multi-tasking: the act of consciously thinking about two things at once — and, with the use of Queueing Theory & Little’s Law, we learn that multi-tasking leads to lower productivity.

Poka-Yoke is an excellent method of making a process more efficient and humane by being considerate of human frailties: we won’t always be thinking about which way a part fits in, so design the part in a antisymmetric way so that it can only be installed correctly.

Shigeo Shingo, the originator of poke-yoke, wrote “Defects arise because errors are made; the two have a cause-and-effect relationship…yet errors will not turn into defects if feedback and action take place at the error stage”.  In other words, users make mistakes, but those mistakes are detrimental only if they aren’t corrected immediately.  One context-agnostic principle of humane interface design is summed up in the mantra “Never Use a Warning When You Mean Undo“.  If you make a mistake, no big deal.  Just undo it.

For example, a common Poka-Yoke style method is to cover an important switch so that it cannot be bumped accidentally. But, what happens if you use that switch all the time? You’ll either leave the cover open or flick-the-cover-open-and-flip-the-switch as a single gesture. In the computer world, we often have the advantage over the real-world in being able to undo. So that even though you just ran the smash-the-car-into-the-wall safety test while the technician was inside, you can just go back to the way it was before.

If Poka-Yoke was practiced more in interface design our lives on the computer would be a lot less stressful.

I just spent the last couple of days in Beijing, working with the wonderful folks from Mozilla China, meeting with the major tech players, and covertly observing user behavior with other UI researchers in internet cafes. It was on of the most intense learning experiences I’ve been through in recent memory.

This is a brain dump, in no particular order, or some of the observations from the trip.

(more…)

Golem.de, one of the preeminent sites for technology in Germany, wanted to know more about how we design interfaces. As we passed through the reconstructed space-station-from-the-future C-Base, they caught up with us for an interview.

All thanks go to Jane Finette for all the hard-work in setting everything up, and Golem.de founder Jens Ihlenfeld for the questions and great discussions that unfortunately weren’t captured on film.

I’ve been remiss in blogging as often as I should. To try to combat this, I’ll be doing an “Ask Aza” thing once a week. Pose questions about design, Firefox, Ubiquity, Mozilla Labs, life, whatever and I’ll do my best to give cogent, non-sleep deprived answers. Feel free to shoot me an email with your questions aza [at] mozilla [dot] com, or leave them in the comments.

The first question comes from a reader of www.shmula.com, which is where the idea of the weekly thing started.

Question

I work as a product manager for a technology company in the valley.  In large companies like mine, the department of Product Management, Software Engineering, and Customer Experience work together, but in a clunky way, to build a product.  What is the best way, in your opinion, to infuse the humane design principles in a hot political environment?

For example, the classic problems of: product will define a feature based on market research and define the personas.  Engineering feels like we define something and “throw it over the fence” to them to develop.  At the same time, Customer Experience is bothered that Product Management didn’t involve them, etc.

My question is turning out to be more of a human resources question than about design, but wanted your thoughts.

Maybe you should start an “Ask Aza” column, like a Dr. Phil segment, or something.

Answer

Successfully bringing a product to market is a holistic endeavor.  User requirements drives customer experience; customer experience drives marketing; marketing drives user requirements.  Nobody should feel that a set of requirements has been “thrown over the fence”.  When this happens, the recipient-of-the-throw is beholden to an abstract deliverable and is no longer connected to the end-user.  That’s a real problem.  Combating this requires a tight-feedback loop which is most easily created with a small team: engineering gets to see the market research come in, and the usability people can guide engineering throughout the actual creation process.

In an ideal world, everyone on the team would have a foot in engineering, design, and marketing.  Unfortunately, this isn’t always possible.  What is possible is that we can create small, tight teams that collectively have intimate knowledge of all three disciplines.

The small-team idea is by no means new.  In the book In Search of Excellence, Tom Peters explains over-and-over again that it’s the small groups; skunk works, home-brew projects, and strike teams that drive innovation at companies both large and small.  The most successful teams are those of 10 people or less — preferably between 4 and 8 — that include people from the required disciplines.

By keeping teams small, products don’t get commitee-ized.  The team is directly responsible for success.  Success is dependent on making a product that meets the needs of the user and to the user, the interface is the product.

P.S.,  I like the idea of an “Ask Aza” column: Anything that’s alliterative must be good!