iTunes Download Del.icio.us Pod-safe music generously provided by Sonic Blue
Christina Wodtke traveled with microphone to the IA Summit in Las Vegas this year and sat down with some of the most interesting and accomplished information archictects and designers in all the land. Bill Wetherell recorded those five conversations, and now B&A is proud to bring them to you. Thanks to AOL for sponsoring these podcasts.
_*You Only See the Tip*_ In this cliffhanging podcast, Bill Wetherell wields the mic as he explores how Tom Wailes and his team at Yahoo! turned the normal design process on its head. They were successful, Wails posits, because they worked small and crafty while being inclusive in most useful ways.
If you are in a position where a new approach might reignite creativity and effectiveness in your organization, check out Tom’s thoughtful approach.
We discuss…
*Innovation at Yahoo!*
Tom talks about how his team at Yahoo! have completely reversed every day business processes to be more innovative and creative.
*KISS methodology*
Tom talks about the need to keep things simple and small; leading the process so creativity and innovation become part of the team culture.
*Being one of the cool kids*
Tom talks about the importance of involving everyone who wants to be part of such a team and how “Tiger teams” tend to intimidate preventing the whole team from realizing their potential.
*Less can be more*
Tom talks about the ice burg theory, how most of the work when creating brilliant design is unseen to the client. The best solutions are often the ones with the least amount of detail.
*Is it Bond…James Bond?”*
He goes on to describe how some parts of creating a design team involve communicating with everyone about the process; while other occasions merit a more stealth like approach around the office.
*TRANSCRIPT*
Announcer: This podcast is brought to you by AOL, now hiring designers in Silicon Valley, New York City and the Washington, D.C. area. Help us set the standard for what happens next in the Web. Send your resume to UI Jobs at AIM.com today.
[musical interlude]
Woman Announcer: Boxes and Arrows is always looking for new thinking from the brightest minds in user experience design. At the IA Summit, we sat down with Tom Wailes from Yahoo!
Bill Wetherell: Hi, this is Bill Wetherell, I’m from AOL. I’m here with Tom Wailes from Yahoo! Tom, you gave a great inspiring talk, I felt, today, and maybe you could talk to us a little bit about what innovation is like on your project at Yahoo!
Tom Wailes: What innovation is like, I think, there’s a couple of key things that we were trying to get across in that work. One of them is that we’ve completely reversed our process in order to be more creative and more innovative. We used to do piles of documentation, all the traditional stuff, requirements, documents, spent ages going through those with the team and its rating; wire frames, flows, all the usual suspects.
But it is one that is tedious for everyone, so it’s just not much fun. I think perhaps because it’s not fun, it’s not conducive to creativity either which is very important. I mean, it’s not very energizing, so people in the team are not inspired, and if you’re not having fun, you’re not energized and you’re not being as crazy for it as you could be then you’re not going to do such a good work.
So we’re still working through this, like we said in the talk, we haven’t figured out “Here is the methodology, this is how you should do it.” So again, maybe I should emphasize more in the talk I think I’d encourage people to just play with the process, try new things. Don’t be afraid to try new things, mix it up.
But I think the important thing is first, obviously start with the customers and the users and really to try and understand their needs and whether that’s through field studies or market research or, in our case, a combination of different things. From that, then go straight into ideation and, as soon as possible, start visualizing those ideas.
So that’s really the core of what we’re talking about today, visualizing ideas in different ways whether that’s through storyboards to talk about from users perspective or approach typing and simulations to really show what the product feels like. It’s only after that once you’ve figured out what the core ideas are going to be and you got a good sense of the feel of those core ideas and the experience, then if necessary, you can go into detailing out all the edge cases and things, the wire frame and the rest of it. So that very much secondary documentation for us now, the primary documentation is prototyping and storyboarding and things like that.
Bill: During your experience at Yahoo!, do you find any opponents to the process or were there any people that maybe didn’t set too all with? Are there really ruffled some feathers?
Tom: One thing I should note is that this is just what we’re doing in our team at Yahoo! And at Yahoo!, there are many, many teams and each team has a different culture, a different way of doing things. So what we’re doing is not really like probably any of the other teams at Yahoo! And they are all a bit different, so it’s just one thing to note. I think that’s one reason why we decided not to really press too hard too early to go into this big ideation phase was to minimize the chance of resistance.
It’s all that fiesta, I don’t want to have to think whether I’m going to derail these other projects, if I’m going to have to divert resources. That was a big reason why we played it that way but it’s build over time, there’s this idea that we really should do something to clarify the big vision, the overall goal that we’re shooting for. So that was just the approach we took in that situation as well as those small successes that entail very little risk. You just take in couple of resources for a day or whatever it is. So it’s a much easier sale because, what the hell, it’s just the day.
Bill: Yes, you and Kevin talked a lot about doing small things and saying small things. Can you talk a little bit about that?
Tom: Yes, again, I think that was a reaction against what we’ve seen other people try to do where you feel like if you have a big idea, like in this example, we really need to change the whole roadmap of the products. We need to really figure out what the vision of the product is which is quite a big thing. Then when you have overall of this big thing, you feel like you need some big event where there’s a big presentation in front of key stakeholders.
The problem with that is one, I think you’re more likely to encounter resistance for a variety of reasons; and two, it just ends up inhibiting you as well because it becomes this big burdens on thing that you’ve got to create. Then it’s like, “When do I find the time? Oh, my God, I’ve got to get it just right because this is my one big swing for the fences” kind of things, so all these pressure on yourself which actually makes you fearful as well. “What if I don’t do a good job of it? I’ll just look stupid or I’ll miss my opportunity.” Again, there’s internal fears and pressures and everyone could come out with the laundry list of why they can’t do something.
So yes, I think, that’s why we want it to start small and then let it become part of the team culture because a lot of these is about fostering the right culture in the team to be creative, to be comfortable with creativity and innovation. It’s not just about the design that’s doing that, it’s about everyone participating in that process and having that culture like that.
Bill: Actually on that note, since you’re talking of culture, how do you decide or do you decide who is on this sort of innovation team or is everyone involved?
Tom: What we try to do in our case was involved as many people as possible, at least in some ways. For example, the brainstorms, that was wide open. We just used tweaky pages internally. So we used those sign up sheets and just spammed everyone with email about what we’re going to do and it’s already first come, first serve. You just sign up on the page and it was open to everyone. Of course, they’re sort of who is going to be key people that would really liked to get involve so you might spend extra time hounding them to make sure they show up.
But it was important to everyone on the team to feel like they had an opportunity to be heard. I think what is not conducive to really creating the right culture is if you start having these “awesome” team and this sort of elite tiger team that’s doing all the brainstorming and figuring out all the ideas and then there’s just all the production monkeys who are putting it into action.
The thing is it was like that opening session, the Joshua with the architecture stuff, where you really need everyone to be involved in the process because everyone is going to end up owning it, every engineer and every product manager to make the final product right. Everyone is going to have to be creative in problem-solving throughout the process until the final, in our case, pixel is delivered or the final line of code. So it’s not enough to just say, “Here’s a great idea” or “You, non-idea people, you go and implement it”. They’ve got to feel ownership to that idea and they’ve got to be applying their creativity to actually implement it.
Bill: There’s definitely been–it seems like a popularization of Scrum and Agile processes like that, where if at all, do you see what you’re doing in innovation, in general, fitting into that kind of a world?
Tom: I think this is definitely been a struggle for designers and user experience people working with Scrum and Agile. I’m not an expert in Scrum and Agile but my understanding is it really evolved out of more engineering needs for building products. There’s a lot of sense or reasons to break a project up into lots of small little parts that individually work rather than you sort of work for months and months and months and it’s all suppose to come together magically once in the day before launch, kind of thing which is quite risky. So it’s a way of minimizing risk.
But it’s a problem for designers for exactly the reason that we illustrated today, in that each individual piece might make sense, but there’s in this Scrum process that it’s not very clear often where you decide what the overall vision is. There have been people who’ve talked about Scrum Zeros and things like that where you–and this what we’ve done lately–set aside some time at the beginning before you go into this Scrums of really making sure you’ve got clarity of vision.
Then you can execute even from the design point of view as well as engineering as you go through this Scrum. So I think Scrum is useful for executing but you really need to start out without that overall vision so you know where it’s going and you know what it’s going to add up to. It’s got to be more in the sum of the parts to really be compelling.
Bill: It seems like you, guys, come out with less UI at the end and more storyboards or conceptual pieces. How do you see that in comparison to other process that you used to deal with where you’d deliver wire frames and deliverables. Can you explain the difference a little bit and maybe some challenges you see between those two worlds?
Tom: It’s funny that you said the last because that iceberg metaphor that you saw that came out of–we have various user experience team meetings for broadly across Yahoo! And we are presenting some of the work that we’d done in storyboarding as a little snippet of you saw today. One of the designers who wasn’t on our team–he was on the search team–and at the end of it, he said, “I don’t really see much design work there.” I was actually pretty astonished that the designer would say that. So I went a bit Basil Fawlty and do that whole iceberg thing on the whiteboard saying, “Look, this is what you’re seeing is the iceberg but there’s a ton of stuff and every designer knows this that goes on underneath the water to get to that thing that you see above the water.
So I don’t think it’s a problem that we have less output. I think, frankly, a lot of the output that we have, traditionally–whether it’s in consulting or in-house–is propaganda. It’s propaganda for designers or information architects. What it mainly communicates, if you’ve been harsh, you saying, “I’m really clever, you’re getting a lot for your money and you know that because you don’t really understand this document very well and you certainly don’t understand very well how it was created.” So, gosh, it must be worthwhile having me around, wasn’t it?”
That’s just bullshit. So, I don’t have a problem that those, quote/unquote, “less-designed” delivered at the end.
You know, the main goal should be creating the most compelling product over experience. And, really, how you get there is incidental. And, I certainly don’t think that it’s, that Y-frames and flows are a really good place to start that. And, there’s a place for them, I think, in the process, but, certainly, not at the heart of the process. And, that’s the problem that we had, and we realized that it just wasn’t working.
It wasn’t working creatively to figure out the problems. And, it wasn’t working in terms of communicating. So, that’s why we flipped it.
Bill: How much of this process at Yahoo was stealth? Was behind the scenes, or was it all? You talked about transparency. Did everyone know this was going on, or were there cases where you had to, I guess, play it a little subtlely as opposed, just to get it done?
Tom: I think there’s a bit of both. And, we did show a couple of different examples. Like, there were, there was that Design Day example and the Field Day example that were very public. They, we weren’t hiding anything and we were actively encouraging participation. That was, the point of those things was to involve everyone else in those processes.
And, also de-mystify it saying, look. OK. You think you can’t draw for the Design Day, for example. It doesn’t matter. You find a way. The only rule for that was you had to express your idea visually. No sort of long, wordy lists describing your idea. Just show it visually. Scratch out a storyboard, or show it as some rough prototype. Do something that visually conveys the idea.
The Field Day thing was, you know, the goal was not to convert engineers and QA people, PR people into expert ethnographers. It’s not needed. Really, it was saying, look, that it’s basic. It’s not rocket science.
This is just about, let’s get out and talk to our customers. And, see them in their own environment and see things from their point-of-view. That’s it. And then, the deliverable at the end, you know, you saw a little snippet of that, was just creating a poster. So, some of them were very public.
But then, there was the other example where Kevin had a little bit of, you know, kind of, slack time in his schedule. And so, that was the case. Well, let’s just take it. Why sort of ask permission? Is it OK? Let’s just do it. It doesn’t matter. You know, let’s go off for a couple of days and, you know, who cares?
And then, if it had been a disaster, if what we had come back with was rubbish. You know, if internally, if we decided it was rubbish. Well, then we do, just [swoosh sound]…
Bill: Right.
Tom: …you know, just sweep it under the carpet and no big deal. So, I think you can mix and match.
But then, there’s also the other big point about this starting small conversations which is really to start triggering ideas in other people. So, it’s not you bellowing a message to everyone else. It’s, you’re just transmitting the message quietly. And, letting it spread and grow. And, you can start reinforcing it more as time goes on.
But, in the end, hopefully, if the idea has merit, so, it’s a good way to test your idea. If it really does start blossoming in the organization in, like in our case, we have, we stopped talking about it. We didn’t have to because everyone else was saying, when are you going to do this? We really need to do it.
And, we didn’t have to do any big, fancy presentation. Or, you know, bang the table, or anything like that. So, I think you, I think, again, experiment with different methods. And, each situation is going to be a bit different. Each company is going to be a bit different.
So, try some stealth. Try some things where you just go do something and don’t tell anyone. Try small activities which are public and do involve people. And, try small conversations. Or, you could even try a big presentation if that’s, you know, for whatever reason, you think it’s going to work. So, just mix it up. And, don’t feel like there’s one way to do things.
Bill: Great. Hey, Tom. Thank you so much for talking to us today.
Tom: OK. Thank you very much for your time.
Nice job. Very informative.
I totally agree that a lot of traditional documentation is unnecessary, but isn’t that the designers fault, and not the fault of either the process or the traditional document forms?
I’m curious if it’s the documentation that’s bullshit, or if as a culture, designers have adopted a lifestyle of intellectual laziness that lets us focus more on what we like (things that are cool) than on what we do (communicate).