Category: Process

I’ve found the Agile Development community has a lot in common with the user-centered design community, and their methods — especially the spirit of them — is closely aligned. In case you haven’t been following their evolution, many different methods from Scrum to Extreme Programming sprang up and, seeing commonalities among them, the founders came together to write the Agile Manifesto and form the Agile Alliance. Soon project managers caught the bug, adopted the practics and just recently formed the The Agile Project Leadership Network (APLN) which incidentally is structured much like the Information Architecture Institute.

The APLN’s core principles reaffirm the human-centeredness and agility of their predecessors:

In order to consistently deliver successful results, great project leaders embrace the following practices:

• Relentlessly Focus on Value. Focus efforts on generating organizational value rather than managing tasks.
• Be Situational Specific. Use situationally specific strategies, not a one-size-fits-all approach.
• Manage Uncertainty. Manage uncertainty through client focused collaborative exploration and proaction.
• Continuously Align to Changing Situations. Choose strategies for leading within a dynamic environment.
• Lead with Courage. Confront reality with conviction and a dedication to purpose.
• Build Strategies that Leverage People. Challenge team members with opportunities to grow professionally.
• Design Strategies Based on Teamwork. Devlop and sustain a collaborative team environment.
• Communication Through Immediate and Direct Feedback. Maintain control through feedback, not prescriptive plans.

In GM’s Design Push Picks Up Speed David Welch profiles Bob Lutz’s struggle to balance the priorities of accounting, engineering and design in an enterprise. This bit pressed the clutch down in my brain:

One of the first things Lutz did on arriving in September, 2001, was push designers and engineers to stop fighting and start collaborating. Now, when the two sides butt heads, they get together in weekly meetings to hammer out their differences. “It isn’t a love-in,” says chief designer Ed Welburn. “But in the last two or three years the laws of physics have changed.”

Now I realize this is a huge company, and the projects run for years, but we all know from having done this work that once-a-week meetings doesn’t count as teamwork. At the Skunkworks for example draftsmen and engineers worked in ajoining rooms, close enough to shoot rubber bands at each other. This helps people generate ideas and sort out issues while in the synthesis frame of mind, rather than the review frame of mind. Hopefully GM’s weekly meetings are a step towards richer interaction.

I’m doing research on high-performance teams that can evolve how they work to changing environments. I see it in the best designers, agile programmers, engineers and others. And I’m not too surprised to see it in Skunk Works, a book about the famous Lockheed Advanced Development Projects group. The man who ran the group during the early years — Kelly Johnson (shown with the U-2 spy plane) — wrote up a set of rules that emphasize small teams, close collaboration, low ceremony, iteration and testing, relationships built on trust, and constant communication…

1. The Skunk Works’ program manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher.
2. Strong but small project offices must be provided both by the military and industry.
3. The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people.
4. Very simple drawing and drawing release system with great flexibility for making changes must be provided in order to make schedule recovery in the face of failures.
5. There must be a minimum number of reports required, but important work must be recorded thoroughly.
6. There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program. Don’t have the books ninety days late and don’t surprise the customer with sudden overruns.
7. The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project. Commercial bid procedures are very often better than military ones.
8. The inspection system as currently used by the Skunk Works, which has been approved by both the Air Force and the Navy, meets the intent of existing military requirements and should be used on new projects. Push basic inspection responsibility back to the subcontractors and vendors. Don’t duplicate so much inspection.
9. The contractor must be delegated the authority to test his final product in flight. He can and must test it in the initial stages. If he doesn’t, he rapidly loses his competency to design other vehicles.
10. The specification applying to the hardware must be agreed to in advance of contracting. The Skunk Works practice of having a specification section stating clearly which important military specification items will not knowingly be complied with and reasons therefore is highly recommended.
11. Funding a program must be timely so that the contractor doesn’t have to keep running to the bank to support government projects.
12. There must be absolute mutual trust between the military organization and the contractor with very close liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum.
13. Access by outsiders to the project and its personnel must be strictly controlled.
14. Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay, not simply related to the number of personnel supervised.

And a last rule passed on through oral tradition…

15. Starve before doing business with the damned Navy. They don’t know what in hell they want and will drive you up a wall before they break either your heart or a more exposed part of your anatomy.

“We are stuck with technology when what we really want is just stuff that works. How do you recognize something that is still technology? A good clue is if it comes with a manual.” — Douglas Adams

It’s ironic that making simple products is difficult, but it is. It requires discipline to design simple products, discipline to focus on real-world use and experience of a product rather than guesses about use, and discipline to market the real value versus the sheen of extra features.

John Maeda’s seventh law of simplicity expresses a similar idea with an interesting phrasing, suggesting that the simpler thing becomes cognitively more…

The more care, attention, and effort applied
to that which is less, the more it shall be perceived
as more than it really is.

“Premature optimization is the root of all evil (or at least most of it) in programming.” — Donald Knuth

I think you can replace the word programming with the word design and that would still be true.

Brett tracks the coinage of the phrase beta is the new black. While the idea isn’t news to the web-savvy, it’s still a scary concept to product developers in the corporate world.

A friend just reminded me of a story from some time ago. I was giving a short presentation at a financial services company on the user-centered design process. The audience was a project team. I threw up some slides illustrating the various activities: researching users, designing the interface, implementing it, etc. Toward the end, the database programmer said, “Ohhhhhh, I understand, you do everything backwards!”

That’s because his process was: build a database, slap on a user interface, and test it… the exact opposite of what I would do.

I wonder if this is a way to explain UCD to technical audiences? “OK, what I’m about to tell you may be hard to believe. But there’s this whole field of people achieving great results by doing everything completely backwards!“

iLife let’s you be composer and editor with production capabilities that required an entire studio 15 years ago. The next logical step in consumer production is full-on film direction, a combination of simulation and multimedia that completes the DIY promise. An example of what amateurs are hacking together is Mike Fraser’s 100 years (Windows Media), made using The Sims 2 and set to Five for Fighting’s 100 years (iTunes). It’s rough but wonderful. Wait for the ending.

Update: Brett writes in to compare this to machinima, which it is, and which I should have thought of after discovering the hilarious Red vs. Blue last year. But what if Apple comes at it from the other direction – building a complete production studio on your mac, instead hacking together a movie using a game engine — it could suddenly own the commercial machinima market before others realized there was a market.

Laurie Vertelney writes in after seeing my take on the Origin of Personas. …It seems like we’d been using scenarios for ages to do design work at Apple and at HP Labs before that. (mid-late 80s) I was personally inspired by some of the work at MITs Architecture Machine Group back in the early 80’s…

I’ve added more of her comments to that post.

Thanks to Zap — who invited me to a panel on design methods (.ppt) at the IA Summit — I finally got my hands on a copy of Jay Doblin’s A Short, Grandiose Theory of Design, an article from the 1987 STA Design Journal. In its seven pages Doblin presents a straightforward and persuasive argument for design as a systematic process. Quick notes:

• For large, complex projects, it ‘would be irresponsible to attempt them without analytical methods.‘ He cites the existence of a too-common ‘adolescent reliance on overly intuitive practices.‘
• He contrasts direct design in which a craftsperson works on the artifact to indirect design in which a design first creates a representation of the artifact, separating design from production in more complex situations.
• He outlines a generic process of design: STATE 1 -> ANALYSIS -> GENESIS -> SYNTHESIS -> STATE 2
• Analysis is deciding what is relevant, then detailing and structuring it
• Genesis is expressing the concept, what Terry Swack used to call expressing the intended user experience. In some ways it is model building.
• He demonstrates using a 2×3 matrix of performance/appearance vs. products/unisystems/multisystems (increasingly complex artifacts or combinations of artifacts).
• In the end, he brings it back to a focus on business, reminding us the core issue is to compete effectively