Eames: Never Delegate Understanding

I recently watched a film on Charles & Ray Eames. It tells the story of their continuing influence in design. Scattered throughout the film were fascinating glimpses of their design process.

I don’t think I could do a better job summing up their processes better than this:

Perhaps more enduring than some of their designs was the method by which the team created: later dubbed the “Eames design process,” an intentionally cultivated unfamiliarity toward the problem at hand was regarded as the only way to begin work. Operating by the conviction to “never delegate understanding,” teams would approach assignments Socratically by asking fundamental questions that manufacturers had lost sense of. They did their own research and testing, ceaselessly iterating to adapt products for those who actually used them, and for how they used them. By so doing, they kept a powerfully creative tension between intellectual and artistic discipline and childlike curiosity which would become the permeating characteristic in all of their work.

– Brandon Dorn

How the film inspired me

Learning and researching can sometimes feel purely academic and heady. “I will understand this problem after I sit and listen and interview and watch.”

Watching the Eames think through problems while experimenting reminded me of the value of learning that comes from building and testing. Much more can be learned of a problem when you try to solve for it.

Additionally, I was reminded to not just build and assume any first idea is on-point. I must learn; I must test. I must not pass on opportunities to deeply understand problems. Either at the outset when discovery is needed. Or through learning via experimentation.

 

Collection of tiny details

Getting the details right is the difference between something that delights, and something customers tolerate.

Your software, your product, is nothing more than a collection of tiny details. If you don’t obsess over all those details, if you think it’s OK to concentrate on the “important” parts and continue to ignore the other umpteen dozen tiny little ways your product annoys the people who use it on a daily basis – you’re not creating great software. Someone else is. I hope for your sake they aren’t your competitor.

This Is All Your App Is: a Collection of Tiny Details
Jeff Atwood, Coding Horror, May 7, 2012