In this interview, we talk with Doug Look, who’s a strategic designer for Autodesk Labs. The labs are interesting because they’ve built a strong, engaged, community around closed-source software. In this interview, we specifically cover:

· Using an online “Lab” to engage the community in closed-source development.

· Does open-source tackle interdisciplinary problems well?

· What does an interdisciplinary team in action look like?

Scott:  Thanks for taking the time to chat. Would you mind introducing yourself?

Doug Look:  Sure. I’m Doug Look. My role is senior strategic designer for Autodesk Labs. That means, essentially, overseeing the design aspects of the solutions that we’re exploring at Autodesk Labs. Autodesk Labs is a place where we preview and share new technology. Our intent is to share things early enough in the process so that we can get a good read from our customers and from users as to what works, and what doesn’t work.

I have a particular interest and background in user centered innovation. Before I came back to work at Autodesk Labs, I had gone back to school at the Institute of Design here in Chicago, and I completed a Master of Design Methods program. It’s about design innovation methods and processes, and a lot of focus on going out to understand user needs, by using ethnographic and social sciences techniques.

The thing I’m hoping to bring to the labs, and back to Autodesk, is the notion of understanding user experience. You’ve probably heard that term used a lot. And we’ve got some really, really smart technology folks in the lab, and my role is to represent users and help us focus on doing things that make sense to our customers.

Before this line of work, my formal training and my experience had been as a practicing architect. I’m a second-generation architect and practiced in upstate New York, in Ithaca, for about 17 years. That’s my background.

Sean:  Thanks. Could you tell us a little bit more about Autodesk Labs? We’ve visited the site and taken a look at it, and it looks like what we sometimes refer to as a “Pirate radio station.” It’s a site that’s outside realm of the main corporate site.

That’s useful in terms of building a sense of community, or running certain kinds of product releases early to get feedback. So tell us a little bit about how that site got developed, and your particular role in leading it, day to day.

Doug:  I think you got it just right. I wasn’t around when Autodesk Labs was established, but I think it’s been around for just under a year. It is a way to engage customers and users. It allows us to put up trial balloons for new things that maybe the engineers cooked up.

Every so often, we get requests through entries in the blogs, or there’s someone from a discussion group requesting a certain feature. One example was somebody wanted an easy way to publish their model information from Autodesk Inventor to our Freewheel site, which is our zero client way of viewing both 3D and 2D model information. Folks at the labs took it on, and I think within three weeks or so, they had something up.

It’s really a test-bed. We have the ability to maybe have a little bit less process than other parts of the company, because this is not production quality kind of development. It’s really about offering as much as you can, getting it out there, with the hope of getting early and direct feedback from our users.

Sean:  So would you say the site predominantly informs the mainline products that you develop, and that things from the test bed may make it into the products?

Doug:  This is a place for us to test out new things. We’re looking to see if things are possible, to see if customers resonate with some of these ideas. I guess it’s fair to say that we have a little bit more leeway in terms of the things that we pursue, because if it works, great. But, hey, part of it is also finding out what doesn’t work.

Scott:  In terms of the site’s influence, what are some things you could point to that have been canted or targeted to a different direction based on the discussions or feedback on the Labs site?

Doug:  I think we’ve gotten some good feedback, some early feedback on a number of early concepts. One of the so-called graduates of the lab is something called Autodesk Impression. This is a way of taking CAD data and kind of putting different filters on it and rendering it. As I understand it, there was good, direct feedback, and the development team was able to take that into account. We felt confident enough that it is now a product.

Another product that we’ve pulled together is called ShareNow. It’s a plug-in, basically, for Autodesk Inventor, Revit, and AutoCAD. It came directly out of a request that was fielded through Labs. This lets you upload and share your 3D and 2D model data directly into a Web application where anyone can view and navigate the model.

I don’t know if you’ve had a chance to look at the site lately, but just the other day, we got an early version of Content Search posted. There’s also something called Project Showroom, which is an experiment to see how people feel about being able to view virtual spaces. Plans are rendered on the fly, and tested out with different products.

Those are examples of things that we’ve done.

Sean:   I’ve seen both of those. The Showroom one actually stood out to me as well.

Scott:  In terms of the lab, how does that process work? When somebody requests something, how do you prioritize what to work on and what to move forward with?

Doug:  I think it’s on a case by case basis. It’s a fairly small and fast team. We get feedback, not only from the discussion groups, but we’ll go out at customer events, and even arrange our own visits with folks. We just try to use it as a way to gather feedback. There’s no formal process that we crank it through. If it seems to make sense, it looks interesting and we have people that are available to do it, then we’ll go for it.

Scott:  OK. Which I guess makes sense, but it’s kind of based on a feeling of whether the idea really has legs and would really benefit people?

Doug:  Yeah, that’s it. I’d say that, based on our experience in the design industry, Autodesk has a good feel for what might benefit users. We’ve gained a wealth of rich knowledge from customers over the years (through customer surveys, beta testers, customer councils, AUGI, and the like), that’s helped provide a base of understanding to work from. We also want to take advantage of my background from the Institute of Design. I think one of the things that we’re hoping to do is get out in front a little bit, and do a little bit of generative research. Go out there and do some observations and interviews with folks, much like the way you guys are learning more about this open source notion by talking to people.

I think that, if we had a chance to do some of that research, analyze and synthesize, that would also help inform the direction in which we move, in terms of what we should be developing. One of my roles, one of my goals, is to keep focus on what users are really doing and trying to do, and focusing on user centered needs. Quite frankly, at this point, with the technology and with the experience of the developers that we have, a lot of things are very possible.

Scott:  How much of what you guys are doing was inspired, or triggered, in part by what you have seen open source projects do, in terms of developing in the open, making sure that people have a really clear line of sight to a project from pretty much the light bulb going off and the idea being conceived, all the way through development?

Doug:  I think that there are some interesting parallels. I think that what’s interesting to me about open source development is this notion that you’re making things completely transparent, that you’re going out and involving a large community of users, so you’re getting representative use from a lot of different areas.

If those are some of the guiding principles for open source, I think those are some of the principles that we’re trying to use in Autodesk Labs as well. It’s really to have that focus to be on being transparent and trying to get a full understanding and get input from our users and our customers.

Sean:  I trot around with an iPhone and a Mac, and I’m interested in what’s been called “peak experience.” Do you think open source can reach the level of peak experience, from a user standpoint, and usability standpoint? It feels like it’s easier for closed-source to have a rock-solid vision, but I’m not sure. I’m personally on the fence; I feel I’m still investigating this.

Doug:  It’s a tough problem, whether you’re open source or closed source, to come up and nail that incredible customer experience. And I think you touched upon it a little bit when you talked about having some kind of rock solid vision. I was thinking about that earlier today, and specifically thinking about Linux.

Torvalds had a rock solid vision, did a bunch of work, and made an open source development community. So it’s really possible to get things jump‑started.

Whether or not, you can turn it into the iPhone experience without someone constantly driving a singular vision and tying together maybe all the different constituencies somehow, I think that seems to be one of the challenges.

The other thing I was thinking about relative to this was… I’ve been reading this book, “Designing Interactions,” by Bill Moggridge, one of the founders of IDEO, and he has these really interesting interviews.

In one of them, he’s interviewing David Liddle, who worked on some of the original Xerox Star interface. And he explains development of technology and he breaks it into three phases; one is the enthusiast phase; the second is the professional phase; the third is the consumer phase.

I don’t know for sure, but I have a hunch that maybe the open source side is really great at the enthusiast stage but that what you really want are really quick and rapid iterations and lots of input from lots of sources and you’re maybe not as concerned with everything being all exactly worked out. You’re really just interested in pushing the ball forward as quickly as you can.

When you then need to move that forward into the professional phase ‑ when it needs to get more robust and you need to maybe, in some ways, to clamp things down a little bit. And then, at the consumer phase, that’s when you need to pull it all together and simplify it and make something beautiful as an experience, not just the way it looks.
So my hunch is that maybe some of these different development models are a bit more applicable to different parts of where a technology might reside in each cycle.

Sean:  OK Fair enough.

Scott:  One of the things that you said the lab lets you do is iterate and try things out and not go through as much process.

Doug:  Right.

Scott:  One of the things that we’ve found in talking to closed source companies is that, when you come out with a new version of a product, there are business reasons to make fairly substantial changes to the product. You want there to be enough of a delta between V2 and V1 of a product that people see a reason to upgrade and they see value in the new version. In closed source, your previous version is competition.

This pushes closed source, proprietary products, to trying to add a lot of value from one version to the next. Open source, on the other hand, can move much more incrementally. The people working on the Linux kernel, or working on a patch, they’re just out to get it right. They’re not out “selling” and upgrade of the web server or the kernel.

The challenge is that sometimes companies will think up a fairly grandiose idea, but when they actually ship it, it ends up being a flop and a lot of wasted effort. Do you feel like that’s one of the reasons for the lab, is to really track with what people are going to use and to keep your pulse on what people are going to find interesting and compelling? Or are there other kinds of benefits you get that I’m missing in my analysis?

Doug:  I think that one of the main reasons for Autodesk Labs is to get that early feedback. You guys are familiar with the software development process. By the time you are really at the stage where you’re giving early access to your product, in a normal product development cycle, it’s really almost too late to make any significant changes.

I think the theory, anyway, with a place like Labs, is that you get early leads and do quick prototyping, with the expectation that it isn’t production quality, but with the goal of really gaining user input and feedback. That’s really important.

I’ve noticed a difference, since my first tenure at Autodesk, that this is very important to the company. When I worked on some of these earlier development products at Autodesk, our team, didn’t know what we were doing was bleeding edge or anything, but we actually went out and we were doing early prototyping and sharing early versions of our ideas with our customers, even before things were coded up.

And I think, at the time anyway, that was a fairly unique process at Autodesk. And yet, today, if you look around, at least from what I see in the company, there’s a huge effort to go out and gain this early user feedback and use it to inform the process, early enough in the process.

Scott:  For a long time in business, it seems like the thinking was: “Absolutely don’t show the product until you have to. Be worried about what competitors will do if they see the direction that we’re going.”

Doug:  Right.

Scott:  ”Try to keep it under wraps.” And then, when you release a version, release it with a lot of fanfare. Now, the trend has moved to be very transparent, and have a really good dialog with your users, and get some of their ideas and enthusiasm to infect your development team so that they’ll build really cool stuff. What happened to the fear of the competitive threat? Is it there, but people have just recognized that they just can’t really worry about that? Or how was the thinking able to shift?

Doug:  My perspective of that is that I think that companies are finally starting to realize how really important it is to understand the customer. 10, 15, 20 years ago, the people that were using applications, using computers, were willing to put up with a lot more heartache, because they were enthusiasts and you didn’t have to really do as much to get people to like what they were purchasing or using.

Now on the user side, people are more mature in terms of their attitudes towards the use of technology, and they have quite a bit to say. It’s great that we’re changing this around — going out and really listening — and using that to inform our thinking.

Scott:  Is there a concern that competitors might look at what you’re doing and get there sooner? Or is that just the risks you have to take to do business?

Doug:  What tends to be happening is that, as companies are being forced to do things quicker and quicker in very fast cycles, the development times are way down. I don’t know, maybe because things are so quick cycled, there’s a little bit less concern about somebody else catching on and doing it. You can’t stop. You keep on developing and you keep learning and you keep moving the ball forward.

Sean:  You said earlier that open source projects often exist to initially solve a technology problem. And then there’s this life cycle of the products as they go through, and it eventually gets more refined and distributed to consumers.

Do you see any open source projects that you feel exhibit a good design aesthetic? I mean, I’m not of that field, so hopefully I’m using the appropriate phrase, but have you looked at something where you say, “Look at that. That was built in an open source model. I love the way they did design. They really seem to understand the usability aspect, and I would think that’s a good model of it.”

Doug: Since I figured you guys were doing all this research, I wanted to ask you that question. [laughs] But I guess you haven’t found the answer yet.

I guess I’m not aware of any of the open source efforts that have this slant, or ones where design seems to have billing, in the holistic sense. Maybe people haven’t reached the point that that’s an issue yet. I don’t see why it couldn’t work. If there was kind of a call to arms for designers to get out and solve at the interaction level or visual level or how the applications or platforms are working, you’d probably see kind of a community of designers get involved. Communities really have taken off at Autodesk. Labs is just one; there’s a manufacturing community, a civil community, and of course AUGI, our international user group.

Sean:  In open-source, it seems that credibility resides, to a large extent, in technical capability.

Do you think it’s, perhaps, nothing more than the habitual disconnect between the person designing, who has a different focus for their intellectual tasks than someone who’s simply trying to write code, and it’s kind of an impedance mismatch that never really fully settles itself out?

Doug:  Yeah, I think you’re right. Different people think in different ways, and in terms of the design side, those are different skill sets that maybe aren’t being called upon yet. This, again, doesn’t mean that that couldn’t happen.

Design is kind of part of this open source notion. It’s not really open source to the same extent, but you see every day in this little Web 2.0 world, people doing mashups and taking components that they’re finding from anywhere and kind of putting them together and making really interesting applications.

And I think, at least in the Web 2.0 world, design does seem to play a role in that. Not only as the underlying technology, but also the way things work, the way they feel, the experience that they’re giving to their users.

To me, that’s along the same lines as that open source on the design side, kind of this democratization of the process. Anyone can participate. I think that’s a really strong idea to, perhaps, get some people to talk about and challenge the design community to get involved in one of these things.

The other example, and it’s not a direct one-to-one example of software development, but there’s a group called Architecture for Humanity. Are you familiar with them?

Sean:  I’m not. I’m not.

Doug:  They gave a really interesting talk at one of the TED conferences, and actually ended up winning one of the prizes. They created an open source design network for solving architectural and environmental problems.

And what they’ve done is created a way of getting designers to input ideas into this network, and share out all these ideas with anybody who wants to participate and work.
One of the mechanisms that they used to do this was what’s called Creative Commons licensing.

Sean:  Yep.

Doug:  I just think that that’s another hint that there are certainly opportunities for the design community to get involved in the open source development world.

Scott:  And I’ll just make an observation on that. Open source seems to work when it’s used in a single discipline environment.

So if you want to contribute to Open Office, you pretty much have to be able to write code. If you want to contribute to the Linux kernel, you pretty much have to be able to write code. If you want to affect the user interface, you have to be a coder, rather than a pure designer, to do it. There isn’t a lot of ability…

Doug:  In the environment that exists today.

Scott:  In the environment that exists today. And what you talked about with architectural design was, again, fairly single disciplinary, right? It’s these architects sharing these designs.

And so you find this a lot, and I think one of the chasms that open source hasn’t yet figured out how to cross is to pull together an interdisciplinary team to solve a problem.

Doug:  And I think that’s where some of the really interesting things get solved, is when you’re working on teams that are made up of different individuals of different backgrounds and different perspectives.

That certainly happens on the open source development side, because you’ve got people from all over the place participating. But I’m not familiar enough with the way the process works. Do they ever get in the same room, or share a whiteboard and talk with each other? Or is it really just in the check‑in, check‑out of code?

Scott:  It depends on the product. Some products, like MySQL, really are open in the fact that the code is out there and somebody could fork it, but everybody who’s working on it works for the MySQL company.

Other things like Apache and the Linux kernel and a lot of other stuff, really is built over a mailing list, and they never do physically get together and whiteboard stuff.

Doug:  Maybe some of the limitations are there just because of the way that the environment, as we’ve been talking about it, has been framed out. I mean, what’s to say that if I wanted to get in and share some ideas and thoughts about the user interface with Linux, that I couldn’t just post some bitmap graphics to the nodes or a paper on some ideas that I wanted, not necessarily checking in and out source code and coding.

Scott:  I’m going out here on a limb, and if I’m off base I hope readers of this interview will comment and correct me, but it seems like open-source emulates (dare I say, copies) work that interdisciplinary teams have done. I don’t know that there would be an Open Office if there hadn’t first been a Microsoft Office.

Doug:  Right.

Scott:  The Linux kernel was obviously patterned after UNIX. Apache, on the other hand, was built from scratch as a web server. A lot of times open-source isn’t doing things that are interdisciplinary, or if it is doing something interdisciplinary, it’s because those interdisciplinary skills exist in certain unique individuals. You have a cryptography expert who can code. You have someone who can both envision a better process/thread scheduler, and can code it up as well. If you’re just a mathematical researcher, but you’re not a coder, I don’t know that you have a mechanism to get the fruits of your research into the product. You have to hope a coder will pick up your research and run with it.

Doug:  Right. You guys are writers, and write books and such. I guess the question that I have is for a process like creative writing, say take creative writing, could you imagine writing a novel by open source methods?

Scott:  Well, sure. Or definitely you can write an encyclopedia with open-source methods.

Doug:  I’m talking more about maybe something less technical.

Sean:   In other words, something that has a plot, a logical consistency, the characters don’t jump from one island to the other. So it’s not like the grammar school game of the story starts out on row one and by row five, essentially they’re slaying dragons on space ships all of the sudden.

Doug:  Yeah, these are just questions that I don’t know the answer to, but I think they’re really interesting ones to ask. I mean, whether or not the visual kind of design, where you’re working in concert with each other, can produce that kind of deep user experience, using an open-source model… I don’t know.

Sean:  Let me switch gears for a minute here. In terms closed source, talk about how Autodesk handles the process of weaving design in as part of a product. Walk us through the life cycle of a feature that required high design characteristics, and how that came about from inception through production.

Doug:  I can tell you a little bit about the initial way we developed the Autodesk Design Review product. Maybe that’s a good way of sharing how we went about doing that.
I was a senior product manager and I was working very closely with the senior product designer. And as a team, we went out to gather requirements. We had product management and product design go hand in hand, out to the field to talk to, interview, and observe customers.

So instead of starting with, “OK, we have this technology, what are we going to do with it?” we went out and talked to customers to see what they really needed. And during that process, we started getting hunches about the need for different kinds of tools to help people review and view their design data, and so we started doing prototypes.

The prototypes were not technology prototypes. They were not coded, they were graphical visualizations of the way these applications might work, or the way certain features might work. And in that process we would share this with these users and get a ranking of what’s important.

It was really interesting because every time we would go out we would think we knew that, “The customers are really going to love this red pen feature that we’re just crazy about,” and we’d have to have them rank it, and guess what? The red pen thing, they didn’t really think it was that important.

Sean: Out of their hundred dollars they spent zero on that feature.

Doug:  Right, exactly. And that was on a consistent basis, so it really comes down to not necessarily what the designers of the project think, it really is what do the customers think, what do the users think of this thing? Because we had done early prototyping and got it out there early, we didn’t have code yet. One of the things that we identified very early on, which we almost didn’t even pursue because people were saying, “Oh, no one cares about that,” was the issue of roundtripping redline mark-ups.

This is the ability to present an AutoCAD drawing, publish it out, have someone basically do a mark‑up on it digitally, and then ‑ and this is the part that we learned ‑ then getting those mark-ups back into the original CAD file. That was huge!

Before we had gone out, and people were telling us, “Oh, nobody needs redlines, they don’t do redlines.” The key thing we learned is that it doesn’t work because it doesn’t round trip. So that was a really great example of how we just didn’t know, we had to go out there and learn by interviewing and observing and really finding out what people really thought.

Scott:  On the closed source side, it is pretty easy to sort of put together an inter‑disciplinary team. Microsoft will sometimes even throw in a cultural anthropologists, and things like that. How do you resolve issues, though, if you’ve got designers who have envisioned something that might be a great user interface experience, but the coders look at it and say, “You have no idea how impossible that’s going to be to implement.”

Doug:  Well, we talked about having multi‑disciplinary teams. True multi‑disciplinary teams really involve the technologists as well. On these customer visits that I describe, we took care to do, we brought along coders and designers to come out into the field.

They just loved it, because then they were able to see firsthand the results of who they were coding for– the problems that were actually out in the field. We worked as a team, we really did. We had equal footing between the different disciplines, and I think that’s really important to have with all the constituencies represented.

Scott:  And I guess that probably fostered a certain amount of appreciation between the designers for how creative they could be, if it was going to be impossible to code, and the coders for, “OK, I can’t just say no to that,” because it really seemed to resonate with the client.

Doug:  Exactly right; appreciation, experience, knowledge, when you go out and you solve these things as a team. We would have our heated discussions, certainly, but what you have there is a situation that people were really promoting their constituency. I would be the one to be the voice of the customer.

Someone else would say, “Well, we’ve got to do this on the technology side.” Someone else would say, “I want it to look and feel like this on the design side.” And I think when things get out of whack is when any one of those things gets out of control and leads the whole effort.

Scott:  And how those things get arbitrated? Was there somebody who was something like a senior product manager who would take all the input and make a decision at the end of the day?

Doug:  The working relationship on the teams that I’ve been a part of has been very strong and with most things, it wasn’t that someone had to come in and arbitrate and say, “OK, we will do this.”

Most things we really did try to do as a consensus. It really wasn’t a vote. It just happened after in-depth discussion of the issues. That takes a certain level of maturity on the part of the participants who are willing to not just represent what they believe but also put themselves in the shoes of others, including the users and the people that are building it.

Sean:  Is there anything you want to add? We try to give everyone a chance to get in closing thoughts.

Doug:  I just think that this is a really interesting discussion and it’s made me think a lot more about some of the questions that you’ve been asking. I mean, what is the role of design and how does design work with technology, and to me, it’s a higher level question and answer than even the open vs. closed source model. It’s ways of working and ways of thinking about things. Thanks for the discussion. I found it very interesting.

Sean:  Thanks for chatting.

Bookmark this: