# Packing kits - part 3

October 21, 2012 8:40:54 PM CDT

## The counting table:

This is the thing that sparked my first impulse to write about packing kits. I thought, "hey, this is a really useful device. I should show it to people."

When I started trying to write about it, life got frustrating. The benefits of the table are obvious to me, and trying to explain 'the obvious' is a nightmare.

The word 'obvious' comes from the Latin roots 'ob-' (across) and 'via' (road or path). Literally, something lying across the road.. if you somehow miss seeing it, you'll trip over it. In more abstract terms, it's something that follows naturally from what you already know.

That concept has a built-in geographical component. The 'ob via' depends on which road you're following, and where you are on it. I mean.. the Nyquist-Shannon sampling theorem is obvious when you look at the frequency domain Fourier transforms of a signal modulated by a discrete-time impulse train, but you have to crawl through a lot of "say what?" to learn what all those words mean.

Sometimes explaining 'the obvious' means you have to trace your steps back over the paths that led to where you are now.

So. . .

## Path 1, the workshop:

I used to do process development for a company that sells woodworking tools. The owner would invent something new and bring the prototype to me. I'd take it apart, figure out how to make all the pieces, then arrange the steps in a path leading from 'raw materials' to 'shipped product' with as little wasted effort and material as possible.

To do that, I had to take the operations apart (this step happens on the chop saw, this one happens on the drill press, this one happens on the tapping press, etc) then combine them with steps for other products (we're cutting Delrin rod on the chop saw, so we may as well cut blanks for this product, that product, and the product over there).

As a result, I spent very little time dealing with 'things' and a lot of time dealing with 'materials on their way to becoming things'. I stopped thinking of 'a part' as 'a part' and started seeing it as 'the bit that's left over when you get done performing a series of operations'.

## Path 2, a really good book:

Somewhere around then, I stumbled across The Design of Everyday Things (formerly The Psychology of Everyday Things ) by Don Norman.

Good book.. if you haven't read it, find a copy at your library or just buy one. It's a fun introduction to the concept of affordances.

Loosely speaking, an affordance is something you can do with an object: you can sit in a chair; you can bounce a basketball. You can also sit on a basketball, so the basketball has affordances for both 'bouncing' and 'sitting', though people tend to spot the 'bouncing' one first.

DOET's general theme involves making affordances easy to see.

Have you ever gone to a website whose creator (probably a graphic designer) thinks brightly-colored, underlined links look ugly, so they remove the underline and make the links the same color as the rest of the text? You have to scrub your cursor all over the screen to find links, assuming you even make the effort. That's an example of making affordances harder to see.

There's a school of design 'thought' which believes hiding affordances is spiffy.. something to do with abstracting away the merely functional blah-blah-blah. Norman uses "probably won a design award" as a curse.

At any rate, thinking about affordances gave me a new way to look at both parts and the processes that create them. Every step in a process that creates a part has needs so specific you can assign numbers and tolerances to them. So the scaffolding used to create the part should have affordances for 'making the right thing happen to the material at the right time'.

## Path 3, the Theatre!:

In college, I was a theatre major. One guest professor was a director from LA with an intensely pragmatic view of the trade. He taught a class called "Negotiating With The Enemy".

The premise of the class was that technicians and directors speak different languages. Technicians have a vocabulary of machines and materials, directors have a vocabulary of texts and performances. When those languages pull in different directions, you get problems. The goal was to teach technicians a basic fluency in 'director' and vice versa.

## Path 4, the office (and another good book):

Skipping ahead to the dotcom era, I was head of the group that provided internet services for a publishing firm. Being an IT person dealing with salespeople was a lot like being a tech dealing with directors, so I fell back on my training and spent a few months learning to speak 'manager'.

One of the books I found was W. Edwards Deming's Out of the Crisis.

Deming, if you aren't aware of him, invented what became known as 'Japanese management'. One of his key insights is that production failures aren't just some mysterious fact of life. They happen for reasons. Good production managers keep track of the failures, find the reasons, then work to eliminate them.

There are two stories that illustrate the idea, one success and one failure:

• IBM Canada ordered parts from a new supplier in Japan. The contract specified a defect rate no higher than 1.5%, which was fairly demanding at the time. The order arrived with a small box to one side and a note that read, "We don't know why you want 1.5% defective parts, but for your convenience, we've packed them separately."
• Another company couldn't reach an agreement with its labor union. The workers went out on strike, and management decided to do the symbolic "run the production lines ourselves" thing. By the end of the first morning they'd tagged the machines for one whole production line as scrap, and cannibalized parts from two other lines to make a fourth one actually work. Then they had to go back to the negotiating table and face workers who'd been reporting those same problems for years. A manager from the company told that story to Deming, who replied, "and you know exactly whose fault that was, don't you?"

"Track and eliminate sources of failure" ties in well with the idea of process affordances.

A process with affordances to Do The Right Thing -- cutting to size, placing or tapping holes, etc -- can still be a lousy process if has as many (or more) affordances for Doing The Wrong Things.

## Back to the present:

I use the table to count parts and do QA because there's a lot of overlap in the affordances those jobs need.

'Counting parts' involves taking a specific number of parts out of bulk storage and putting them somewhere else. Breaking that down into process affordances, we get:

• an affordance for putting the uncounted/bulk parts somewhere
• an affordance for separating a small number of parts from the bulk
• an affordance for counting the parts that have been pulled out
• an affordance for adjusting the number of parts in the 'counted' pile
• an affordance for moving the 'counted' pile somewhere else

Keeping the most obvious failure modes in mind, we also need to eliminate affordances to for:

• getting the count wrong
• having parts from 'bulk' fall into 'counted' or 'somewhere else' and vice versa
• having parts go onto the floor as they move in or out of the 'bulk', 'counted', and 'somewhere else' zones

If you look at the table with all that in mind, you can start mapping affordances onto the object:

Bulk parts go in the upper left. The counting area is toward the middle. The spout at the lower right lets me sweep parts out of the table and into 'somewhere else' containers.

The fact that the table is raised (and the missing fourth leg) gives me an affordance for moving new 'somewhere else' containers under the spout quickly and easily. The balance isn't nearly as bad as you might think, either.. the off-center mass of the upper left leg prevents wobbling. Using the plastic scraper on a smooth, flat surface gives me an affordance for moving large numbers of parts all at once.

The rim around the counting surface removes an affordance for parts falling off the table and onto the floor. Putting the spout in a corner removes an affordance for parts to miss it. Having the spout extend below the table (into the 'somewhere else' containers) removes an affordance for parts to fall on the floor as they leave the table.

There are still some things I'd like to improve, but for a tool I threw together in half an hour from scrap laying around the shop, it's performed remarkably well.

As I said earlier, the QA process shares many affordances with the counting process, including "being able to see what's there" and "getting everything into a container". There are a couple of new ones though:

• an affordance for grouping different kinds of parts
• an affordance for getting parts into a bag
• an affordance for associating a specific set of parts with a specific kit

The rim around the table gives me four easy-to-hit surfaces for grouping parts, and the transparent plate allows me to put the part bag directly under the table when I take a picture of the laid-out parts. I wish I could claim that as an example of good design, but I'd have to lie. When I made the thing, the piece of sheet stock closest to the right size was a scrap of transparent acrylic. Finding a useful application for the 'can see through it' affordance was pure luck.

Bagging requires another tool:

It's a funnel cut from the safety housing of a 60cc veterinary syringe. The long end fits all the way down into a bag:

And the wide end fits around the table's spout:

Parts fall out of the spout into the funnel:

Then I can raise the funnel to dump the parts into the bag:

After you've spent a few hours fighting with small parts and the lip of a resealable bag, you'll appreciate how much faster, easier, and more reliable this method is.

## More paperwork:

And, of course, each time I count the parts for a kit, I tick them off on the checklist:

I know that this step is redundant, what with the standard layout and photo and all, but I think of the QA mindset as a friendly enemy to the production mindset.

The production mindset focuses on getting it right. The QA mindset focuses on proving that something was done wrong. It doesn't take shortcuts, and it doesn't take anyone's word for anything, including its own. A checklist that's redundant 99.9% of the time is a checklist that saves my ass one time in a thousand. As little as it costs in time and effort, I think it's a good investment.