Communicating a Vision (cont.) Dirk Knemeyer

Yeah, Luke, it definitely sounds like we are in accord on the importance of clear communication, design artifacts, and context. From the standpoint of actual design tools, unless I’m misunderstanding you Luke, I’m quite surprised that you start the process with mock-ups. Getting back to the power of communication, in my experience, you need to get some stakeholder involvement and buy-in a little earlier in the conceptual process.

We’ve been very successful at Involution Studios with using both of the extremes to communicate our software design decisions: very early on, to go through box exercises and very low fidelity wireframing that is akin to magazine or newspaper art direction. That is, communicating a variety of the most basic structure and flow possibilities of the product, including pros and cons to the different approaches. Philosophically, we believe there are various correct solutions to each software design problem, and this low fidelity approaches helps other stakeholders to think through and understand design solutions, becoming part valuable co-creators in the process. From there we go straight to very high fidelity mockups similar to what our final interface design would look like. We’ve found that both stakeholders and users need this degree of fidelity in order to test and validate the design. However, without first going through the purely structural/architectural steps, I don’t think stakeholders would fully appreciate the essence of the design, or have the context to make decisions and back what we’re doing as product designers. So I’m interested in how your process accounts for these things, as well as the issue of buy-in.

Changing gears for a second, one thing we talked a little bit about offline was that we largely are communicating with different audiences, or coming at this from different problem solving perspectives. I wonder if it would have been valuable to explicitly define our respective contexts right up front, to better communicate to each other and our audiences what is framing our positions on these things.

Heh. It all comes back to communication!

Communicating a Vision (cont.) Bob Baxley

Not to break up the kumbaya moment but I think you guys have ventured a little far afield of the actual topic here. The original question was about communicating a product vision not about communicating an actual design solution. Those are two very different beasts and typically involve very different audiences. Although I can't say I've had a ton of success selling or communicating actual vision, in this context it's the more salient topic so I'll focus there.

The single best tool I've found for communicating vision is the concept statement. The idea is simply to describe the core essence of the product in a single sentence. Although it might sound like a simple thing to do, the act of forcing the expression down to a single, concise sentence imposes a level of discipline, committment and clarity that is all too often lacking from software development projects.

The best example I've encountered is Walt Disney's description of Disneyland, "The Happiest Place on Earth". In a single sentence he managed to express the entire philosophy and experience of Disneyland, providing clear and unambiguous guidance for a plethora of business, service, and design decisions. Fifty years after Disneyland opened, you can still see the committment to this vision in everything from the placement of trashcans to the length of the crew shifts.

For more about concept statements, check out this article by Gerd Waloszek at the SAP Design Guild site or my book, "Making the Web Work".

For inspiration I'd return to Dirk's opening comment and encourage everyone to read Kennedy's famous "Address at Rice University on the Nation's Space Effort" as well as the "Special Message to Congress on Urgent National Needs" (skip down to the Section IX, Space). Notice how he describes the goal as well as the timeline and difficulties as well as how he inspires his fellow citizens without downplaying or ignoring the very real dangers and sacrifices required.

Regardless of your political leaning, the speeches are worth reading because they remain the only successful model we have for uniting a large group of people in a single cause unrelated to survival or equality. That's not to say that creating a software experience is quite on par with sending a nation to the moon, but clearly there's a lot to learn from them in terms of inspiration and leadership and vision.

And finally, to wrap the two ideas together, we might look to this passage as the concept statement for the Apollo mission: "...I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth." Perhaps not as concise as "The Happiest Place on Earth" but certainly clear, direct, and ultimately successful.

Communicating a Vision (cont.) Jim Leftwich

I should quickly backtrack and acknowledge what Luke said about the importance of telling a story as a means of communicating key aspects of a vision in a context that people can readily grasp. And he’s absolutely right that PowerPoint (which I disparaged earlier), can indeed do this wonderfully. My comment about PowerPoint wasn’t really a comment about it as a medium, as much as a reaction to the innumerable bullet-point presentations I’ve suffered through over the years. So little within corporations is presented in an effective interrelational manner, either visually or, as Luke suggests, in narrative story form. Most of the time, meetings are plagued with these awful bullet-pointed slideshows.

A laundry list of bullet points is to a whole and integrated vision what a list of types of musical notations is to a symphonic score. It’s important, of course, to discover and manage needs and requirements, but this is unfortunately where too many design processes stop. Too often, the focus remains centered around the checklist of features or items, and the design process really becomes about “bolting them all together and putting a pretty skin over the whole mess.”

To avoid confusion, I should again point out that a lot of my projects involve developing platform-level OS UIs and frameworks for associated applications. This is a very different endeavor than designing in other areas, so my methods and approach come from my experiences. The challenge in rapidly developing these types of systems requires iteratively designing at two scales simultaneously:

1 - Developing an overarching theme, interactional language, and set of consistent patterns from which all individual and specific types of interaction can be embodied

And...

2 - Developing each of the individual sub-parts (i.e.: modal divisions, functional sequences, procedures, etc.) using the common language and pattern.

As you can see, this presents something of a chicken and egg problem. It’s impossible to develop the overall interactional language and patterns (the OS level language) without knowing a great deal about the needs that arise within the required functions and activities (applications level). And vice versa. It’s necessary to have some sense of a consistent pattern of interaction in order begin laying out and designing the interactional flows with some sense of consistency and order. By working at both scales simultaneously back and forth, it’s possible to see commonalities and patterns emerging, and this provides opportunities for establishing the overall interactional language and patterns. Then, as this begins to take form, it can be applied back across all of the specific parts of the system. Iteration by iteration this becomes refined and well-integrated.

Evolving flow diagrams and a simultaneously evolving compilation of archetypal interaction elements and usages (a style and interaction guide) become the communicational tools that begin to bring consistent form and integration to this type of whole system.

In this way, the “vision” at the beginning is not necessarily a complete idea for how the final product or system will look and feel, but rather a vision of what type of integration and wholeness will be necessary for initial and long-term success.

While we’ll use mockups and prototypes for some aspects of systems like this, large-scale printed wireframes and storyboards are the primary communication tools my teams use to keep both the big picture and the details coordinated during development. Using these efficient methods, we’re able to bring a great deal of detail and consistency to complex products and systems, such as platform OS GUIs and associated suites of applications, or multi-device and software infrastructures.

Communicating a Vision (cont.) Luke Wroblewski

Guess it’s my turn to acknowledge we’re all singing kumbaya. Jim outlined a number of design artifacts that help with communicate and sell a design vision: thumbnail storyboards, flow diagrams, physical models, and architecture diagrams. These reiterate what makes design artifacts great communicators: information-rich, highly visual and compelling narratives that express both the macro (big picture) and micro (detailed) levels of a product vision.

Bob pointed out these artifacts loose a significant amount of value when presented without a clear definition of the problem they are addressing. Dirk started us off by stressing the importance of communication across an organization when trying to make a vision reality. So it seems we all agree that:

•	Clear communication is imperative for binding teams and stakeholders to a product vision.

•	Design artifacts and designers are particularly well suited to communicating that vision through: information design, models, narrative, prototypes, diagrams, and more.

•	In order to be effective, these artifacts needed to be presented in context. For Bob, this means a clear problem definition. For Jim & I, the narrative unifying the problem and solution is paramount.

We might, however, have different perspectives on how best to illustrate that narrative and thereby design vision. In my field (Web application design), I’ve had great success starting with highly refined product designs (mockups if you must) that begin meaningful conversations about the holistic design systems they imply. Other designers often opt for architectural and flow diagramming first – a process I’ve used many times as well. You can think of the difference between these methodologies as bottom-up and top-down design vision. Which one works best depends on the domain of the product (Web, mobile, physical) and your client’s perspective (product, business, engineering).

I’ve often found the top-down approach starts the process off with a bit too much abstraction for most of my clients (predominantly business and product owners) to understand. It can be quite a challenge to grasp product implications from an architectural diagram when you are not directly building or designing the system. As a result, I prefer to quickly sketch out architectural and flow diagrams for my own understanding, which I don’t initially share with clients. Instead I begin a very direct conversation by bringing visual design, interaction design, and information architecture decisions to the table all at once.

Once the conversation starts, I share high-level design artifacts such as information architecture diagrams to broaden the dialog to an entire holistic system, since the implications of higher-level decisions have been made understandable through the initial set of refined product designs.

Regardless of whether you communicate a design vision with top-down or bottom-up design artifacts, the important thing is start the conversation off right. If your client is a product manager, a refined mockup might work best. If you’re working for the VP of engineering, architectural diagrams may be better.

Too often, it seems that designers choose to make their full process visible right away instead of starting things off in a language their clients already understand.

Communicating a Vision - Jim Leftwich

Communication begins with mapping and understanding what is to be communicated. And so the designer or design group must have a broad and interrelated grasp (not simply a laundry list) of the human needs, desires, and opportunities for greater value (ease of use, utility, efficiency, aesthetics, and ultimately affinity) associated with the project or long-term strategic vision. There are many ways these can be mapped, but as a visual thinker, I prefer graphical and illustrated diagrams showing elements and interrelationships over bulleted PowerPoint slides when it comes to presenting dimensionally interrelated systems. Though when it comes to sleep aids, I’ll admit the superiority of bulleted PowerPoint slides over pills.

I began my career in the early 1980s, a medieval period that predated the age of interactive prototypes. So I developed a method of iteratively designing interactional architectures using a combination of thumbnail storyboards and flow diagrams. Even as interactive tools became available, I still opted for my paper method, as I’ve always felt it more effectively “laid it all out” in a manner that allowed the flows and options to be more effectively visualized, discussed with other designers and engineers, and refined and edited.

My decision to go with dense and detailed paper-based design also allowed me to avoid the time necessary to program or script mockups, and allowed me to concentrate on more interrelated detailing and/or alternative options for the design (which could then be presented simultaneously presented and discussed).

I’ve long had the advantage of working very closely and successfully with engineers and others that were capable of grasping and understanding the interaction as presented in the paper flows. And in the majority of cases, they were able to begin immediately and concurrently implementing the designs in the real software or hardware (even if in a rough prototype device), and so this made it unnecessary to produce an intermediate designer’s interactive prototype. Much of my work is involved in developing significantly or completely new products or systems, and almost always on extremely short schedules. Use of thumbnails and wireframes and paper flow models gives me the speed and immediate overview necessary to look at the system as a whole. My teams generally follow along or “read” these flows and act out the interaction. It’s faster than mocking it up during the exploration phases. We can explore ten ways and get a very good feel for why it’s better to go one way than another in the time that it would take to mock up just one interactive Flash piece. Speed and detail and attention to the whole is the priority in the majority of projects I’m developing.

Many times I have produced physical models (either simple foam form models, or highly detailed stereolithography models) in order to get a better feel for the ergonomics and rhythms involved with physical interaction.

In terms of communicating the architecture and higher-level interrelationships occurring in a large-scale system (separate from the work designing and documenting a component product or user interface and interaction flows within such a system), I also prefer illustrated diagrams showing users, interface and device elements, sequential actions and interrelationships, monetary flow, third-party participation or connection points, and other significant components and interrelationships. Often these will consist of multiple graphics, each covering one aspect of the overall system.

I’ve discovered that in many projects, and perhaps most importantly in large 200+ person government projects, that these are among the only overview documents showing the big picture in significant or meaningful detail.

How would I summarize the importance of design vision communication deliverables? He or she who owns the drawings, owns the vision.

Communicating a Vision - Dirk Knemeyer

Our Design Conversation series continues this week, moving here to my site. This follows the the previous two issues discussed, which were carried on Dirk Knemeyer's and Luke Wroblewski's sites.

The issue this week is be, "Communicating a Vision." Graphical approaches, stories, interactive prototypes, and more are discussed, along with our thoughts on communicating in a design project or ongoing effort.

One thing that's becoming clearer as we begin to get into specific approaches and methodologies, is the differences in our types of projects and development domains. Different types of clients (non-technical business people vs. highly technical Chief Technical Officers, for example), and comparitively standard categories of project (web application vs. custom multi-device OS and application framework, for example), lead to very different needs and approaches to the project itself.

This is highlighting the challenge in speaking about Design and approaches to development in universal terms, when there's such a wide range of types of projects, scale of efforts, length of schedules, and number and type of stakeholders.

The conversation continues to bring up interesting insights. This part will play out here over four days, beginning tomorrow with Dirk's and Luke's first thoughts on Communicating a Vision.

Our Design Conversation series continues this week, moving to Dirk Knemeyer's site. Our second issue in this conversation is the question, "What about an organization makes it ready for design vision?"

Our first question, "What is Design Vision?" was carried on Luke Wroblewski's weblog, Functioning Form.

This continues to be an interesting and enlightening undertaking. Luke, Dirk, Bob, and I had dinner this past Monday evening at the Empire Tap Room in Palo Alto, and had an opportunity to discuss these issues in greater depth. I think some interesting themes and insights are emerging, regarding the role of design in a wide range of organizations and situations, the challenges we face, and a range of strategies we've used to greater or lesser success.

This past month I was invited to participate in a most interesting and dynamic discussion project with four incredibly talented and experienced designers. The idea, as I learned, had originated with Dirk Knemeyer last November, inspired by writings on Luke Wroblewski's design blog, Functioning Form, and had expanded to include Bob Baxley, Director of the very talented design group at Yahoo! Search, and Andrei Herasimchuk, Dirk's partner in the consulting firm, Involution. Other commitments forced Andrei to withdraw before we concluded all the rounds of our discussion, but I certainly hope he can join us in the future, as his views are always strong and informed by his experiences as a practitioner. I'd known Andrei for some time, through the IxDA discussion list and local get-togethers. I'd met Luke and Dirk a little over a year ago when I participated in a panel discussion with them on The Future of Digital Product Design, held at Yahoo!. I was immediately impressed by the depth and breadth of their insights that evening, and the experience that informed them. I met Bob last Autumn, and immediately realized that we'd not only come to the Silicon Valley from Dallas at roughly the same time, in 1990, but also shared many common ideas and philosophies toward design.

I've always held practitioners in the very highest esteem. While I greatly respect the work and efforts by academics, researchers, and design writers, it falls upon the practitioner to actually transform the ideal into the real, and do so in the twin crucibles of the company and marketplace. And it's in that often arduous and dimensionally complex endeavor that the practitioner's know-how and vision is forged. And whenever such experience is given voice, the result is often refreshingly honest, grounded, and enlightening.

Our first Design Conversation, on the subject of Design Vision, will take place in four parts, with each part divided into individual responses and followups. The Design Conversation will take place across our four blogs, and is in part an experiment in form and dialog. You'll discover that our opinions do not always converge, and yet the process succeeded in yielding numerous issues on which we concur. The process left me not only much better informed as to the opinions and perspectives of my colleagues, but also granted me an invaluable opportunity to examine my own in reflection and comparison.

Design Vision: Introduction

In the later half of January 2006, a group of designers with nearly 50 cumulative years of experience designing products for companies like Apple, eBay, Macromedia, and Yahoo got together to talk about design vision. It was a concept for which we all had a personal definition -forged by our unique experiences and insights. Yet we all recognized the important role design vision played in our lives as designers so we took the first step toward a public discussion about what it can do for you, your organization, and your products.

Design Vision: a conversation about the role of design-driven leadership in the product development process.

	Bob Baxley - http://www.baxleydesign.com Design Director, Yahoo! Search Author, Making the Web Work: Designing Effective Web Applications
	Dirk Knemeyer – http://www.knemeyer.com Principal, Involution Studios Author, Numerous
	Jim Leftwich - www.orbitnet.com Founder/Principal, Orbit Interaction Articles and Publications
	Luke Wroblewski – http://www.lukew.com Principal Designer, Yahoo! Inc. Founder/Principal, LukeW Interface Designs Author, Site-Seeing: A Visual Approach to web Usability

The Design Conversation begins this week on Functioning Form. Stay tuned...

I went with friends last night to catch the new IMAX film, " Roving Mars." Wow, what a ride!

The film's based on the book, "Roving Mars : Spirit, Opportunity, and the Exploration of the Red Planet," by Steve Squyers, and presents the dual missions of the Spirit and Opportunity rovers, which were launched in June and July of 2003. It combines interviews with mission scientists, scenes from the the trip to Mars, and the fascinating discoveries that the rovers have been beaming back to us during their unexpectedly long lives.

From the triumphs and setbacks during the mission's development, to launch and arrival. to sweeping Martian panoramas, to the incredible machinic origami of the rovers, there's so much exquisite geekery to savor here!

My most common criticism of IMAX films has been that they're simply not long enough, and Roving Mars is no exception at just 40 minutes. However, it's an awesome two-thirds of an hour, and really makes excellent use of IMAX' immersive format.

The part presenting the Delta II rocket launch and trajectory insertion stages are more intense than what I remember from "Apollo 13." The sequence of events that take place in Stage 3 are particularly cool to watch. After Stage 2, the spacecraft still doesn't have enough velocity to escape Earth's orbit, so a 90-second rocket motor burn boosts its velocity from 19,500 to 25,000 mph. Just prior to this burn, additional small rocket motors spin the Mer spacecraft up to 70 rpm to stabilize its trajectory. After the burn, two weights on tethers are released to fly out like the arms of a ballerina, and slow the spin to 12 rpm before they're both cut loose to fly off perpependicular to the trajectory. Woah! Watching this on the enormous IMAX screen really blew me away.

Yeah, you get the bogus "sound in space" we're all annoyed by in film portrayals (except Kubrick's 2001: A Space Odyssey), but my friends and I decided that we'd pretend the microphone was recording from inside the spacecraft. Heh.

But the real value of this film is the sense of awe and admiration you get for the scientists and engineers that overcame great challenges and obstacles to succeed with these missions. This is geek heroism at its best.

If you're sick to death of being bombarded by evidence of widespread human stupidity and backwardness, go see Roving Mars. It reminded me of just how much we're capable of when we're at our best.

*Insanely* inspiring. Just go see this. Now.

R. Buckminster Fuller

During my college years in the early 1980s I delved deeper into Fuller's writings and creations, and discovered his ideas on systems, geometries, order, and balanced efficiencies. These greately shaped my own thinking and approach to product and interaction design. To this day, my work in interaction design and design strategy in general is informed and ordered by the interrelational and geometrically-ordered systems thinking of Fuller.

My 270-Strut Tensegrity Sphere

I was compelled to build some models of his tensegrity spheres, and luckily there was a kit on the market called Tensegritoy™. It came with thirty wooden struts, elastic tensional cords, and rubber end caps. I had a great time building, taking apart, and re-building many different configurations. Then I was struck by a startling realization - that a puzzle I'd had as a kid, and which I'd taken apart and never managed to put back together again, was most likely a tensegrity sphere as well!

12-Strut Tensegrity Puzzle

Ballet du Buckminster A small stop-motion animation

30-Strut Soda Straw Tensegrity Sphere

In the late 1990s I discovered the plans for building a tensegrity sphere out of soda straws, elastic bands, and paperclips on George Hart's wonderful site. I decided to make a small, colorful version a 30-strut sphere to sit on my workstation desk.

If you're interested in Fuller, or the spirit of his powerful ideas, I suggest you build one of these as a symbol. It's a relatively simple project, and makes a great addition to your geekosphere.

The Design Encyclopedia Logo

One subject category that I found a few examples of deals with the evolution of well-known corporate logos. It's interesting to study the changes in a brand symbol over time. Here are examples of the changes to the logos of John Deere, Kodak, and 3M.