Stuart Silverstein Experience Strategist/Designer

back to all articles

What do Pixar, Genesis and UX Designers Have in Common?

In 1995, following the success of Toy Story, Pixar animation studio tossed around the idea of starting a sequel to the hugely popular movie. The project was approved by Disney, and the production started in 1998. The initial scope of this project was to be a direct-to-video 60 minute video, however, on initial viewing of preliminary reels, Disney execs Pete Schneider and Joe Roth, decided to upgrade the movie to a feature length animated film.

Seeing as the movie was not a primary concern when production started, most of the more experienced team members were working on A Bugs Life. Additionally, Director Lee Unkrich described the story as “all over the place.” Once the movie was upgraded to feature, 12 minutes of footage needed to be added to the movie, so Chief Creative John Lasseter and the rest of the story team scheduled an emergency “story summit” over a weekend, which at the end they had hoped to have the initial 12 minutes that they needed.

In actuality, what came out of that meeting was a whole new story. Top to bottom rewrite. The team members took a hard look at what they had, and realized that ultimately it was a mess, and needed to be scrapped. It was a tough decision, but having an incredibly high level of creative integrity, they knew that they had to start from scratch.

But it gets better. They burned through so much time, that they had to deliver a completed film in 9 months. Just to give you perspective, a normal animated film (let along a cutting edge 3D animated film) took about 3 to 4 years. So this was not only an issue of throwing away thousands of man hours, but also producing the new movie in a quarter of the time.

As we now know, the movie was insanely good (I am an unabashed Pixar fanatic), and this was indeed the right decision. I am sure it was not an easy one though. However, the team had learned so much in the stuff that they threw away, that they were able to start again, from scratch, and build a story that met the goals of the new criteria: a feature length film.

Starting from scratch

When starting a new design project, we start by defining scope and requirements for the project, and once scope, requirements and strategy are defined, we start working on concepts. Oftentimes, we try several comps with different approaches. In trying those different concepts, we pick one to start with, and then retrofit requirements that are not met on to the approved direction, with varying degrees of success.

What happens when there are one or many several fatal flaws in the design that start to be uncovered? On a complex web project with several moving parts (social, commerce, advertising, etc), no matter how many questions you ask upfront, you are going to hit roadblocks. There are going to be requirements from other departments that the core team is unaware of. There is going to be a learning curve, especially if you work for an agency. At an agency, you will not have the benefit of a history and will have to take requirements at face value by a third party, and you may not have access to have a conversation with these people. This makes the job even more difficult.

If you add to this an expectation by client or stakeholders that the approved design would remain in tact, but that a few things will be retrofitted to accommodate the requirements, there can be trouble. I personally have found this situation a “lose, Lose” situation until I figured out how to handle it.

After presenting initial concepts, throw them out and start from scratch.

The Spike

Why would someone work for a few weeks, and throw away all the work? A builder doesn’t work for 3 weeks, and then tear down the house and build a new one? Filmmakers (usually) don’t film a movie and then start from scratch? Why would you complete a design and then throw it out.

In Agile development process, there is a term called a spike. A “Spike” is a short period of exploration where a developer will try a few things simply with the idea of learning what they need to, and finding out a strategy to move forward. It is timeboxed, usually to a sprint, and at the end of the sprint, all the code is thrown away.

Yes, thrown away.

The idea with a spike is to learn all that you can by doing it once, making mistakes, not worrying about clean code, trying stuff out, uncovering possible risks that can only be uncovered by working on something, and then writing clean code on the second attempt. Developers are often faced with new technology, and often have to program things that they simply have never done before. You can’t get everything right the first time you try something.

In design, we have experience with solving similar issues, but we never create the same project twice, so we are doing the same thing as developers: trying something new that we have never done before. Furthermore, we are working with a complex set of moving parts, all of which need to move seamlessly, so that the business, consumer and developers all are able to complete their tasks. It requires exploration.

The Fail

As projects have gotten more and more complex, I found by accident, that the idea of creating a concept and refining it, doesn’t work. I had the fortune of being on a few projects where the business lacked focus, and we had to start from scratch. In doing so, the things we learned in the first iterations led us to a bulletproof v 2.0. Fortunately we had not started development on a project that was just not right. We did what Pixar did, and threw it away. It just wasn’t right and it wasn’t working right.

One of the most important lessons I have learned is that good design does not need retrofitting. Good design just works. There is not a long list of exceptions for use cases. There is a minimal list of adjustments for use cases, but overall, I’ve found that if you find yourself coming up with an unreasonable amount of interactive accommodations, you have the wrong concept. Another barometer, is that after one round of revision, the excitement is gone, and there are a bunch of additional use cases that are not met. This is another sign that your design is not right.

The Solution

When working on projects now, I treat every concept as a spike, and throw it all away. I make note of all the things that are working, and bring those over to the new concept. I also have all the assets from the previous iteration, which saves a lot of time (although I start with a completely new document as well). By trying a lot of things, running into problems, asking more questions, thinking through more operational and user scenarios, you will compile your “real list” of requirements. Some things that you thought that might be negotiable, might not be possible due to time or budget constraints, and it is better to create a unique solution that is solid from the foundation than to retrofit an idea.

I also make it very clear to stakeholders that we will be starting from scratch on ONE concept from our findings, and we can do it in less than a quarter of the time. We will also come up with the right solution this time, and that the exploration allows us to try new things without hitting it out of the park on the first try.

If it’s the right solution. It will just work and you will know, and all the stakeholders will know.

Don’t be afraid to throw everything out and start from scratch.