Sweating the Small Stuff

What’s stimulated this return to the intarwebs is Tony Pantello’s comment on a Metacool post, which reminded me of another 20×20 presentation I made to the Designers Institute of New Zealand a few months back, under the auspices of the group I work with at UoA. Last time round with DINZ, I covered a lot of ground: this time I decided to talk in a bit more depth about one subject, and the subject was how low level standardisation gives high level freedom, which I releted to the idea that constraints breed creativity. As I’ve said before, the 20×20 format is itself a good example of this very subject.

As you might imagine, talking to a bunch of designers about standardisation went down like a lead balloon, particularly once I started giving examples from the software industry, but they did me the courtesy of listening, and who knows, maybe it even gave some of them food for thought.

The text is below. As per last time, I think I’m within the bounds on copyright, but if one of them is yours and you’re offended by my helping myself, let me know.

———————————————————-

Tonight’s theme is all about doom and gloom.  If the downturn turns out to be severe and prolonged, a lot of us are going to have time on our hands.  That makes is a good time to be working on our businesses not in them – thinking about how we can do things better.  And businesses aren’t going to be looking for same old same old – they’re going to be wanting out of the box solutions to get them out of the box.

.

.

So tonight I’m going to be talking about one idea that might help.  It’s an area I’m sure isn’t even slightly dear to your hearts:  standardisation.  More specifically, about the idea that standardisation at a low level not only makes for a more efficient design process, but actually liberates creativity at a high level.

.

.

I’ll start with an example:  Language.  Written English is totally standardised at the lowest level.  You work with the letters you’re given, and those haven’t changed since the 17^th century.   And I’d point out that the latin alphabet is a lousy standard:  the letters don’t match the phonemes, and several of the letters and numbers look the same.

.

.

At the next level up, words, you get a little more latitude.  Maybe not as much as Lewis Carroll took, but words do change over time:  if you need it enough, you can invent a new one.  Go up a level again and the standard relaxes:  there are quite a few ways to construct a sentence.  One step further, and standardisation disappears:  at the paragraph level, there’s good practice but no real  rules.

.

.

As a consequence of this, at the highest level, the designer – or author – is free to focus upon the play of ideas and concepts, rather than the administrative details.  Shakespeare is famous for playing with both words and grammar, but their very presence and rigidity gave him this opportunity.

.

.

Another example is electronics.  Electronic circuits are built entirely from standard basic devices.  What’s on the screen won’t mean much to most of you:  it’s the symbol for an IGCT, or insulated gate commutated thyristor.  The interesting thing about the IGCT  is it’s the most recent  device to be invented:  in 1968.  Modern electronics are built on a foundation that hasn’t changed since the 60s.

.

.

Again, move up a level and the standard relaxes.  Most electronics designers work entirely with standard packages, but new ones with variations on the basic devices are coming out all the time.  And if you need a custom package badly enough, there’s nothing except time and money stopping you designing one:  at Wellington we’re doing it right now.

.

.

This standardisation means, once again, that electronics designers are free to focus on what they should be doing:  coming up with circuits that do cool stuff in new and better ways. The electronics industry is developing at a massive rate, and that’s entirely down to low level standardisation.

.

.

.

For a third example, look at Toyota.  Toyota are one of the most successful and innovative manufacturing companies in the world:  the history of manufacturing innovation over the last 20 years has been pretty much the auto industry chasing Toyota, and everyone else chasing the auto industry.

.

.

.

And Toyota base this entirely on low level standardisation:  both of products and processes.  They even standardise their reports.  The A3 report, which comes in about 5 flavours, accounts for most internal communications at Toyota, and it means that the author can focus entirely on what people need to know, rather than how they’re going to say it.

.

.

For their products themselves, they standardise as much of the detail as possible.  Details like shutlines, swages, hinge mounts and location features are standard across all Toyotas, from a Corolla to a Lexus.  And as a consequence, designers, both of the product and of the part, get to focus their attention on the stuff that needs to be different.

.

.

At Wellington Drive, we’re an IP based company, and we put a lot of effort into design:  probably 1/3 of our staff work in NPD, and about a quarter of those are engineering designers.  The design we do is almost entirely about function rather than form:  if we believe Steve Jobs that “design is the fundamental soul of a man-made creation”, well if an electric motor has a soul, it’s in what it does and how it does it.

.

.

One of the issues we have at Wellington though is one I’m sure that you’re all familiar with:  the problem with creative people is they can’t resist creating.  But creative people creating cause work for other people, and the creative people only have so much time themselves:  if they’re creating at a low level, they’re not adding value at a high level.

.

.

Take this thing for example.  This is a wire termination block.  The metal part traps the wires in the plastic housing and cuts through the insulation to make a connection.  We’ve built this into about half a dozen products by now, and each time we’ve redesigned it a bit.  But the thing is, it worked fine the first time.  And we’ve got dozens of little bits like that, whether they’re mechanical features, bits of circuits, or blocks of code.  We’re going to stop redesigning them.

.

.

At a more obscure level, we’re also taking the idea of low-level standardisation and seeing how far up we can push it.  Software is like language but even more so:  at the fundamental level, there are only two letters.  Above that, there are levels of code which as you get further from the basic binary, offer more and more freedom, but less and less control over the precise detail.

.

.

Historically, we’ve tended to work in the lower level languages:  C and assembler.  These give our software designers a high level of control, but tend to focus their attention at a low level.  The question we’re asking ourselves now is:  how can we focus their attention on the highest level, the algorithm?

.

.

.

And it turns out the answer is by standardisation.  By standardising the relationship between high and low level code, you can automate the generation of the low level stuff.  We’re doing a project with the University’s computer science people to find ways of describing software with something called function blocks, which are even more abstracted than the high-level languages. This will free our software designers from the drudgery of detail.

.

.

So why are we doing all this?  Well, up to a point it’s about  efficiency:  doing more with less.  But for me it’s also – in fact primarily -  about creativity, and the fact that necessity is the mother of invention.  These are two of the icons of British car design.  One of them was subject to a lot less constraints than the other, and that one is undoubtedly the more beautiful.  But it’s the other one that changed the way we thought about cars and about class.  Which is the better piece of design?

.

And how does this relate back to design in a wider sense?  Through the idea that design depends on constraints. That less constraints isn’t necessarily better.  And that constraints don’t just come from God and the client:  you get to choose some of your own as well.  And by picking the right ones, you not only make yourself more effective, you channel your creativity into the places it can do the most good.

.

.

I close by returning to my first two examples.  If you wanted to pick disciplines that have changed the world, you could do worse than these two.  And you could do worse than follow their example.

Learning from Making

I did a short (20×20) presentation to the Designers Institute of New Zealand a couple of days ago. I can really recommend this presentation format – it’s a pig to prepare for, but it’s incredibly effective for making you really think about what you need to say. The presentation (heavily academicized and with some stuff on the end about what I’m hoping to do about it) is going to form the core of my preliminary review, which is due in a couple of months time – I figure now I’ve got it condensed down to almost nothing, expanding it to 30 pages or so should be a breeze.

The text and slides are below. A note on the slides: most of the images are either mine or came off flickr or wikimedia and are either GNU or Creative Commons licensed, but a few are taken from I can’t remember where on the web. I’m fairly comfortable that my use of high-res copies in the in the presentation and of thumbnails here is within “fair use” or “fair dealing” provisions, but if any of the imagery is yours and it offends you, let me know and I’ll pull it down.

The presentation is on the subject of how design can learn from other disciplines – primarily software and manufacturing – about managing their process. Since I come from the “hard” rather than “soft” end of design (i.e. engineering) I started by sticking a few stakes in the ground as to what I’m talking about when I say design – this probably doesn’t overlap much with the viewpoint of a lot of the audience, since many of them were from fashion or graphic design industries.

————————

The first point I want to make about design is it has a purpose. To me, all of these are designed objects. And all of them are designed for something. The purpose might be functionality, aesthetics, image, communication, or whatever. But what they have in common is the for. And the for’s not realized till the job’s complete. Completion is important.

.

The next thing about design is that it’s a process. It’s not enough to realize that what the world needs is a chilli banana chesecake – the job’s not done until the happy customers leave the restaurant, and slaving over the typeface of the menu is just as much a part of the process as the fun stuff in the kitchen developing the recipe.

.

The third thing is it’s an uncertain process. Novelty, by definition, means uncertainty. You can’t innovate in a perfectly controlled environment. And lets face it, in the small business environments in which most of us work, you can’t control the environment anyway. But the current innovation management methods try to do exactly that. And they fail.

.

They fail even in the big corporates they were designed for. In small, fast-growing tech businesses – the kind NZ needs – they’re exactly the wrong tools. Which is why nobody uses them. There’s plenty of research to show that most small businesses run design and product development by the seat of their pants. But winging it can only take us so far.

.

.

We need a way to keep a degree of control while letting creativity flourish. And oddly enough, we can find models for that where we might least expect them. The mass production paradigm has changed the world in the past century. But even in this controlled environment, the rise of lean manufacturing over the past 20 years has shown that flexibility and adaptability outweigh efficiency and control.

.

And in the IT world, the past decade has seen the waterfall software development model fighting a losing battle against the wide-eyed idealists of the Agile movement. What lean and agile share is an emphasis on people over process, flexibility over compliance to plan. But unlike the all-or-nothing approach we tend to have in the design world, these processes manage to combine flexibility with method.

.

It’d be nice to think we could just plug them straight into our design process. Unfortunately it doesn’t work like that. Agile straight out of the box relies heavily on the special characteristics of software. Lean has been translated into design management – not least by Toyota – but read a book like this one, and you quickly realise that plugging the Toyota system straight in to a small business would be both impossible and a disaster.

.

So we need to customize the tools. And that’s where my research lies – I’m going back to first principles and asking what these approaches have in common that can work for us. I don’t have any answers for you today, but I want to highlight some of the areas where there are lessons that could turn into tools.

.

.

I see the common thread coming from another unlikely area: industrial process control. Control theory tells us that to control an undefined process, you need to use frequent small adjustments. That means shortening the feedback loop as much as possible, and improving the system’s ability to respond to feedback. Both lean and agile focus on ways to do exactly that.

.

Lets look first at feedback. In design, feedback comes from generating information, learning from it, and adapting to it. That means getting the right info to the right people as early as possible and ensuring they can act on it. It means putting as much effort into surveys, tests and experiments as you do into the product: information gathering is a critical design activity and deserves respect.

.

It means working on cycle costs – the cheaper and faster it is to spit out a daft or prototype and get feedback on it, the more often you can do it and the faster and better you’ll learn. It means keeping the customer focussed on value not contracts: there’s no point in learning things if you can’t change course based on the new knowledge.

.

And it means keeping your options open. Once a decision is made it’s hard to unmake it. The right time to make irreversible decisions is as late as possible – at the last responsible moment. Planning needs to take this into account – plan like hell for the stuff you can predict, but don’t trap yourself into letting your plan make your decisions before you’re ready to make them.

.

.

Now lets talk about response. We’ve all been pushed to do stuff faster. Personally, I don’t believe design can be fundamentally sped up without compromises. Thinking takes as long as it takes, and if you try to do it faster you just get less of it. Maybe you’re lucky enough to cut out the low-value stuff, but mostly you just cut down quality. There’s a lot of evidence to show that the correlation between accelerated product development and profit is dodgy at best.

.

But there are argument for speed. Information is our stock in trade, and it gets lost, forgotten, and obsoleted. The photo here is the inside of a two year old Formula One engine. I took it – in public – about the same time Maclaren were being fined a hundred million bucks million for stealing one year old data. A hundred million to worthless in 1 year. F1 is an extreme case, but information depreciates fast.

.

.

What lean and agile show us is that to go faster, we shouldn’t focus on what we’re doing, but what we’re not.The leverage is in the gaps. There’s more time to be gained by keeping the work moving than by doing tasks faster. And the economics of information depreciation means it’s worth spending money on that. A job sitting waiting is bleeding money. We need to organize our processes around workflow.

.

.

A classic example of that is avoiding batch processing. Anyone been to the Coromandel? Remember the Kopu bridge? More importantly, anyone remember the two or three intersections after the Kopu bridge? Batches hold up the workflow – not just at the batchpoint, but downstream. They’re a convenient way to work – build it up till you’ve got enough to be worth doing – but they’re a bad way to work.

.

.

Another example is timeboxing. Keeping the job rolling to a rhythm lets feedback be incorprated smoothly and lets the players be ready when it comes their way. So instead of breaking it into chunks of work which take as long as they take, break it into chunks of time that achieve as much as they achieve. As long as you prioritize the important stuff within each time box, the 80/20 rule will work in your favour.

.

.

Another idea which I think has real value is extremism. Don’t do things by halves – take it to the limit one way or the other. In IT, finding bugs sooner is better. What’s the extreme of that? Finding them as they’re written. So Agilists put 2 people at one computer and do the dubugging simultaneously with the coding.What’s important in your process? And how do you turn the knobs on that up to 10?

.

.

Conversely, what can you turn right down? Lean gurus believe “if it’s not contributing value it’s waste”, and the agilists mantra is YAGNI – You Ain’t Gonna Need It. Elegance in design is the art of the minimum necessary. ISO9000 and suchlike encourage us to design processes like motorway bridges – we have to ask ourselves “how big a bridge do we REALLY need?”

.

.

I want to conclude by suggesting that design isn’t a machine, and we shouldn’t treat it as such. But neither is it a craft, and we shouldn’t treat it as that either. The design process is something that could benefit from some design, and, just as in the design of things, if we don’t take inspiration from outside our field, we’re letting ourselves down.