Sign up to get our featured articles delivered straight to your inbox every month or two.
RSS feed of all articles
Dave Cronin
VizFarm: Visualization jamboree
Last night a couple of us made it out to the VizFarm, July's installment of the incredibly successful IxDA San Francisco monthly event. The format was interesting: 19 presenters, speaking for 5 minutes each on a single visualization or visualization-related project. The brevity of the presentations was reminiscent of Pecha Kucha and certainly served to keep things moving and provide for a serious diversity of material, even if I wished I could hear a bit about some of the projects. (Also, I should say fellow Cooperista Chris Noessel and myself were both presenters and we certainly found it easier to prepare for this than a longer format. This is a good way to encourage participation from a community.)
The visualizations described topics included genetic sequencing workflow, Grand Prix motorcycle racing results, air-traffic control, correlations between deforestation and carbon emissions, as well as between transit times and home prices, and of course, the slightly self-referential but always enjoyable topic of uncovering meaning in qualitative design research.
A recurring theme in many of the presentations was how visualizations can help to uncover answers to complicated questions like "Where are there opportunities to reduce the amount of time it takes to sequence a human genome?" or "Where should I be looking if I want to buy a home that costs under £500k and is within an hour commute to central London?" By structuring the data and display in the right way, we can start to rely on people's abilities to recognize visual patterns to see complex situations in new ways.
Photo: Many Eyes
Of course, readers of Tufte will be familiar with a lot of this — in an academic sense, at least. But there's a huge challenge in making these useful to those who are less familiar with infographic conventions. To address complex questions in a visualization, the creator must communicate the utility of the levers and dials to "readers" at a variety of levels, which require a certain degree of visual and quantitative literacy, and can (potentially) further burden the display/interface.
Martin Wattenberg and Fernanda B. Viégas have made an attempt at this with IBM's Many Eyes project, the goal of which is to "democratize visualization and to enable a new social kind of data analysis." (To avoid any confusion, I'll mention that Many Eyes was not part of the proceedings last night.)
What do you think? Does something like this stand to help citizens better understand the world they live in, without the slant and filter of news organizations? What can we do to provide these new ways of seeing things to audiences unaccustomed to reading data visualizations?
Welcome to Michael Voege, Director of Industrial Design!
Some of the most exciting and challenging products we’ve designed here at Cooper have involved a physical component. We admit it, we’re greedy: we want to do more fun projects like that. So without further ado, we’re excited to announce that Michael Voege has joined Cooper as the Director of Industrial Design. We fundamentally believe that interaction, industrial and visual design must be closely coordinated to create user experiences that delight and engage. Bringing in Michael, with his experience, creativity and crazy design mojo, will help us interweave these disciplines even more tightly as we grow our own in-house industrial design department.
Michael comes to Cooper from frog design, where he was an Associate Creative Director. During his 10+ year career he has worked on consumer products, software user interfaces, automotive interiors, furniture, and medical and industrial equipment, among others. Michael was educated at ArtCenter College of Design in Switzerland, and in Pasadena where he studied Transportation and Industrial Design.
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.
Early and Often: How to Avoid the Design Revision Death Spiral
Introduction
One lesson we've learned over the past several years here at Cooper is that on the vast majority of our projects, intimate client collaboration is a critical ingredient for success. This is a lesson that we have sometimes learned the hard way; collaboration can be messy, unpredictable and has often forced us to compromise what we thought was a supremely clear and elegant vision. Despite these growing pains, we have now come to embrace the unpredictability and compromise; through well-managed client collaboration, our designs are stronger and are more likely to serve our clients' needs and satisfy the goals of end users.
It is the aim of this Practice Study to discuss the methods we have adopted to get maximum benefit from our clients' expertise and feedback while maintaining creative momentum and achieving our milestones and deadlines.
Well-Designed Products
A common affliction plaguing many of us interaction designers is the propensity to complain and kvetch about every piece of software on our computers, cell-phones and cars. And it's true—there is a lot of bad software out there.
To offset this sometimes irritating tendency to critique and redesign everything we see, I'd like to offer a selection of software that I consider to be truly well-designed. To avoid creating a list that is simply an expression of my personal taste (which of course it is, to some extent), I devised some criteria as necessary aspects of a well-designed software product.
Designing for Offshore Development
Everyone's talking about outsourcing and offshore development these days. It's been on the cover of major newsweeklies, featured prominently on the West Wing television show, and a topic of conversation around boardrooms and discussion groups. Regardless of your personal position on trade policy, globalization looks like it's going to be a fact of life in the software industry.
As an Interaction Designer, I'm not responsible for actually building the products I design. However, I find it increasingly clear that outsourcing creates a significant impact on the entire software design and construction process. Offshore development is in its infancy, but will continue to evolve to become an increasingly effective way to go about certain kinds of software construction. Based on recent project work, this article describes a number of observations worth considering as you ponder how outsourcing and offshore development may fit into your plans.
RUP & Goal-Directed Design: Toward a New Development Process
Abstract
Interaction design methodologies, such as Goal-Directed Design, tackle the software development process from the top down by defining specific product requirements and interface behavior based on research and user needs. The Rational Unified Process (RUP) and other programming methodologies attack software development from the bottom up. RUP creates fluid efficiencies for iterating product development during the construction phase in order to react to changing product requirements while still producing shipping code.
Although different, the two approaches are both successful ways to manage software product development. Do development organizations need to choose one methodology over the other? Or are the two development strategies complementary?
Email it to us and we may answer it in an upcoming article.