Design Leads & Wireframes

by November 11, 2005

[Editor’s Note] By popular request and with permission, Functioning Form is publishing some of Jim Leftwich’s writings on design. Part one of this series follows:

I have always believed in the speed, breadth of integrative power, and just sheer purity that a single strong design lead can bring to a problem. I'd qualify that further in saying that similarly strong leads in all the necessary aspects of product or system development (that understand the value of the others - i.e.: engineering, business, etc.) is even more powerful, but in my long career, fairly rare. What separates truly extraordinary and transcendent products or systems from the merely adequate (I won't even talk about poor efforts) is vision. Until such time that the communication and coordination between “separate minds” can reach the speed and integration of neurons within a single mind with vision and experience, the latter will always be capable of creating and “inspired” solution.

The higher up the food chain this capability and leadership resides (or is consulting into), the greater the likelihood of an inspired and elegant solution. Now this doesn't by any means insure larger business success, because there are many extenuating and complex forces at play in the product world. It also doesn't imply that such a leader is always “right”, but in the long term, and especially when it comes to significant or revolutionary “innovation” (as opposed to the overwhelming majority of development that is merely "me too" or evolutionary feature creep), a design leader with vision will very often drive a product or system to greater and more successful heights.

I ceased arguing about this years ago when my body of work and track record had piled up to a point where it could speak for itself. But it is true that I started my interaction design career in the early 1980s with the idea that such a thing was not only possible, but provable. I guess I'll have to blame a design education where the heroes were the Bauhaus designers and egoist architects like Frank Lloyd Wright, and maybe even good ol' Howard Roark.

While it's true that many design group processes have yielded great and significant successes, it's also true that I've been brought in by clients after some of the most famous of these have taken their whack at it. I've also witnessed internal development processes that more closely resembled a bunch of monkeys attempting to breed a football, than getting on with real and inspired design solutions. This is just a fact of group dynamics.

In over twenty years, and dozens of successful and complex projects, ranging from room-sized machines, to OS GUIs, to handheld and wearable devices, to medical systems, military devices and systems, financial software, interactive television systems, and more, ninety-nine percent of my design work and iterative tools have consisted of just storyboarded thumbnails and wireframe diagrams. I couldn't count the number of projects where I didn't have an opportunity to physically interact with the system until it was manufactured.... and then went on to win numerous design awards for its design and usability, and great economic and usability success in the global marketplace.

Okay, so am I saying prototyping is not worth it? Absolutely not. You see, when I started, there really were no prototyping tools of enough efficiency to be worth it. So I learned very early on to work in wireframes and thumbnails. And I learned to use these as the driving force of the projects, and as communication tools for interacting with the other developers and team members. In the early days, say from the mid-1980s to the mid-1990s, this was also efficient, as I had primarily only my own time and effort to spend on a project, and I wanted to make certain that I was spending my time pumping detail and functionality and specification into the project, rather than producing a dog-and-pony show.

Nowadays, another factor is coming into play - greatly compressed (and ever-accelerating) time cycles. Projects that used to take a year or two to create, are now regularly required to be finished in three months (at least the design phase). This means that as designers, you don't have one second to lose. If you're burning your effort on programming mockups (unless you're truly as fast as wireframes and storyboards, which I've not yet seen), then more power to you. But documents have a number of distinct advantages, in that they're more compact, provide more overview as to interrelationships “across the entire architecture”, and leave you with a document of your design that's more portable and accessible than a prototype. Particularly when showing a new client or team the “whole complexity” of what you've designed in the past.

Also, I have the ability to envision and play out interaction in my head. I guess this isn't a universal capability, but I'm certain that many have that ability because I've met them. Beethoven was deaf, after all. The human brain is capable of many different ways and talents of approaching problems. Bottom line here is that I mostly object to people saying something "can't be done" or "has to be done this way." I'm not claiming that everybody can design the way I do, but I am saying that it's possible, and have proof of its advantages and successes.

Some would say that interactive mockups are necessary as persuasion tools. This may hold for some, or even most people. Personally, I just push it through with my own force of personality. It's not always pretty, but it has always gotten the job done. And in the vast majority of cases, was later recognized as the right thing to do by those that might otherwise have been nervous at the time. What will establish this trust with clients or other team members, however, is proof of your past successes. You have to document your work and successes as you go. No other means provides as much throw-weight, if you want to take my approach to design.