Expert Interview: Murat Konar, Pixar Animation Studios

| December 20, 2011
Sign up to get weekly resources, and receive your FREE bonus eBook.
Thank you!

Get ready for some great content coming to your inbox from the team at UserTesting!

UserTesting sat down with Murat Konar, user interface designer for Marionette, Pixar’s in-house animation software. He started out as a software developer working on pioneering multimedia software including Flash and SoundEdit and earned a Masters in Interaction Design from the Royal College of London.


UT: What’s it like designing tools for internal users? How is it different from the consumer products you’d worked on before?

MK: Our user base is small, so we have really spiky user requirements. Sometimes you need to accommodate the peccadilloes of a single person because he can’t or won’t change the way he works. The challenges of designing for a small user base were a big surprise to me.

You’d think that being in the same organization–really close to your users–would be a dream situation, but it’s a double-edged sword. Users who only see their own small part of the puzzle will request that you design a feature the way they want. It’s a challenge to maintain design integrity that might not matter to particular users but is critical to the long term viability of our system.

Since we’re replacing a system that already exists, people already have ways of doing things. We often want to improve the way they do things, but sometimes people don’t like change.

Another thing that’s not obvious: organizations who make software for the general public have self-selecting users. When you make a design change, users who are unhappy with the change drop off and new users replace them. (Hopefully you have more new users than lost users.)

But our user base is captive. They don’t have the option of using anything else. We have to satisfy everybody.

UT: You’ve been at Pixar 6 years. Does the fact that employees stay a long time affect your work?

MK: Yes. There’s a culture that has grown up around the use of our old tools. some in use for nearly 20 years. It’s natural for people to resent having their old culture usurped, even if the replacement is better.

On the other hand, we’re constantly challenged to do new things that haven’t been done before. There’s not a sense of settling down. It keeps things from getting stale.

Every new film has its challenges. Features are driven by content, so you can’t anticipate how folks are going to use your tools.

Case study on creating realistic food for “Ratatouille.” 

Another consequence of long-time users is that training isn’t a big issue. Software that is instantly approachable is not as big a win in the long run as software that has user efficiency and productivity as a goal.

UT: How do you prototype your designs?

MK: Pixar is an intensely collaborative place; we run designs by a lot of people. Being able to communicate a design effectively is really, really important. Something I can actually demo is great way to communicate a design.

Early on, we focused on super-detailed design documents, but these wound up becoming negotiating instruments between production and engineering, and work wouldn’t start until everybody was happy with the document. Over time we realized that it wasn’t worth the effort to work out every last detail once implementation started. Unanticipated problems would pop up, and the final result was often quite different than what the design document called for.

So these days we’re working faster and looser, embedding designers in teams, doing some design up front to set the direction, but more importantly staying looped in during implementation to deal with the inevitable curves that come your way. It’s been working quite well.

UT: How do you validate your designs?

MK: We’ve identified people who are good at giving feedback. And of course we’re right down the hall. So if a design isn’t working, we hear about it. It does mean that the initial implementation of a feature is really a prototype, but the close proximity between our users and ourselves makes this not as expensive as it would be in more conventional settings.

I think an unmet need is how to identify tasks that are candidates for streamlining. User testing as usually formulated tries to identify aspects of the design that prevent a user from understanding how to use a site (app, whatever). That approach isn’t as good at surfacing tasks that are done 100 times a day versus tasks that are done once a week.

We also have a bug and suggestion reporting system integrated in the apps, so we get a lot of “sugs.”

UT: How has the world changed since you started designing software 20 years ago?

MK: In the old days (before the web) we used to use the same five or so apps over and over. Maybe just two. We used to live in those apps. Now we use lots of apps for short periods of time. On the web, every site is a different “app”, unique in some way from every other site.

There’s also a higher baseline of computer savvy-ness these days. Hardly anyone has never used a computer before.

UT: What has the Apple/Pixar way taught you about quality and user satisfaction?

MK: It’s not enough to value “good design.” You have to privilege it. It’s an organizational orientation.

That’s why Apple consistently puts out things people love, but other companies can only do it in spurts (or not at all). It’s not complicated. Focus on user satisfaction, and you will get satisfied users.

Lego Buzz and Woody welcome you to Pixar Headquarters in Emeryville