Orbitstar Interactica - The Orbit Interaction Weblog
Orbitstar Interactica leads a small, but determined fleet of broad and experienced practitioners in search of the lost home planet called Generalist Interaction Design.
Site Links


Featured Presentation

Orbit Interaction
Palo Alto, California USA
650 . 325 . 1935 office
jleft (at) orbitnet (dot) com
Orbitstar Interactica Archive - January • February • March 2006

Design Vision :
A Conversation on the Role of Design-Driven Leadership in the Product Development Process
Acrobat .PDF
Luke Wroblewski has compiled our entire four-part Design Conversation - "Design Vision: A Conversation on the Role of Design-Driven Leadership in the Product Development Process" into a nice single Acrobat .PDF document.

About Design Vision:

In the later half of January 2006, a group of designers with nearly 50 cumulative years of experience designing products for companies like Adobe, Apple, eBay, Macromedia, Nike, Palm, 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.

- James Leftwich, IDSA 3/22/2006 1:21:19PM

Design Conversations
Communicating a Vision - Dirk and Bob contiue

Our Design Conversation series concludes this week, moving to Bob Baxley's site. Our fourth and final round inf this conversation delves into the all-important issue of "Getting it done."

The first entry of the fourth part begins with Dirk Knemeyer and Luke Wroblewski. In the second entry, I and Bob weigh in. Then in the third entry Dirk and Bob continue, and then in the final entry, Luke and I add our concluding thoughts.

This four-part series has been an interesting exploration of several issues crucial to the design of user experience across a wide range of products and systems. As our conversations progressed it became apparent that each of us sees design and the challenges present in our work through the unique contexts of our projects and work settings. Hence, Bob, as a Director in a large-scale corporate design position at Yahoo! is faced with challenges that differ in important ways from those encountered by consultants, such as me. And our work and challenges are further differentiated between consumer electronics and physical products, such as I often work on, and the web and desktop software designed by Bob, Luke, and Dirk.

In the end, however, we found many common issues and principles on which we agreed.

- James Leftwich, IDSA 3/20/2006 8:42:29AM

Design Conversations
Communicating a Vision - Dirk and Bob contiue

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.

- James Leftwich, IDSA 3/2/2006 12:03:48AM

Design Conversations
Communicating a Vision - Jim and Luke contiue

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


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.

- James Leftwich, IDSA 3/1/2006 12:05:26AM

Design Conversations
Communicating a Vision - Jim and Bob begin

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 - Bob Baxley

The most important part of communicating any design is to clearly and unequivocally state the problem the particular design deliverable is intended to solve. Too often, a designer presents a prototype or mock-up without any context or reference to the problem driving the situation. And without such context, the discussion invariably devolves into a swarm of opinions, conjectures, and personal preferences.

By contrast, if the designer spends the time to properly understand, articulate, and frame the problem being solved, they can pull the audience along with them as they rationally, logically, and inexorably proceed, step by step, from the stated problem to the unavoidable solution.

Showing the logical chain of decisions has to be the mission of all design communication. The question of prototypes versus specs versus PowerPoint versus sock puppets is ultimately an issue of communication strategy and one that is dependent on the sophistication of the audience, the complexity of the design problem, the goals of the products, and the amount of time afforded.

Of late, I’ve taken to not even looking at visual design comps until the designer tells me what emotion(s) they are trying to communicate. When presented with comps I simply turn them over and ask the designer, “What am I supposed to think and feel when I look at this?”

Too often, the designer can’t provide me with a clear and concise collection of qualities, values, or feelings that the design is supposed to elicit and as a result, I have nothing much to offer by way of critique other than off-the-cuff comments and knee jerk reactions -- hardly the sort of things that should form the basis of a design decision.

This is I believe, is the fundamental difference between a designer and a stylist. The former is an analytical, directed problem-solver while the later is a wanderer and a guesser, hoping they’ll stumble across something the client likes.

To sum up and as a corollary to Jim’s final point: he who can define the problem, declares the solution.

- James Leftwich, IDSA 2/28/2006 9:34:07AM

Design Conversations
Communicating a Vision - Dirk and Luke begin

Communicating a Vision - Dirk Knemeyer

Communication is vital to a successful design project. After all: the final designed product is only part of the challenge facing a company. To enjoy long-term and sustainable success, a company needs a healthy culture, which is dependent upon the people in the organization. If they do not feel like they are part of what is happening, personally feeling ownership and participation – no matter how far-removed they might be – they will not be productive, positive contributors to the good of the organization.

Strong communication can create a feeling of shared vision in an organization, even among people who are far-removed from the actual product or design process. One of my favourite stories – and it certainly may be apocryphal – is about JFK touring Cape Canaveral in the early 1960s. On the tour he came across a janitor scrubbing the floors:

JFK: Hello friend, what’s your name and what do you do here?

Janitor: My name is Ray, Mr. President, and I’m helping to put a man on the moon.

The point of the story being, that because of the shared goal and high organizational morale – the product of strong communication, starting with the President himself (“We will put a man on the moon by the end of the decade”) and running all the way down – everyone including the janitor saw their place not in terms of the specific role they did, but framed within this ambitious, even audacious, goal. And of course, they were actually successful, in no small part due to the shared vision.

Communicating a Vision - Luke Wroblewski

I’m going to start off with a loose definition of leadership. Leaders establish a vision, they bind their team and stakeholders to that vision, and then drive for results to make the vision a reality.

This vision does no one any good if it cannot be communicated. The team doesn’t understand what they are trying to build and why. Stakeholders don’t feel their needs are being met and driving for results is next to impossible: people simply don’t know where they are going. Luckily, when it comes to communicating a product vision, designers have a full arsenal of tools at their disposal including: narrative, information design, visual design, and prototypes.

These types of design artifacts can help bring a team or an entire organization together around a shared vision. As I like to say: “design is communication. Use it as such.”
- James Leftwich, IDSA 2/27/2006 12:02:41AM

Design Conversations - Issue No. 3

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.

- James Leftwich, IDSA 2/26/2006 3:02:12PM

Design Conversations - Issue No. 2

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.

- James Leftwich, IDSA 2/12/2006 11:34:08AM

Design Conversations - A Designers' Roundtable Discussion

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 Knemeyerhttp://www.knemeyer.com
Principal, Involution Studios
Author, Numerous
Jim Leftwich - www.orbitnet.com
Founder/Principal, Orbit Interaction
Articles and Publications
Luke Wroblewskihttp://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...

- James Leftwich, IDSA 2/6/2006 3:07:12AM

Roving Mars - The IMAX Film

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.

- James Leftwich, IDSA 2/4/2006 10:59:19PM

R. Buckminster Fuller and the Tensegrity Sphere

R. Buckminster Fuller

All designers have their heros and inspirations. No designer has influenced my own thinking and philosophy more than R. Buckminster Fuller. Even as a child I was drawn to photos of his gorgeously pure geodesic domes and spheres, which I encountered while reading the Worldbook Encyclopedia.

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

Of all of Fuller's geometrical architectures, the type I was most fascinated by were his tensegrity structures. These combined compressional and tensional elements in geometric configurations that utilized their unique strengths in the most efficient and symbiotic manner.

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

On my next trip home to visit my parents, I looked in the endtable cabinet in our living room and sure enough - there were the pieces to that wooden puzzle, where they'd sat disassembled for over fifteen years. Within a few minutes I'd reassembled what I now knew was a 12-strut tensegrity sphere, and placed the hand-blown glass sphere back in the middle. It was quite a moment, sitting there and realizing how I'd come full circle with this object after so many years.

Ballet du Buckminster
A small stop-motion animation

Next I set out to build a much more ambitious tensegrity sphere. In Fuller's books I'd seen illustrations of 270-strut spheres. Over the course of the next month I pursued an incredibly tedious, yet rewarding project of building the components and discovering the specific geometries necessary to assemble it. I still have the wooden 270-strut sphere in my studio today, and it continues to inspire my thinking. I even used the Kensington VideoCAMworks software I designed to create a stop-motion animation of it, along with two other tensegrity spheres - Ballet du Buckminster.

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.

- James Leftwich, IDSA 1/31/2006 4:02:27PM

The Design Encyclopedia
I'm a huge fan of Wikipedia, the free online community-built encyclopedia. I find that I often spend considerable time clicking on the "Random Article" link, which is reminiscent of one of my favorite childhood reading activities. Often I'd grab a volume of our World Book Encyclopedia and sit down in our reclining reading chair, randomly reading article after article. I often preferred this to watching television, and I credit it for having instilled a life-long love and preference for subject matter and documentaries.

The Design Encyclopedia Logo

Recently I was excited to find another community-based encyclopedia focused on the wide field of design. The Design Encyclopedia is just getting started, but is growing and promises to become an amazing resource for design information and history.

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.

- James Leftwich, IDSA 1/29/2006 7:05:41PM

In The Beginning
Today marks the beginning of a new weblog, Orbitstar Interactica. It will feature pointers to interesting design items and news, observations and comments from the wide field of product and interaction design. From time to time it will also present essays and collaborative design discussions with others from across the broad field of design and development.
- James Leftwich, IDSA 1/29/2006 7:03:05PM

About | Clients + Portfolio | Boards, Research, Conferences | Publications and Awards | Orbitstar Interactica Archives | Design Conversations Archive
All content is © Copyright 2006 James Leftwich / Orbit Interaction unless otherwise indicated.
Please contact jleft (at) orbitnet (dot) com with any questions or comments