Interviewers: Scott Swigart and Sean Campbell

Interviewee: Liz Danzico

In this interview we talk with Liz. In specific, we talk about:

• User experience consulting for open source versus closed source customers
• Pros and cons of working with small groups versus open communities
• Strategies for harnessing the wisdom of crowds
• Design by omission versus inclusion of features and achieving coherence with a dispersed team
• Clustering meaning: roles for both humans and computers
• Web acilitation of conversation: emulating pre-literate culture

Scott Swigart: Can you start us off with a little bit of your background, including your relationship to open source and WordPress?

Liz Danzico: All right. I am a user experience consultant, by and large, here in New York City. I do a significant amount of work with Happy Cog Studios, which is how I got involved with WordPress in the first place.

Happy Cog Studios did their redesign of WordPress 2.5 starting in 2007, which launched for that release in 2008. Then I was an independent consultant and continued to work with WordPress in a user experience capacity, doing user research and prototyping.

I have a number of other clients who I do work with in user research, information architecture, and a general user experience capacity. That’s one third of my job as a user experience consultant.

The second third of my job is that I’m chair of an MFA program in Interaction Design at the School of Visual Arts, which starts in the fall of 2009.

The final third of my job is that I do a lot of editing and writing in that general space.

Scott: What do you mean when you say “user experience?” Unpack that for us a little bit.

Liz: User experience includes every touch point that you have with a brand, whether it’s your experience with a website, a product, or a service. Your experience with every aspect of a brand is what we consider to be a user experience.

When we first started using the term “user experience,” when it was introduced in the work of people like Clement Mok in the late ’90s, we thought of it just in terms of a web experience. I think that now, we are starting to realize that the lines between products and services are kind of blurry.

That is, your experiences with digital things and physical things are blurring, and as a result, user experience is spilling outside of the digital experience into the physical experience.

Scott: When you work with a group like WordPress or others you consult for, what kinds of things are you brought in to do?

Liz: My work with WordPress is actually quite a bit different from the work I do with other people, for a number of reasons. In general, when I work with a client, there is a specific point person with whom I set up goals for an individual product or service and craft a plan that is very clear and has directives. I’m thinking about expectations, deadlines, and where and how the work is going to happen.

The same thing can happen for a project like WordPress–and it should–but one of the great problems of open source design is that the clients are as big as the products. As many users as WordPress has, that’s how many clients you have.

Of course, that doesn’t mean that the design is opened up to the millions and millions of WordPress users. At the same time, though, it sets up a different model, where ideas and concepts and iterations are opened up to the community, and feedback is broader and shallower than it would be with a typical client.

The relationship still has the same critical components, such as a leader, a problem definition, expectations, deadlines, and guidelines about where and how the work is taking place. But all of that is happening in the public sphere, like at WordCamps (which are locally organized WordPress conferences) or on the WordPress blog. That kind of feedback happens in a different place and in a different sort of timeframe than it would with a typical client.

So the tools you would use for having those conversations look a lot different than they would if I were working with The New York Times where things are happening on a much smaller scale but for an audience no less broad.

Scott: It sounds as if, when you work with a client that’s not an open source project, you interact with a much smaller group, and they make a lot more executive decisions about the direction the work takes.

On the other hand, with an open source project such as WordPress, there’s a lot more vetting the ideas and taking input from the community as the design progresses.

Talk a little bit about the pluses and minuses of each approach–working with a small team versus working with more of a community based effort.

Liz: Of course, this requires using stereotypes on both sides, since they both depend on hitting the right stride with the right people. But for the sake of discussion, let’s assume a best-case scenario on both sides:

Working with a small team in a closed scenario, assuming that you have the involvement of someone who has decision-making authority (or at least good access to the person with that authority), you can move very quickly with brainstorming and meeting the goals of the project. You also have a great sense of always knowing where you are at any given time.

If you have a strong project manager on your side, you can work against the deadlines set by that decision maker. That means you don’t need complicated tools to manage the project that can bog down the process.

Because there are very few people involved, everyone can meet together–virtually or in person–and everyone is clear about the directives that you’re trying to solve. Therefore, the product itself–which could be a physical product, a service, a combination of those, or even a brand or logo–can have a clarity of focus that is really hard to get when there are larger numbers of people involved.

That’s the key benefit of working on small teams in closed areas where there’s not a lot of sign-off that needs to happen. The drawback is that this group can be insular and isolated. If they’re truly visionary, you get the iPhone scenario, and you can get a really great result.

On the other hand, if this small group doesn’t have the right set of data or the right information at their disposal, then the drawback of is that they are misinformed. Even though they have a great lightweight process and can move very fast, if their work is predicated on the wrong information, the results can completely miss the mark.

In contrast, the open source model can have the inverse kind of problems. One of the signature problems of designing in the open is that there are often no clear leadership or problem statements. Typically, there are a lot of people with good ideas designing a lot of things, and the loudest, most visible person tends to get a lot of attention.

Understand that, by leader, I don’t mean an open source design evangelist. I am referring to someone who can actually take control over the project–or at least one idea–and move it forward. Without someone to capture those results, there is no momentum and there is no coherent trajectory.

That creates a domino effect of missed expectations, because everyone is working toward their own conception of the goal. There are no deadlines set, so there can be no momentum for all of this great work that is being done.

If deadlines aren’t set, a project misses out on one of the benefits of open source or working across EPs, which is that people can work staggered hours and in different ways, when it is suitable for them. Unless deadlines are set, no one really knows what they are working toward, which can tend to squander their effort and frustrate the contributors.

Open source projects tend to attract fantastic people, and in order to take advantage of their capabilities, it’s important that, at the beginning of the project, there needs to be a little bit of structure setting up clear parameters and a couple of leaders.

Some tools need to be set up, as well as things like a wiki, bug tracking, and processes to check code in and out. You don’t necessarily need complicated project management tools with this kind of work; lightweight ones can actually be far better.

The benefits of open source are clearly that you get a lot of feedback from people in real time, as well as the wisdom of crowds. But you need a leader to cull and edit the wisdom of these crowds, or else you’re just going to end up with a glut of information and no real sense of what to do with it.

Scott: “The wisdom of crowds” is a nice turn of phrase. In some ways, I think Shuttleworth tries to harness that with Ubuntu. Everyone once in awhile, the wisdom of the crowd washes over him, and he’s left holding his surfboard broken in half.

Still, I’ve always really admired what they’ve done with the Brainstorm site, and particularly with their latest refresh, they’ve made it even easier for users to participate.

I think user feedback is a weakness with a lot of open source projects. I’ll use OpenOffice as an example, even though there are any number of others that I could name. When we talked to them a couple of years ago, they talked about how they were very open to user requests, but I couldn’t help wondering where a mainstream user would make such a request, or even how they would know it was an option.

On the other hand, Ubuntu has built these external portals like Brainstorm that users can interact with and understand, without a lot of real work. They don’t have to think through mailing lists and IRC chats, and everything else.

How do you think those kinds of efforts feed into the types of concerns you are discussing?

Liz: I think that borrows from Digg and other models that people are familiar with, which aids in participation. It’s sort of a group editorial function, but honestly, I think there’s more needed than that. In terms of editing the wisdom of crowds, I’m really talking about a more centralized editing function with a bigger red pen.

Scott: There’s an interesting sense that some people see Shuttleworth in–sort of the keeper of the hip version of Linux that thinks about UI. He doesn’t always think about the Kernel, but yet I haven’t seen too many people ask themselves, “What more could he do?”

Liz: Remember the book “Paradox of Choice?” I interviewed Barry Schwartz once, and I recall asking him about what was needed in editorials. His perspective, at least when I interviewed him about a year ago, was that “We’re not coming up with better tools, or better search engines, or better filters for our data. We’re actually going to human editors for the work that we’re doing.”

We’re moving away from data-driven solutions and more toward human editors. I think that there’s only so much work that can be done before you have to kind of turn it over to people to make that data useful.

An actual person has to sort through and make sense of it, with an editorial perspective for people, instead of just having data just kind of represent itself over and over.

Sean Campbell: We went to Gartner in the fall, and there was a presentation on the “Evolution of Search” that included a hilarious little skit. He said, “Search is essentially a list, as if you walked up to a hole in a wall and yelled “penguins!” and a librarian on the other side held up a series of books for you to look at.

That’s the ultimate limitation of search as we know it. Google gives you pages and pages of results, but ultimately, you still need to sift through more information than you’re really equipped to handle. People are drowning in it, and for the most part, they don’t really know how to navigate through it.

Scott: I recall an interview we did with someone whose company developed a product with in-house developers and released it under open-source license. We asked him whether he could build that product without having the traditional ability to bring his teams together in meeting rooms with white boards and so forth. His answer was that he felt the product was too complex to be built by a dispersed team.

I mentioned to him that, at OSCON, in a discussion about open source usability, someone asked, “When is there going to be an open source iPhone?”

The perspective that he gave was that there’s a trade-off inherent to open source, because development tends to be very incremental, and features accrete over time. That’s great for the Linux kernel, because it adds more and more device drivers, while not really getting rid of any of the old ones, so it’ll run on very old hardware and very new hardware.

Likewise, it’s great for the Apache web server, because configuration options become available for more and more scenarios.

On the other hand, the brilliance of the iPhone doesn’t come about because of more and more added features–it’s the result of ruthless cutting. From his perspective, that’s very hard to do with open source, because the process wants to have that one more feature that’s going to be useful to two percent of the user base.

Sean: I don’t remember the person’s name, but there was a famous designer who said (to paraphrase), “I know I’m finished when I’ve removed the last thing I can remove.” That’s the opposite approach from open source, where it often seems like we’re done when we’ve added the latest 10 things.

Scott: Sean just recently got a new MacBook, and instead of having one button, it has no buttons. They decided that they would simplify the thing beyond having just one button, and make the whole thing a button.

[laughter]

What are your observations around that design notion of removing versus adding things?

Liz: I am actually a writer by background, and my first job was writing user manuals—the first for a washing machine. I have spent a lot of time and energy in both professional and academic contexts studying how to communicate ideas to an audience in the fewest possible words.

As technical writers, we approach the problem by looking at all kinds of documents–bank statements, rental agreements, and washing machine instructions. By understanding the audience’s prior knowledge and what situation they were in when they were trying to understand the information or ideas, we were able to economize on words.

That training and background predisposes me very much to the mindset that one should build a product and then think about how to take away features, rather than adding them.

My favorite example is not one of building products, but of managing customers and thinking about how to listen to them. Until around the beginning of 2007, Jason Fried of 37signals never had any customer service representatives; he answered the 125-150 customer service emails himself.

He would get questions like, “How do you manage all of those customer service emails, and how do you listen to customers? How do you know who to listen to and who not to when it comes to feature requests?” Because if you’ve ever used a product that you love or one that you hate, you’re probably at some point going to say, “You know what I wish I had is this button or this feature, and I’m going to tell them about it.”

Jason has openly admitted that he responds to emails with customer service issues, but he just deletes emails with feature requests. The philosophy is that if a feature request is popular enough, it will come up again, and if it keeps on coming up, then it’s time to start paying attention to it.

If something is popular or critical enough that it keeps coming up, that is the reason to consider not trimming it away, even if you have to regard it in kind of a stricken way.

I always thought that was pretty alert, because it’s fairly standard, especially at large companies, for there to be very elaborate customer service measures to categorize and tag and file information like that, at substantial cost.

Sean: That reminds me of someone we knew who worked at Microsoft and was gone for four weeks. When he got back, he deleted his whole inbox, under the premise that anyone who really needed to get in touch with him would send another message.

I don’t have the guts to do that, but I’m glad somebody does.

In your example, he’s trusting himself to kind of aggregate things into meaningful buckets. He’s relying on that human neural network to do stuff that computers aren’t really up for. We have interviews transcribed through a service called CastingWords, which uses Amazon Mechanical Turk.

Again, the idea is basically that they’ll chop the interview up, and people will sign on, grab a piece of work, transcribe a bit of this conversation, and post the results back. It works extremely well, compared to other transcription services we’ve used, and it doesn’t try to use software to do something that it’s not well suited to yet.

Liz: Mental clustering.

Scott: I think that to exist, we have to be able to look for patterns and aggregate information from a lot of sources and boil it down to ascertain meaning, since we can’t really process all of it. From a design standpoint, a lot of bad software tries to force you to process way too much.

For example, it may present huge lists or grids of information, trying to make the human do what the software ought to be better at, rather than leaving the higher functioning stuff for the user.

Liz: If that is the case, it comes back to needing better editors, because in general, there’s going to be a bunch of information, and clearly, we don’t yet have the tools–whether it’s Brainstorm or whatever–to provide the patience or trust to allow someone else to be the editor.

Maybe what we’re going to need is to train each person to be a better editor. We’re all going to be in charge of our own data, so we need to develop these skills to have better mental clustering and pattern recognition and so forth.

Maybe that’s one of the new skills, and we should start training people to do that kind of thing instead of relying on external tools to do it for us.

Sean: I think there’s a lot of truth to that. As language evolved, it became a vital skill to be able to communicate effectively. Looking back to the 18th and 19th centuries, that was a skill everyone aspired to.

The situation now is that creation is just as much about aggregating what’s out there and deciphering what it really means as it is actually writing up the output.

We’ve all seen the situation where some people don’t have the tools or the framework they need. If you’re web savvy, you can recognize what a screen worth of data means in a blink of an eye, and you will immediately ascertain what the next logical step is. Someone else might not find the relevant information on that screen for five minutes.

Scott: Our model for handling that information keeps changing, too. Early on, Yahoo! had the notion that humans and not machines were the key to categorizing the material on the web. They undertook the task of manually categorizing all these web pages, and then Google came along with a lot of data and a killer algorithm and just trounced them and everyone else.

Now, in order to use Google effectively, you have to know what to put in to get out what you want, and it isn’t always necessarily the most obvious keyword.

Technology leapfrogs human effort, and then people leapfrog the technology, because now they’ve got a foundation to go farther than they could go before. That takes us back to the notion of people driving things.

Liz: Alex Wright wrote a fantastic book called “Glut: Mastering Information Through the Ages.” More than one of the chapters in the book talk about oral traditions among pre-literate societies and the idea that we are now seeing a sort of return to pre-literacy and oral traditions.

The idea is that we’re writing online content as a means of having conversations, as opposed to the one-way nature of previous forms of written literature. That’s very much how things worked in the oral traditions, and Wright makes a great argument for why that is in the last chapter of that book.

Sean: That’s a great example of what we’re talking about.

We’re running short of time, so are there any closing thoughts you’d like to add?

Liz: I feel like we’re at a point of comfort with these tools, including things that have been popular for now a while like Flickr, as well as sharing tools like Basecamp, or even tracking and version-control tools.

People have become comfortable with the idea of putting data out there to be shared. That suggests that open source design, which has been controversial for a long time, might have a new chance for success.

I think the next year or two is going to bring some interesting new changes in the ways that we present design work to one another.

Sean: That seems like a good place to wrap up. Thank you for taking the time to talk today.

Liz: Thank you.

Bookmark this: