“Innovation has nothing to do with how many R&D dollars you have. When Apple came up with the Mac, IBM was spending at least 100 times more on R&D. It's not about money. It's about the people you have, how you're led, and how much you get it.” - Steve Jobs

Not all rapid iteration is design.

One of the great parts of a good design process is around rapid prototyping. People seem to have taken this spirit to heart lately with the Web 2.0 movement. But is that really what is meant by design?

I don’t think so. To me, rapid prototyping is nice, but if all you are doing is having everyone working on one prototype you miss the important piece of design exploration, which is breadth of ideas.

Yes, it is important to implement, get feedback and make changes, but that is not design. That is engineering. It is incredibly linear and bottlenecks your creative team around a slngle energy flow.

At IntraLinks, I have been developing a process that meets the linear needs of my development group while at the same time hold onto the advantages of the design process. It is not orthodox in various respects, but the results I have been seeing by the design team and the effect culturally it has been having throughout the organization has been quite dramatic.

I am not allowed to go into too many details in this, but I’ll try to explain as much as I can.

This particular project started off with a clean slate. Always a more dramatic and well more exciting beginning for any designer. The design team is not focused on functionality, but rather on the following elements: flow, behavior, structure and presentation. This freed us a bit as we didn’t have to deal with the distraction of thinking up functionality to express with those 4 criteria as that was already done. I know some might be upset with that, but we have had a great effect in that process even without leading it directly.

Since the functionality was well understood by the design team by the start of this project, it was easy to just say, “Go!” and light a match under our butts. We gave ourselves a series of tight deadlines. This was important because when time is too open, things rarely get done. The first process created prototypes of 5-7 distinct frameworks for structure and interaction. These were done by just 2 designers over 3 weeks. At that time we received feedback from the x-functional team that allowed us to reduce our direction to 3 designs as we began to explore further the depth. We went from 3-5 screens per design type to 20 for the 3 chosen designs.

After a renewed feedback period, we struck a line at 2 of the concept directions. We did a deep validation internally of these design concepts but froze the designs themselves. During this process we chose a single direction, but learned that a change was required to a fundamental aspect of that design due to business considerations and scalability issues. After this shift we ended the framework period of the design process.

We are now in the next stage and again, we are going to go broad before going deep again. Or actually we are going broad AS we go deep. The framework itself needs to be tested by submersing it into the full functional needs of the application. But intead of locking too strongly to the design itself, we have now 3 designers working on different aspects of that depth, with explicit direction to hold onto the spirit of the framework, but do not feel obliged to lock yourself to it. As you come across aspects of the functionality that require new elements that the current level of framework design has not covered.

The goal here is that as each designer works on filling in the framework with rest of the design needs, they will be exploring similar patterns in different ways. This creates the opportunity as before with the frameworks themselves of discovery. After this phase of design we will be able to mix and match these ideas as we did the original 5-7 framework designs for a better whole.

What is important here is that we don’t re-open the box of the framework itself, except if we discover places of failure in t. What we are trying to do here is move forward through exploring broadly at a new level.

Here is a comparable exercise:
1. Design an input device that is for object & action selection, drawing, etc.
1.A the solutions delivered include a broad array of mice, trackballs, pen/pallette, laser pointers, touch screens/finger, etc.

2. Ok, I like the mice
2.A ball-mouse, optical, multi-button, scroll-wheel, ergo, gyro, etc.

3. optical mouse with a scroll-wheel, that is right-hand/left-hand ergo, w/ multi-buttons for gaming
3A. a host of different presentation designs ensue
3B. a 2nd exploration that now are limited to the brand and product mission statements
3C. a 3rd exploration that incorporate new market information such as blue-tooth instead of radio, re-chargability, light factoring, manufacturing costs etc.

This type of process is what I’m speaking about with the design of GUI treatments. But iti s precisely this type of design process that is NOT being done throughout most of the software product design community. And the Web 2.0 community of “beta now” are also not seeing that what they are doing, is the same thing as before, only more hurried, and only using “feedback” as a means of validation, instead of the rigors of research oriented validation.

While interesting product definitions are being created, I’m not so sure that many will break acrosstthe chasm unless they grow up (aka are bought) and change their was to incorporate more of this type of design process.

Will Basecamp ever be more than an early adopter program? Would Flickr ever be where it is today w/o the purchase by Yahoo? The reason I mention this is that both “successfuly” Web 2.0 products have steep resistance in my experience. I still cant’ get my mother to join Flickr and it is very hard to ONLY use Basecamp and not mix it with other hosted programs like JotSpot and Writely for their added or specific functionality. But more importantly the very functioning of Basecamp has limited appeal. The concentration on functionality (even usable functionality) without a further concentration on context of use and usefulness in context will limit these properties to the the other side of the chasm for quite a while.

Before we begin the next step we are going to run focus groups on the framework designs across as many users and user types as possible. It is just too expensive to get to all the different roles and organization types we would need to in a 1-on-1 paper prototyping session and since we are still not doing interactivity in the system it makes most sense to gather larger numbers of people in the room at the same time. We are aware of the limitations of focus groups, but feel that the risks are worth the added numbers of people we can get for the money.

From this validation we move into the next step of design by adding interactivity.to a prototype. As I mentioned in my article about Pixar at the MoMA, it is vital that we put 2D to 3D (3rd D – Time). The only way to truly do that is through interactivity. We are struggling with the best way to do this. There are two options we are considering–flash or xHTML. Both have their advantages and disadvantages.

I’m favoring Flash because it allows for more functionality and while some suggest that we need to design for the medium, I would counter that at this stage of design you want to design away from the medium. It is the only way that we will push it. See my previous article on why AJAX now.

After this level of prototyping, we will usability test (the lab) the prototypes, and then finally iterate on that. All the while closely staying loooped in witht he following parts of our organization: Product Management, Development, Customer Service, Sales & Marketing, and Quality Assurance.

After this level of prototyping, we will move into the documenting phase by the creation of an object library that development and QC will use through their processes for design and implementatoin.

Be Sociable, Share!


The archives run deep. Feel free to search older content using topic keywords.