Sign up to get our featured articles delivered straight to your inbox every month or two.
RSS feed of all articles
Architecture (3)
Books (3)
Branding (2)
Business (21)
Communicating design (7)
Cooper (3)
Critiques (12)
Design & engineering (8)
Design disciplines (3)
Design in organizations (19)
Design principles (13)
Development (6)
Ecosystem-centered design (5)
Events (1)
Experience (1)
Features (77)
Ideas (1)
Industrial design (4)
Industry-specific (11)
Information design (4)
Innovation (16)
Interaction design (12)
Methods (6)
Mobile (2)
Personas (10)
Platforms (2)
Product definition (7)
Requirements (2)
Research (10)
Service design (2)
Service design (1)
Strategy (4)
Techniques (27)
The Drawing Board (1)
Travel (3)
Trends (4)
TV (1)
Typography (1)
Visual design (12)
Web-related (8)
Books
Learning from How Buildings Learn
The BBC miniseries based on Steward Brand's How Buildings Learn became available on the Internet a few days ago. It's chock-full of provocative stuff, and lays out compelling arguments about how structures succeed or fail in satisfying the needs and goals of people. (Let's hear it for design on TV! First Mad Men, now HBL. It's a televisual golden age!)
As I watched the opening episode, I thought of the quintessential local example of a learning building: The Ferry Building in downtown San Francisco. Built in 1898, it served as a ferry terminal for points around the Bay; as San Francisco changed and bridges eased the traffic burden, it gradually fell into disrepair. In 2004, it re-opened as gourmet food court, serving the prosperous downtown lunch crowd. San Francisco changed, and the Ferry Building "learned" to address a new set of needs. Beautiful.
Is architecture really a good analog for IxD?
Aside from all of the fascinating examples of the ways in which our built environment responds (or doesn't respond) to change, what the miniseries reveals to me more than anything is the limitation of using architecture and construction as models for software design and development. Architecture serves as a helpful stand-in when you're talking about the macro stuff — the planning process, the rough apportionment of the screen "real estate," and discussions around extensibility or repurposing — e.g., Is this thing the first piece of the big structure, or is it the temporary thing that we live in while the big structure is built?
But when you're talking about the way people experience things in a digital environment, architecture is a limited analog. Software is made up of subtle, nuanced interactions and ever-evolving technical capabilities. Interacting with software is conversation between two active participants; it's fast-paced and packed with immediate possibilities. For example, changing context in software seems more akin to a change in facial expression than, say, a movement to a different room. (It should, anyway). The ever-evolving technical capabilities have created a world in which we're all often experiencing some particular digital interaction for the first time; in fact, if someone wrote a book about how software is experienced, it could be called something like, "How Software Teaches Us How to Use It."
Solutions begat problems, problems beget solutions
Of course, there's another side of Brand's perspective that's relevant to our work: Most design projects (at Cooper, anyway) begin with what is presented as a straightforward task: Design a solution for the problem the clients have identified. Architects probably experience a transformation similar to ours, because the real problem is often quite different than what the client has articulated. Brand's perspective is interesting to consider here, because our solution often simply modifies (or modulates) the problem -- makes it smaller, hopefully — but still: Will our solution be able to handle the need to evolve to further reduce the problem? Of course, if anything could learn and teach at the same time, it's software. But software that can learn ... Hmm. Something sounds fishy about that. Remember that part in Terminator where they're talking about how the computers took over?
[Start with Episode 1 of How Buildings Learn at Google Video, and thanks to smashingtelly for the tip]
Book review: Web Form Design
I view Luke Wroblewski's latest level-headed work titled Web Form Design as a book nobody really wanted to write, but somebody had to do it. Luke makes the point that in more and more cases, it is web forms that stand between your customers and the products and or services they want from you. Anybody who has spent any time at all filling in the blanks knows firsthand that there is plenty of room for improvement here.
Personally, I appreciate that the book begins with "Forms suck." (I appreciate it because it's true). The rest of the book sets out the terminology, principles and patterns necessary to design forms that suck less. Finally, for those of you who have spent more time than you care to admit arguing about label alignment, you'll find a reasonably well considered analysis of the various options that should put an end to the squabbling.
Three books to spark your design thinking
For the past several months, I've been working with Alan Cooper and Robert Reimann on the latest version of About Face, Alan's classic book on interface and interaction design. One of the major objectives with this new third edition has been to bring the book up to date with current conversations about the design of interactive products, which has been a great excuse for me to dig into the growing body of literature on the subject.
In particular, the last year saw the publication of three very worthwhile tomes written explicitly on the subject of interaction design. (Those of you who have been in the field for a while probably share my shock to have such a wealth of discourse.) Despite the almost comic similarity in their titles, the three books each cover different ground but are really quite complementary. These three books, along with Mullet and Sano's Designing Visual Interfaces and About Face (naturally) would be a fantastic curriculum for someone interested in interaction design.
Email it to us and we may answer it in an upcoming article.