Aza Raskin on Cooperation & Fence Throwing

by Pete Abilla on November 7, 2007

Aza Raskin is the founder of Humanized, the son of Macintosh inventor, Jef Raskin, and an all-around good guy.  A few months ago, Aza Raskin agreed to answer several readers’ questions.   In today’s post, Aza Raskin tackles a reader’s question about Product Management, cooperations with other groups, throwing stuff over the fence, why large teams generally suck, and political in-fighting and politics.

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.

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!

Aza’s point above about team size is important, and one that I’ve discussed before.  Quantitatively, we can show why, in general, large teams aren’t the best way to go.  Here is what I wrote back in Ocotober 15, 2006:

Stinky Large Teams: A Proof

I’ve written about the importance of team size before, here, here, and here. Previously, this is what I said:

I’ve written about efficient teams before here and here. At Amazon, there is a concept of a 2-pizza team: no team should be larger than 2 pizzas can feed. It’s a great approach to team size. In my short career, I’ve learned how true that rule is. Here’s another thing I’ve learned –

  • 2 people are smarter than one
  • 3, 4, 5, 6, 7, 8 people are smarter than 2
  • a team larger than 9 people is just one big dumb blob

Ok, that’s not true at a wholesale level, but it sure feels like it. A small team with highly smart and capable team members can do much more than 10 mediocre team members.  The Wisdom of Crowds mentality doesn’t work that well when it comes to efficiency in teams — especially software teams.

A more quantitative explanation is as follows:

One of the root causes of failure in projects is communication — either a lack thereof, or miscommunication.  Large teams are inherently vehicles for bad communication.  This is basic combinatorics — for a given project, suppose there are persons A and B. In this scenario there is only 1 communication link. Add person C, now we have 3 communication links, A-B, B-C, C-A. Add person D, then we have 6; Add person E, then we have 10 communication links. Inductively, as team size grows, the raw combinatoric communication link counts grows geometrically, not linearly. To demonstrate this, we use basic statistics of the form n-choose-r, where !, such as n!, is equivalent to n factorial, to arrive at the formula for how many pairs we can choose from n items:

shmula.com, combinatorics

For the number of pairs, we can reduce the above formula to the following:

shmula.com, combinatorics

Visually, as team size grows, the communication links grows non-linearly, but exponentially:

shmula.com, combinatorics

A Rejoinder

Do not let the above dissuade you from large teams; if the product requires a large team, then that is what is needed. Caution, is what I am arguing here. The facts are that the larger the team, the more communication channels there are and the entire process then becomes more error-prone. If the product requires a large team, then expect the above challenge and manage it.

A Conclusion

There is wisdom in Bezos’ notion of the 2-Pizza Team.  Small teams work incredibly well.  Also, there is wisdom in Toyota’s usage of “The Big Room” as a way to mitigate defects caused by large teams.  A combining of the two will most likely make for a great team and a successful product.

+++++

Other articles in the "Ask Aza Raskin" Series:

  1. Ask Aza Raskin
  2. Aza Raskin on Poka-Yoke & The Humane Interface
  3. Aza Raskin on Quasimodal Design and The ATM
  4. Aza on Feature-Bloat and Site Clutter
  5. Aza on Google Search Results Page
  6. Aza on Cooperation and Team Size

+++++

Articles on Queueing Theory

+++++

For articles on Operations, lean and six sigma, please visit the links below:

{ 1 comment }

Aza Raskin on Google Search Results

by Pete Abilla on November 6, 2007

In a previous post on Ethnography, I invited Aza Raskin, founder of Humanized and son of Jef Raskin, the inventor of the Macintosh and author of The Humane Interface: New Directions for Designing Interactive Systems — to possibly answer reader’s questions about design, visual management, ethnography, genchi genbutsu, man-machine interactions, or anything related.  Several readers responded with interesting questions for Aza.  In today’s post, Aza Raskin responds to a reader’s question about Google Search Results page and how messy it is.

The Google search box is simple, clean, and intuitive. BUT, the search results, from what customers tell us is confusing and messy as hell. How do you suggest we clean up the natural search and the paid search results?  Is there a more intuitive way of doing it?  Thanks — A Googler

Ironically, one of the fundamental goal of interaction designers is to reduce interaction.  When we do our jobs perfectly, few people ever notice (except when comparing your solution to other products).

In this light, I would make one suggestion: remove the pagination from the Google search results.  At best, its somewhat annoying to click through the pages, and at worst its aggravating trying to remember which page had the result you are looking for. One of Google’s magics is the extremely fast loading times, and I understand that loading long pages takes a long time. The solution is a good implementation of an non-intrusive infinite scroll.

As a side note, playful touches make a great interface into home-run products (as long as playful doesn’t become annoying). I like the elongation of "Goooooooogle". That’s a great playful touch. That should be kept in some form.

Other articles in the "Ask Aza Raskin" Series:

  1. Ask Aza Raskin
  2. Aza Raskin on Poka-Yoke & The Humane Interface
  3. Aza Raskin on Quasimodal Design and The ATM
  4. Aza on Feature-Bloat and Site Clutter
  5. Aza on Google Search Results Page

+++++

Articles on Queueing Theory

+++++

For articles on Operations, lean and six sigma, please visit the links below:

{ 0 comments }

Aza Raskin on Quasimodal Design & The ATM

by Pete Abilla on August 21, 2007

In a previous post on Ethnography, I invited Aza Raskin, founder of Humanized, a company that designs more humane products — from consumer packaged goods to software interfaces — and, son of Jef Raskin, the inventor of the Macintosh and author of The Humane Interface: New Directions for Designing Interactive Systems — to possibly answer reader’s questions about design, visual management, ethnography, genchi genbutsu, man-machine interactions, or anything related.  Several readers responded with interesting questions for Aza.  In today’s post, Aza Raskin responds to a reader’s question regarding the interface of Automated Teller Machines (ATM) and a quasimodal and more humane approach to design.

Aza, the following picture was taken by a friend. It is an ATM at an airport.  I know the image is difficult to see, but would love your thoughts on the interface of this ATM machine.

aza raskin, quasimodal design, humane interface

Below is Aza’s response to this reader:

Here’s how the machines like the one in the picture normally work:

(1) Feed your card into the machine. The ATM eats the card, quarter-inch by quarter-inch.
(2) Now that the card has been read, you enter your PIN.
(3) Select how much money you want to withdraw.
(4) Take your cash.
(5) The ATM spits out your card and you take it. If you don’t take it, the machine beeps incessantly.

Despite the beeping, I have forgotten my card in such machines. The problem stems from a mode: the credit card is either in your possession, or being read by the ATM.  As is almost always the case when a direct solution to a mode is required, the solution is to use a quasimode.  The user should perform a kinesthetically active action while the card is being read by the machine.  Such actions can be unwieldy and impractical (like pressing a foot pedal) or they can be simple and effective (like holding onto the card).

Citibank ATMs do this well — they ask you to dip or swipe your card.  This forces you to be touching the card during the entire time in which the the card is being read.  With the quasimodal solution, you won’t ever forget your card (unless you are foolish enough to set the card down).

Other articles in the "Ask Aza Raskin" Series:

  1. Ask Aza Raskin
  2. Aza Raskin on Poka-Yoke & The Humane Interface
  3. Aza Raskin on Quasimodal Design and The ATM

{ 3 comments }

Aza Raskin on Poka-Yoke & Humane Interfaces

by Pete Abilla on August 19, 2007

In a previous post on Ethnography, I invited Aza Raskin, founder of Humanized, a company that designs more humane products — from consumer packaged goods to software interfaces — and, son of Jef Raskin, the inventor of the Macintosh and author of The Humane Interface: New Directions for Designing Interactive Systems — to possibly answer reader’s questions about design, visual management, ethnography, genchi genbutsu, man-machine interactions, or anything related.  Several readers responded with interesting questions for Aza.  In today’s post, Aza Raskin explicates on the Poka-Yoke and how it can be effectively applied to user interfaces.

We lean fans spend a lot of time explaining how great Toyota is.  And great they are.  See what I mean?  We can’t help ourselves.  Anyhow, I am interested in your thoughts related to the way Toyota deals with interfaces, etc.  I personally have two Toyota vehicles in my driveway and love them.  But I was recently in my brother in laws new Camry and noticed they made some rather big changes to the way things looked and felt inside. I dare say things looked a little un-Toyota-like.

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?

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 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.

Other articles in the "Ask Aza Raskin" Series:

  1. Ask Aza Raskin
  2. Aza Raskin on Poka-Yoke & The Humane Interface
  3. Aza Raskin on Quasimodal Design and The ATM

{ 2 comments }

Humane Interface – Ask Aza Raskin Anything!

by Pete Abilla on June 21, 2007

In a previous post on Ethnography, I invited Aza Raskin, founder of Humanized, a consultancy that aims to help companies design more humane products — from consumer packaged goods to software interfaces — and, son of Jef Raskin, the inventor of the Macintosh and author of The Humane Interface: New Directions for Designing Interactive Systems — to possibly answer reader’s questions about design, visual management, ethnography, genchi genbutsu, man-machine interactions, or anything related.  He accepted!

Students of the Toyota Production System will quickly see the very close parallels between humane design and the way Toyota approaches their treatment of people, work environments, and business. 

A little more about Aza:

Aza brings over six years of interface design and consulting experience to Humanized.  He gave his first talk on interface design at his local San Francisco chapter of SIGCHI at the age of 13, got hooked, and has been speaking ever since.  By the age of 17, he was talking and consulting internationally; by age 19, he was coauthoring a physics textbook because he was too young to buy alcohol; and at age 21, he started drinking alcohol and co-founded Humanized.  Aza has also done Dark Matter research at both Tokyo University and the University of Chicago, from where he graduated with honors in math and physics. For recreation, he does Judo, speaks Japanese, and invents in his lab. He also enjoys playing the French Horn, which has taken him all over the world as a soloist. Be warned: Aza is an incorrigible punster, so please do not incorrige.

Here’s What You Do

If you have a question for Aza, please submit them in the comment section of this post.  I will keep comments open until ~midnight of June 30, 2007.  Aza will take some time to answer those questions, and then I will begin posting his responses during the week of July 9, 2007. 

Humane Interface Philosophy

1.  It’s not your fault.

The main thing you have to remember—and please remember this, because it could be vital to your sanity—is that any problems you have with an interface are not your fault. If you have trouble using your microwave, it’s not because you’re "not good with technology", it’s because the people in charge of designing the interface for that microwave didn’t do their job right. User interface design is incredibly hard, and carries with it a great deal of responsibility; this is something that’s taken quite seriously when it comes life-critical systems such as flight control software. But in today’s consumer culture, what should be blamed on bad interface design is instead blamed on the "incompetence" of users. Just remember that it’s not your fault.

2.  Simple things should stay simple.

Some tasks—for instance, teaching a child arithmetic—are intrinsically pretty complicated. But some aren’t. Setting the time on a wristwatch, for instance, shouldn’t be that hard; on old analog wristwatches, it basically involved pulling out a knob, twisting it until the watch showed the correct time, and pushing the knob back in again. But on newer digital wristwatches—ones that claim to be more powerful and feature-loaded than their analog counterparts—it involves pressing a series of buttons in a hard-to-remember, often unforgiving order. Most people dread setting the time on their digital watches, and for good reason.

It’s right and proper for complicated tasks to take time and expertise to accomplish. But something that is fundamentally simple—like changing the time on a wristwatch—should stay simple.

3.  Fewer choices mean fewer worries.

People love having choices, because having choices means having freedom. Well, we don’t think this is necessarily a good thing when it comes to usability. We believe that when someone wants to do something on their computer, they want to spend their time doing it, not deciding how to do it. For instance, Microsoft Windows provides you with at least three different ways to launch applications and services on your computer: desktop icons, a quick-launch bar, and a Start Menu. Each one of these mechanisms is useful in one or two situations but horrible in others, and each has completely different instructions for operation. Microsoft even gives you a wealth of choices to configure them the way you want, which makes the situation that much more complex.

When we can, we try to avoid burdening our users with choices like this: we’d rather just take the time to make one simple mechanism that the user can use for all their purposes. Because the less burdened a user’s mind is with irrelevant decisions, the more clear their mind is to accomplish what they need to get done.

4.  Your data is sacred.

It’s that simple, really. When one ensures that a machine can’t lose a user’s work, interfaces become a lot simpler; no more dialog boxes asking questions like "Are you sure you want to delete that entry?"; no more remembering to click a "Save" button like it’s a nervous twitch. You never need to regret any action you take, because any action you take can instantly be undone. Not to mention your complete lack of terror when you’re in the middle of working on your computer and the power goes out.

5.  Your train of thought is sacred.

You can only really think about one thing at a time. If you’re thinking about paying your taxes, you can’t be thinking about your vacation in Tahiti. Indeed, thinking about that vacation in Tahiti will actively prevent you from thinking about your taxes. That’s why when you want to get something done, you want to get everything out of your head except the task at hand.

Quite simply, you need to preserve your train of thought. And that means that the interface you’re using can’t derail it. No talking paper clips bothering you from the sidelines, no fiddling with windows to find your work, no distractions.

6.  Good interfaces create good habits.

When you’re first learning how to use even the best of interfaces, preserving your train of thought can be hard because so much of your mind is focused on how to use the interface, rather than on what you need to do. But as you become more proficient at using a good interface, it eventually becomes second nature—it becomes a habit, like walking or breathing. You don’t need to think about what sequence of motions you need to perform an action because it’s like your hands have memorized them as a single continuous gesture, saving you the trouble of having to think about them.

Bad interfaces, on the other hand, prevent habits from forming—but they can also make you form bad habits. Have you ever closed a window and hit "Do Not Save", only to realize a split second too late that it was exactly what you didn’t want to do? That’s a bad habit from a bad interface.

Good interfaces make forming good habits really easy, and they make forming bad habits nearly impossible.

7.  Modes cause misery.

There exists a mortal enemy to your habits and your train of thought: it’s called a mode. If an interface has modes, then the same gesture that you’ve habituated performs completely different actions depending on which mode the system is in. For instance, take your Caps Lock key; have you ever accidentally pressed it unknowingly, only to find that everything you type LOOKS LIKE THIS?

When that happens, all that habituation you’ve built up about how to type on a keyboard gets subverted: it’s like your computer has suddenly turned into a completely different interface with a different set of behaviors. And that derails your train of thought, because you’re suddenly confused about why your habits aren’t producing what you expect them to.

When you think about it, almost everything that frustrates us about interfaces is due to a mode. That’s why good interfaces have as few as possible.

8.  It’s easy to learn.

Good interfaces aren’t just effortless to use once you know them—they’re also easy to learn to use. This doesn’t necessarily mean that someone should be able to use it without any instruction, though—it just means that knowing how to use any feature of the interface involves learning and retaining as little information as possible. Keep it simple, and keep it consistent.

Other articles in the "Ask Aza Raskin" Series:

  1. Ask Aza Raskin
  2. Aza Raskin on Poka-Yoke & The Humane Interface
  3. Aza Raskin on Quasimodal Design and The ATM
  4. Aza on Feature-Bloat and Site Clutter
  5. Aza on Google Search Results Page
  6. Aza on Cooperation and Team Size

More articles on Genchi Genbutsu and Ethnography?

{ 17 comments }