It’s great to see design pattern libraries like Yahoo!’s getting a lot of attention these days. I’ve been working on planning one for a client recently and thinking a lot about what makes them successful. In short, I think the newer, popular ones are immediately useful, meaning you can directly insert the pattern into your work during the design process. This hasn’t always been the case.

Roughly ten years ago, interaction designers started to see how patterns were used by programmers and began writing their own patterns, just as Christopher Alexander knew people could. I was part of this wave, for example with this short paper introducing the topic to my colleagues.

But many of the patterns at the time were a little too clever. And the books that came out (and that are still coming out) are a little too abstract to be useful. Instead of giving one concrete observation of a design artifact with an example we can immediately use, they go one level of abstraction higher, in the hope that more generalized descriptions will last longer and be more widely applicable. But this just requires too much work from the typical reader; people have enough constraints to deal with, they want the answers.

Pattern languages so far haven’t been good design tools. Christopher Alexander himself realized that pattern languages didn’t do a good job of helping to generate coherent designs or objects. The ones that seem to be most useful like Yahoo!’s and Welie’s (and templates and stencils and the recent wave of AJAX frameworks) are fairly concrete — you can look at a pattern and copy it (sometimes downloading examples and code). They offer patterns that help people execute a design rather than do design.

And while Alexander et al’s original book is thoughtful and philosophic, it also focuses on concrete examples.

That simple idea (hopefully obvious to anyone who has tried it) that great commercial products aren’t simply the result of great product ideas is one I’ve mentioned before in the context of company culture and improving capabilities over time. But compared to the concrete sexiness of topics like the iPod and Swiffer this argument isn’t quite as riveting.

So I’m happy to see the mainstream press pick up the theme, such as this Pascal Zachary article in the New York Times, The Unsung Heroes Who Move Products Forward.

“Process innovation, even more than most product innovations, also tends to realize its economic potential through a lengthy process of incremental improvement based on learning by doing and other types of learning,” [David C. Mowery, a business professor at the University of California, Berkeley] added. “So ‘breakthroughs’ in process engineering are, if anything, even rarer than in product innovation.”

One thing this has taught me is to not lead with innovation as a theme, as it’s an ambiguous topic that can frame matters the wrong way, as being only about great ideas or high-risk/high-return product bets. I think communities like Agile developers, by focusing on process in a compelling way, are making great progress innovating at the process level.

Inspired by Samuel Mockbee’s work helping architecture students make actual homes during their studies, I’m having my Business & Design class at the Pratt Institute do business design work on an actual business. We’ve studied business operation and finance, secondary and primary research, and business idea sketching. Monday we’re kicking off our project with a visit from the client.

A tool I’d like to use to capture the essence of the client’s business in a snapshot is a business model diagram. I’ve found two good examples:

1. Peter Rip’s
2. Alex Osterwalder’s and below…

Milton Moskowitz, who has co-authored “The 100 Best Companies to Work for in America” since 1984, disovered (not surprisingly) that to really learn what makes a good job you need more than surveys and secondary research, you need to talk to employees. In this article, We Love Our Jobs. Just Ask Us, he identifies several benefits that go into a good job, but one key characteristic:

A good workplace is one where management trusts the employees and where employees trust the management.

Which is illustrated in comments like…

“I feel I get a fair share of the profits of this organization,”
“I am proud to tell others I work here,” and
“There is a minimum of politicking and backstabbing here.”

The magical Overlap 2007 event happened this past summer in the woods north of Toronto, a weekend devoted to exploring the intersection of business and design. To keep it conversational and intimate the size is limited to about 40, but for the first time thanks to this year’s organizers there’s video from the event on the site.

A highlight for me was the presence and conversation with Jeanne Liedtke, as I think her research, teaching, and writing has done the most to define and disseminate the core ideas of business design. She focuses on practical outcomes, yet is comfortable spinning beautiful metaphors and embracing big ideas, so I recommend you start with her video.

If you’re in the Dallas-Fort Worth area you may want to check out Design Thinking 2007, a full day of sessions exploring the topic.

In the evolution of programming languages, we’ve been moving to higher and higher levels of abstraction, for example from binary to assembly to C to scripting. Writing code gets easier, but the more generalized functions are balanced with less flexibility, which limits how much abstraction is practical.

Bill Scott’s Protoscript is a small but significant step in this evolution:

Protoscript is a simplified scripting language for creating Ajax style prototypes for the Web… I am a huge proponent of breaking down the barriers for the non-techies among us to be able to do what us techie geeks can do.

There are many AJAX frameworks out there, but Protoscript is designed to address a different and widespread need — those of us non-programmers who would like to make rich websites — without over-generalizing the code too much. It still involves looking at code, which I think will scare off many people, but it seems he’s thinking about how a graphical interface can control this.

For designers, it means you will soon be able to do more without relying on a developer, and developers can focus more on the backend systems. For everyone else, it means the web will be getting more interesting more quickly.

The nice thing about having a blog is that you can pour your unfiltered frustration into it and walk away self-satisfied. Warning, this is one of those posts.

Dear New York City Internet Job Recruiters,

I’ve met several of you over the years, and many more lately now that the demand for talented people has outstripped the supply. For the most part, you are pretty nice people who are willing to go the extra mile to consider a good match of person and job and maybe even career, unlike the IT headhunters I knew in the early 90′s that were mostly middle men for resumes.

But, I have two giant gripes with the way you’re working these days:

1. Don’t ask me to do your job for you. Yes, I know a lot of people, and yes I like helping them find new opportunities. But simply telling me about an open request you have tells me that you haven’t taken the time to build your network or don’t know how. Further, you’re being paid to do that, so if you want expert help you need to share a significant portion of your fee.

2. Great people are not found, they’re grown. There are simply not enough skilled workers to fill your jobs these days. This may be great news for you, but ultimately the companies you work for (and the clients they work for) will continue to suffer until you learn to cultivate good people. It’s easy to measure if a company knows how to do this, just look at the rate of employee turnover. If it’s under 5%, they do it well. If it’s over 10%, there are serious problems.

To illustrate the potential, I’ll tell you a story from the first dot com boom. I was working at a company that hired a certain smart guy as a receptionist. In between phone calls and signing for packages he taught himself javascript. Excellent, make him a developer. After a while doing that he wanted to be an information architect, so I trained him. At that point the company failed to keep engaging him, and he left to pursue a masters degree, where he formed a company with a classmate. Soon after his company was bought by Google.

That’s an extreme example, but I can tell plenty more about people hired that were not qualified, but had the right qualities, were smart, and got things done. A little training and encouragement made them qualified. But until your clients realize this and stop turning away good people, I’m done helping you.

Once is the best movie I’ve seen in a long time, and accomplishes this very simply, without trying very hard. A tale short enough to be a short story. A musical setting so natural you almost don’t realize you’re watching a musical. Characters that are beautiful people you’d want to be friends with.

Website

Soundtrack