Straight From the Horse’s Mouth with Dan Brown

Written by: Dan Brown

iTunes     Download    Del.icio.us     Pod-safe music generously provided by Sonic Blue

banda_headphones_sm.gif 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.

In this bat episode, Dan Brown, “consultant”:http://www.eightshapes.com/ and “author”:http://www.communicatingdesign.com/ extraordinaire, deftly parries Tom Wailes’ repeated calls to oust the wireframes and task flows for prototyping and simulations. Our stalwart hero defends mindful subversion of the status quo as the best path in many corporate and public sector projects.

While exciting to throw out the bathwater, not every baby is fed by radical innovation alone.

Thanks to Tom for taking the voice baton after his previous turn as interviewee.

We discuss…

*Conceptual vs Design Documentation*
Ideation processes is where the team needs to think bout creativity and innovation. As designers, we create a set of artifacts to help us communicate.

*More detail required?*
Rather than using Wire Frames, Tom Wails says that his core artifacts are more detailed prototypes rather than wire framing, calling Dan’s approach to using Wire Frames into question.

*Know more than your audience*
Dan discusses the importance of knowing not only your audience but also understanding the corporate culture into which you’ll be working and designing.

*Government Work*
Dan points out a constraint to innovation from his experience is that most contracts are very specific with respect to deliverables. The challenge is creating within these set parameters. Dan provides examples of such creativity when designing Wire Frames.


*Transcript*

[musical interlude]

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 Dan Brown from EightShapes.

Tom Wailes: Hi, my name is Tom Wailes. I’m User Experience Director for Yahoo! Local and Maps. I’m going to be discussing with Dan Brown a few issues that came up today at the IA Summit.

Dan Brown: That sounds awesome. I look forward to it.

Tom: So a little bit of background. Dan gave a talk today, “Communication Design”. So something to summarize, I guess, his book what I thought about some of the design deliverables that information architects and designers who typically delivered over the years and made some very senseful suggestions for some refinement improvement to that. I gave a talk with a colleague of mine from Yahoo! Kevin Cheng that talked about different kinds of design deliverables, primarily storyboards and prototypes and simulations. So I’m here to talk with Dan about where he sees this to working together or not.

So Dan first, I kind of teased you a little bit in my talk after praising your talk. It was very good, I enjoyed it. But then, noting that you hadn’t already talked at all about prototyping or simulation, storyboarding, things like that which is what my team has been doing a lot of and we’ve been very little wireframing. So your reactions to that.

Dan: I think it strikes me as a very important part of the work that we do as designers. I didn’t sense any sort of disconnect between your story and my story. In a sense, I was speaking to all those people who have to jump on a project after a concept has been approved and funded and need to hash up the details. At the same time my, I guess, philosophy is meant to help people provide a critique of their own documentation and I wonder if there’s an interesting synergy there in looking at the kinds of conceptual documents that you do dividing it into layers as what I suggest.

So very important stuff that’s critical to the document versus the more extraneous stuff and using that as a model for evaluating conceptual documentation as much as design documentation.

Tom: So can you clarify a little bit what you mean by conceptual documentation versus design documentation?

Dan: Sure. What I got out of your talk was there’s this ideation process. There’s this process where we need to spend some time just spending some brain cells to think about what could be or let me get a better understanding what the problem is. We created a set of artifacts to either better articulate what that problem is, help get our heads around it, or, in the case that you were discussing, we’ve got this concept, we’ve got this idea to improve your product or create a new product and we need to sell it to the people who make the decisions and hold the money. That’s certainly what I got out of your talk and it’s something that I’ve had to do a lot in my career.

Why that stuff didn’t make it into the book, I would say is only because I was trying to –there’s a long list of documentation, I’d to cut it off that one of the things that people really do everyday in their jobs. And I was looking at your little video, I’m going, “God, if I could do that everyday, my job satisfaction would go –I mean, I love my job as it is, I’m self-employed, etc., etc.–but my job satisfaction would go through the roof”. So I see the conceptual stuff as sort of trying to sell and capture big ideas about a product or product direction. Whereas the design documentation, elaborating on the details and providing directions to the people who have to implement it.

Tom: So one thing I didn’t really cover today but it’s also part of our process that we’re trying, we’re experimenting and sort of making up as we go along, frankly. But it’s not just using interactive visualizations for the concept, but it’s also for the details that designs are right now, rather than doing wireframe or anything like that, we’re continuing only detail prototypes to help us work out more detailed aspects of the product, and that ends up being our core documentations.

It’s not to say we won’t go on to do some wireframes later but we’re involving the engineers right now in that so that they can start thinking about, “Oh, you wanted an interacting look like that. Let me think about it.” So using those kinds of –documents is kind of a funny word to use.

Dan: Artifacts.

Tom: Artifacts, those are our core artifacts now throughout the process, not just the ideation but as we’re working through the details. So how do you react to that?

Dan: I think that’s an amazing opportunity that you have. I remember you polled people at the beginning and ask them, for example, “Do you have a 20% role in your organization that allows you to just simply trying to innovate for one day a week?” And only a handful of people raised their hands and I think if you ask them, “Could you experiment with the kinds of documentation that you do to try and continue some of these prototyping or conceptual type of stuff throughout the life cycle of a project?” you get a similar number of hands.

I come from a world of government contracting, working with large Fortune 500 companies that are stuck in old school tradition, wireframes are, in a sense, –I know this is maybe shocking– innovation enough for them as far as a new kind of document. They’re used to sort of, I imagine, 1980’s IBM, big binders of functional requirements, the idea that we can translate those into some digital format is radical in and out of itself.

Can we get to a point that we’re all doing that kind of documentation? I would love that, in 10-years time we will be but in 10-years time you, guys, are going to be doing a whole another kind of creating another kind of artifact to capture functional requirements of behaviors and all those kinds of things. Does that answer your question?

Tom: It does, well, I think it does. So are you really saying that there are just core differences in the type of industries and the type of projects that might make it incredibly hard to break away from more traditional documentation like wireframes and flows and requirements, documents and things like that?

Dan: I’m not even in charge of industry thing, I just think it’s a corporate culture thing as far as there are some companies that are just not –one of my clients, for example, is a hospitality company. They’re not a technology company, they’re not geared towards that kind of innovation.

They grew out of this idea of selling hotel rooms to people. So that kind of culture is throughout the organization. They have technology people there, and they are fighting an uphill battle to do the kind of innovation that you are talking about. That hill is culture of 100 years of hospitality industry.

Tom Wailes: Obviously I know nothing about that company and that project, but I can imagine… You talk about hospitality and selling hotel rooms. At least me, from the outside, I can imagine a great opportunity to start with some visualization and prototyping to get across some concepts, particularly since you are talking about selling. I don’t know the details of that.

So what would stop you, what would make it very hard for you to say “You know what? I’m going try something different on this project”. What are the main inhibitors for you?

Dan: Oh, I’m not afraid to try something different. But I think, as designers, we need to be responsible… I’m no Steve Jobs, so I need to be responsible for about just exactly how much I am going to push the envelope.

The kind of conceptual stuff that you are creating is working for you and your organization and your culture and the kinds of products that you are working on. I think that there are opportunities to create those kinds of artifacts and documents in other organizations but maybe not push the envelope so much.

So, if I were to show that to someone who is so used to, in the flip side, seeing certain kinds of documents, it may not speak to them as well. They may be saying “why are you wasting my time with a comic?”

There is no controversy here. I am not trying to say that I don’t think there is a place for those things. I have not been able to cultivate a place for those things in the kinds of clients that I work on.

Tom: OK, I have two comments. The first is, in our environment, people were used to wire frames and requirements documents and things like that. We had been using those but we decided just to experiment with new methods like the comic storyboarding. The reaction actually wasn’t “I don’t understand that or I don’t get that or don’t want that”. It was like “oh my gosh, can you do more of this? I can see much more clearly what the core ideas are. I can be involved in giving my opinions now”. The wireframes and other kinds of documentation are much harder to be involved in. So that would be one comment.

The second comment is we talked about starting small. In what ways could you perhaps start small? I can understand you cannot just turn your client overnight into completely new processes. You have deadlines, budgets, and things like that. But in what ways do you think you could start small in introducing new ways of working?

Dan: There are things we do all the time. That culture may have given rise to a certain kind of wireframe, and I may see opportunities to encourage them to go in a different direction.

They may start with a conventional site map, and I might move them more to a conceptual model that includes things beyond web pages. It encourages them to think about maybe incorporating their users into that picture so they have a better sense of that. So I think there are definitely small opportunities. I believe we take advantage of them as much as possible.

The other constraint I wanted to point out was that, as an outie, as someone who is not inside an organization… I mean, to a certain extent, you serve clients inside your organization. But as a complete outie, my contracts are structured to do something very specific for a particular client.

So, if they hired me to help improve a set of pages or a particular function on their site and I said “OK I’ll do that but let me show you this first” they would really not happy with that because they are paying me to achieve something very particular.

I am working within the constraint of that particular project scope I need to find a way to do that things you are talking about and sell them on big ideas. The book, Communicating Design, talks about using documentation and use it in different contexts and those contexts, as the contexts vary, they will impact the nature of the documentation itself, as well. I don’t know if I answered your question.

Tom: I think you did. I’m still not entirely convinced that you can’t introduce new ways of working in a very small way where maybe you do not take any of the client’s time or maybe you only take a day. We gave some example today. I can show you some stuff later that just took two days to visualize some ideas.

So it might be something that is very lightweight and you are not beating the client of the head with it and saying “oh my god we’ve got to work this way”. It’s just like “yeah we are going to do all the things we are contractually committed to doing but, by the way, why don’t you have a look at this as well”.

Dan: I am not disagreeing with you at all. I completely think there are opportunities to do that, but my primary concern (I may get in trouble by saying this) is less about doing cool work period and more about doing cool work within the constraints that have been handed to me.

So I do want to push that envelope as much as possible but my primary concern, as a consultant, is customer service. Ultimately I can feed the kid by getting hired again. So I will do a little thing. I will show them a different kind of document. I will take their wireframes to the next level or I will show them how they can incorporate all of their flows. Who knows what it is.

I might produce a comic. We have done a couple of projects where we have done comic-like things that incorporated user commentary and very explicit screens or wireframes along with some more technical contexts. Not a comic in the true sense of the word, but something leaning in that direction. Those can be very helpful, especially when clients themselves are struggling with the scope.

That was a long rambling answer to say I agree with you.

Tom: OK, let me challenge you a little bit then. What if I was to put it to you that you would actually do better work and serve your clients better if you did less wireframing or other traditional kinds of documentation, and more prototyping, simulations and storyboarding?

Dan: I think you are right. So ha! So try and challenge that! [laughter]

I agree that there is an opportunity to do more prototyping and stuff like that. It is balancing that with the expectation of what we are going to get and what is going to work inside the organization.

In some cases, we are shielded from the development team entirely. So I am working to support to user experience team, and they are burdened with communicating with the developers. If I am going to ask them to challenge their developers, that is not very responsible on my part.

Tom: OK, thanks very much. So we sort of agree, and disagree, and agree again.

Thank you so much for your time.

Dan: I look forward to our next conversation.

Tom: Me, too.

Straight From the Horse’s Mouth with Tom Wailes

Written by: Christina Wodtke

iTunes     Download    Del.icio.us     Pod-safe music generously provided by Sonic Blue

banda_headphones_sm.gif 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.

Straight From the Horse’s Mouth with Derek Featherstone

Written by: Christina Wodtke

iTunes     Download    Del.icio.us     Pod-safe music generously provided by Sonic Blue

banda_headphones_sm.gif 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.

Christina talks with web accessibility and design expert Derek Featherstone about considering accessibility as a foundational part of the design process. By doing so, he argues, the software we build will have better structure and be inherently more useful for everyone who uses it.

This interview is a must listen if you want to learn about this emergent part of our practice that started as a grassroots movement in developer communities.

We discuss…

*What do IA and Accessbility have in common?*
Derek looks at the bigger picture when it comes to accessibility, believing that focusing on accessibility by itself will cause the web design to fall short in other important areas.

*Fashionably late?*
Derek goes on to outline the problems of brining accessibility issues to the table late in the design process, including impact on project scope. As Derek points out, better to measure not once, but three of four times before cutting…metaphorically speaking.

*Easy does it!*
Derek talks about specific examples of issues that have arisen when sites for the Canadian Federal Government have been found to be inaccessible and the consequences that follow.

*Heart and Soul*
Derek talks about the value in this work is knowing simply that he’s helping people with disabilities share in the same experiences as everyone else. “I don’t think I could even make an inaccessible web site, now!”

*Structure is at the Core*
He describes how structure (following HTML web standards) allows assistive devices to know what the page is communicating.

*Interaction Design and Accessibility*
Derek suggests trying to think about accessibility from an Interactive perspective. Using things like flow, and rhythm to convey meaning in something we read for those who can’t see.

*Flash in the pan?*
Derek thinks there are great Flash sites and use of the product. In fact Flash has a wealth of accessibility features at the developer’s disposal. The message is just not getting out there fast enough.


Straight From the Horses Mouth with Derek Featherstone.

Automated Voice: This broadcast 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 on the web.

Send your resume to uijobs@aim.com today.

[Theme music]

Female Voice: Boxes and Arrows is always looking for new thinking from the brightest minds and user experience design. At the IA Summit, we sat down with Derek Featherstone from Further Ahead.

Christina Wodtke: I’m Christina Wodtke of Boxes and Arrows and I’m sitting here talking with Derek Featherstone. I don’t even know the name of your company.

Derek Featherstone: My Company is called Further Ahead.

Christina: Further Ahead, I like that very much. So, Derek you are here talking to folks about accessibility and from what I hear, your workshop was fairly well-attended, pretty crowded in there. So tell me, what is it about IA and accessibility? I wouldn’t have guessed they have a lot to do with each other.

Derek: I think, for me, the way I see it is that they are both related because they’re both part of overall user experience.

A lot of people look at accessibility as this little thing that’s on its own but if you do accessibility on its own and treat it as its own component, it becomes like a second class citizen and so it’s not integrated into everything else that we’re doing.

And when you treat it as something that’s just kind of like the checklist training – that’s what everybody thinks of when they think accessibility is this checklist of things that we need to do.

It really becomes something that is removed from the overall design process and the build process, and understanding it as part of user experience on how people, actually, use the web.

Christina: What are some of the bad consequences of having it outside of the design process?

Derek: Well, I think the biggest problem that I’ve seen is that it just gets addressed too late in the process.

So I’ll have clients sometimes come to me two weeks before they are ready to launch a site and they know it needs to be accessible and then I’ll go through and I’ll do an assessment of it, will do user testing with it and will go back and say: “There’s a lot of things that need to be fixed, let’s make this happen.” It’s like they can’t go live or it goes live with a lot of accessibility issues in it.

So that’s, sort of, the most significant problem – is that it gets dealt with too late and then it cost money because you have to go back and retrofit.

Retrofitting a site is never fun and it can be a lengthy process especially depending on how far along you are and how complicated your framework is, what you’re doing on the back end in terms of code.

You might not be able to change things as easily as if you’d dealt with it up front and how accessibility is taken into account at the prototype stage.

So that’s the number one issue, I think – is that it just — it becomes an afterthought and then it’s seen as this button that you just end up with an inaccessible product because of it.

Christina: So it’s an old adage of measured twice and cut once?

Derek: Or measured three or four time and cut once.

Christina: OK. So what happens to those sites where accessibility problems go live? What happens when you aren’t as careful as you should be?

Derek: I mean, depending on who you are, you are kind of hope and pray that you don’t run into any issues where people — you know in Canada, for example, we have sites that may have accessibility problems that are federal government sites and people will launch actions.

They’ll bring that to, say, Canadian Human Rights Commission and they will say: “There’s this service that’s offered online that I can’t access because it’s fundamentally inaccessible. There is all these issues with it.”

So that works its way up the food chain through a process to get resolved. So that’s certainly one of the dangers in Canada.

You know, here in the states, it’s a little bit different although very similar as the Human Rights Commission, but ultimately Section 508 here in the states is there to guarantee or at least provide for a minimum of accessibility.

I’m not sure if people launch complaints with the governments or if it’s more dealt within a civil manner as we see all kinds of suits these days against companies in Texas and the National Federation of Blind launching their suit against Target.

I think the one in Texas was Oracle – all this legislation exists and if you’re not accessible then you’re, kind of, get caught with your past though.

Christina: So lawsuits and government action is at stake. Is there a carrot as well to encourage people to think about accessibility?

I’ve heard some people talk about, like, good code and good accessibility, meaning good search engine results; can you give us some advantages?

Derek: Yeah, I mean, that certainly is one of the advantages. There is a danger though in that being the motivation for it.

I think that biggest carrot is that we are doing this to help people with disabilities use the web. I see the web as, and I think a lot of people see the web, as great tool to level the playing field.

Having the ability to be somebody that’s, say, blind or is, say, confined to a wheelchair, they have the ability to shop online just like anybody else can.

It is an attempt or hopefully a mechanism to get that level of playing field and unfortunately that’s not reality. So the biggest carrot for me is knowing that people with disabilities can actually use the web the way it was intended to be used.

And I know that one of the things that I’ve always done that’s worked really well is for people that don’t necessarily know about accessibility or don’t know some of the advantages of it, just doing user testing with them or having them observe user testing some of the frustrations of using even their own websites.

Getting business owners and people that are driving groups – the owners of the websites to see it for themselves and to hear it for themselves really makes a big difference.

So that’s the carrot that I like to use although there are definitely benefits from a search engine optimization perspective. The foundation of accessibility, really, is that structured semantic underlying data and that’s the same for search engine optimization, so the two of those fit really nicely together.

You know, there are other things too like lightweight pages make it easier to download, things like that. So those are all these extra side benefits that may help people that want to browse on a mobile device. But I don’t see those as being, certainly — those might be like 10 karat and people with disabilities are like a 24 karat.

Christina: 24-karat carrot.

Derek: Yeah, exactly.

Christina: I like that. So well, luckily, you have all those carrots because I have noticed the business are not always altruistic as we might want them to be.

Derek: Yeah, it’s true. I mean, it is something where — I’m fortunate in that all the clients that I have and that I worked with, I never really had anybody that I’ve had to sell it to them and used those other carrots and especially when I’m developing sites and building sites.

This is just the way we do it now. I don’t think I could even make an inaccessible website. I mean, this is the way that we build sites now and that’s just how it is. There’s nothing to, really, sell in a lot of ways.

Christina: So you mentioned that you have more work than you can, actually, possibly do right now and that you’ve been doing this for awhile, do you think that there’s an increased awareness of the value of accessibility? Do you think more people are worried about it or caring about it in the past?

Derek: Yeah, I think some of the visibility or some of these lawsuits is having an impact. I think there is more awareness of it in general and I think a lot of people – there’s, kind of, a web standards’ movement among developers that just keeps growing.

So there’s a group of people that are just out there, that are just doing this because it’s the right way to do things.

So I think that it’s kind of a — is this grassroots movement that is helping to spread that vision of accessibility into organizations all over the place. So I think people are definitely more aware of it these days.

Christina: Earlier you mentioned the lightweight pages, are there some other core precepts of accessibility that you could share?

Derek: I think, well, I mean, the absolute based one is structure – having that structure that enables assistive devices to understand a little bit more about what the page actually is.

Christina: What do you mean by structure?

Derek: Just structuring your page so that you have —

Christina: The HTML? The —

Derek: Yeah. Yes, so using the right HTML for the job. So having headings, lists, block quotes – using the age-old sins of HTML was we to indent our texts so we’re going to wrap it all in a block quote or maybe two or three block quotes to bring both the margins. We just don’t do that anymore because block quote actually has meaning and there is a certain semantic to it.

A screen reader will announce that a block quote is a quote.

So if we have three-nested block quotes together to indent something on a page, it just doesn’t make any sense and that’s extra noise for a screen reader.

So, I mean, that’s just one example, we want to make sure that we’re using the tools that even though HTML is an overly semantic latent rich language, we want to use what we do have to its best.

So using lists properly on other lists and ordered lists, using tables properly, using headings, block quotes, all these different elements that we have for the right reasons.

Christina: So are there other ways to make pages a little more accessible?

Derek: Yeah, I think one of the things that I’ve been pushing a lot of people to do or to at least consider is to think of it from an interaction perspective.

One of them is — one of the ways to do that is looking at the visual languages that we create with our designs. We use color and we use actinography and we use things like rhythm and flow and similarity and size, similarity and color.

We use all that visual display to convey meaning to people that can see.

So how can we take that and translate that into something that is useful for our screen readers? So if we’re talking about things being the same size and having the same, sort of, weight then we should do that same thing in the underlying HTML.

So just taking that extra step to think about what you are trying to visually communicate and thinking about ways to communicate that in other ways to people that may not be able to see.

Another example is, you know, we might have sections of a page where we’ll have primary navigation across the top and secondary navigation down the side. We can visually see that based on the position on the page, these lengths are different from those links.

So there are other ways to try and convey that.

You might include, say, before your secondary navigation, you might include a hidden heading that says: “In the section” so that you can distinguish from the primary navigation links from the secondary just so that it makes it a little bit more clear as to what all these different components are.

So that taking that visual to translating into something that’s meaningful in some other way to somebody that’s consuming a page through auditory means.

Christina: So with the penetration of broadband to a much wider audience, we are seeing a lot more use of Flash and Ajax and streaming video, what, sort of, opportunities or challenges are you seeing these days?

Derek: It’s interesting because there’s a lot of belief that, well, because we now have this broadband penetration we can do whatever we want.

One of the main issues that I’ve seen with that is the use of Flash – I think that Flash is great, I think it’s got some really — some great uses on the web, but one of the things that happens is Flash developers don’t necessarily know all the accessibility features that are built in the Flash.

It’s not really well know, but Flash has, in some ways, better accessibility support than technologies like using things like Ajax.

Christina: Wow.

Derek: And that’s been there for some time.

I mean, Macromedia and now Adobe with Flash. They have been putting a lot of time and effort into making that accessible and that’s — they’ve got — right now, at this point, they’ve got better programmatic control over talking to, say, screen readers and through that accessibility architecture that’s built into your operating systems.

There is better support there for things that — for reaching that applications than there are in Ajax right now.

So that’s one of the big things – is with the proliferation of Flash, people don’t even necessarily know that it can be made accessible. The old story was, well, it’s Flash, so it can’t be accessible, but that’s not true. There’s a lot of things in Flash that can be made accessible and the principles are pretty similar to what we have in HTML.

You need to enable keyboard access, so all your buttons that you have in a Flash will lead to, say, save it with your online video, like things that YouTube or Google video or wherever.

All your buttons that you used to control, they need to have the ability to take the keyboard focused, so that you can tab through them.

So you need to label them so that they just don’t get announced as “button” by a screen reader because button, if you have five things that are all announced as “button”, it’s not clear what it is.

Christina: “Button, button, who’s got the button?”

Derek: Exactly. Exactly. So that’s a big challenge right – is encouraging other people. There are some really brilliant people working on Flash accessibility but it’s just not proliferating. We need to continue to get that word out that you can make Flash accessible.

Christina: Well, you know, Ajax is the flavor of the week and flick or flip completely out from Flash to Ajax and we’re seeing a lot of other new Web 2.0 items in Ajax.

What should people be thinking about is as you sit down to knock out the next most amazing project ever?

Derek: That’s a good question. I mean, in terms of accessibility – I know I have said this a lot now, but the underlying structure is almost everything. That gives you your framework.

So having good, solid HTML which most people that are building new applications are these days, really, what they need to do to take it to that next level is think of the interaction and think of that Ajax component as that final enhancement rather than the first enhancement.

A lot of people think about it – they start creating a new application and the very first thing they do is say: “OK, this is going to be Ajax-driven.” If we can avoid people thinking that way, let’s think of the core structure first, what are we actually trying to do in terms of our interaction?

Then how do we enhance what we’ve already got with Ajax?

Christina: Now, that does sound like information architecture and interaction design to me very much.

Derek: Exactly and the biggest thing that people don’t ask is should we even be using Ajax for this in the first place? And that question just doesn’t get asked enough. There are lots of examples out there where there’s really —

Christina: You mean [indecipherable] names?

Derek: No, I’m not even thinking of any applications in particular but there are situations where the assumption has been we need Ajax to do this but all these things that are happening in this Web 2.0-sphere that are all around tagging at social interaction and social networking, we don’t need Ajax for any of that.

Those ideas are really just concepts; it’s nothing to do with the technology.

We can use Ajax to make those concepts come to fruition in a much more usable manner and in some ways it’s almost more accessible to use some Ajax-type techniques because the fact that the page doesn’t refresh means we don’t lose all that context and have to wait for that page to reload.

So it’s quite possible that using Ajax to expand the nodes of a tree in a file view, for example, might actually be more accessible because it’s easier to maintain contexts; people don’t have to go through that refresh.

So there’s a lot of interesting things to think about that. We’ve only really just started exploring.

Christina: OK. So let’s say, you know, I am that little company and I will say I’ve built it, I didn’t think about accessibility, what should I be looking for just to see if I’m going to be in deep trouble with the law? Is there any quick way I can go through and see if I’ve got big trouble or little trouble?

Derek: I mean there are online checkers that can do a quick and dirty analysis for you.

The biggest problem with it right now is that a lot of accessibility even though there is a checklist to reliably and mechanically checks for those things in automated way, you can maybe hit 25% to 30% of the issues. So you do need to do a bit of a manual review.

One of the things that you can do though, and I do this all the time, is go out to the local college or university and get people from the center for students with disabilities and just get them to — you know, they’ll be more than happy, usually to volunteer to test things out for you.

Christina: After users?

Derek: Yeah, I know it’s crazy, isn’t it? Unbelievable. I mean, who would have thought?

Christina: You’re a radical thinker.

Derek: I know. I know it’s crazy. It’s crazy.

Christina: Well, this is fantastic. Thank you so much, Derek, any last words to the folks thinking about accessibility out there?

Derek: You know, the main thing is just keep thinking about it because that’s what we need – is we need more people thinking about it all the time.

Christina: Make good code and think about your users out there.

Derek: Exactly.

Christina: Sounds good no matter what you’re working in.

Derek: Absolutely.

Christina: Thanks, Derek.

Derek: Thank you.

[Theme music]

Straight from the Horse’s Mouth with Livia Labate and Austin Govella

Written by: Christina Wodtke

iTunes     Download    Del.icio.us     Pod-safe music generously provided by Sonic Blue

banda_headphones_sm.gif 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.

Christina talks with Livia Labate and Austin Govella about the UX practice in Comcast and how they have created an environment where they are treated as colleagues rather than a service organization.

We discuss…

*Big IA vs. Little IA*
Livia describes “Little IA” as the bottom-up approach to projects looking at the structure and organization of content. While “Big IA” is about acquiring user and business needs and then converging these, taking content and structure into account.

*Defining the damn thing*
Does the role define the person or does the person define the role? Austin believes that job titles are not relevant any more. What matters is learning from other professionals to improve upon a product or create a new solution to an old problem.

*Ying Yang*
The need for “specialization” and the need for “collaboration” in business is a big challenge. These two important yet distinct elements are rarely looked at in harmony.

*What is IA all about…besides “herding cats?”*
Livia defines this process through their mission statement: “Balancing user needs and business goals to create a framework in creating positive user experience”. This helps them define the boundaries of Information Architecture.

*Looking through the Looking Glass*
Austin suggests reading business publications thereby changing the words you use to sell ideas to different members of the corporation. Dress code also impacts the kinds of conversations you have with the client. Know who you are presenting too, and dress the part.

*Describing Value*
Austin discusses the importance of talking to business leaders about design choices in their own language. For example, “this move will decrease our acquisition rate”…”decrease our ability to convert people”…”decrease our referrals.” In essence, know your audience and speak their language.

*Secrets to Success*
Christina sums up this conversation beautifully, “…learn the language, lose the agenda, be a resource, and dress better!”




*TRANSCRIPT*

Announcer: This podcast is brought to you by AOL, now hiring designers in Silicon Valley, New York City and the Washington DC 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]

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 Livia Labate and Austin Govella from Comcast.

Christina Wodtke: Hi, I’m Christina Wodtke of Boxes and Arrows and we’re here talking to Livia Labate and Austin Govella of Comcast. We’ve been having some really interesting conversations here at the Summit about the importance of business to information architects and vice versa. So Austin’s is going to be giving a talk about that and so we thought we’d grab a couple of minutes with them and hear what they have to say. So Austin, what inspired your talk? Did it come from work?

Austin Govella: Yes, it came from work and it came from–like all the discussions we have, people have about big IA and now it’s inaccessible and, I think, they can’t do it or they’re not supposed to do it. I remember some of my experiences [indecipherable] the little IA that became big IA and I came on the idea that big IA is a way you work not the things that you do per se.

Christina: OK, some of our folks at Boxes and Arrows actually aren’t information architects and that’s a little bit shocking. So actually, Liv, can you explain the big IA, little IA definitions and how you see them at Comcast?

Livia: So generally, the way that I interpret that is little IA is really the bottom of looking at the content and building structure from it, so understanding and thinking about the more granular aspects of information and growing the structure and the hierarchies and things like that from that. The top-down big IA type of work is more looking from getting insights from user needs and the business needs and converging those things and then taking the rural aspects like content and other things into account but just from a different angle. I think it’s not a matter of one or the other, you actually have to work in both levels, and that’s something that we try to do. But it’s not like we have a formal way to do that.

But something that’s interesting in terms of business in IA is that often, I’ll get to the discussion of process, so thinking about “Who does little IA, who does big IA?” and how does that jibe with everyone else’s work? To us really what matters is servicing the business and so providing a service to the business and so the process needs to support that. So in many ways, we’re seen as top-down because we’re thinking about the goal aspects of the business and working with that to the more granular aspects of what we need to do.

Christina: A lot of people have said that the concept of big IA is really the job of a product manager or it’s something that they call user experience or UX. Your talk is to bring back big IA or at least defend it. Can you talk a little bit more about how it’s unique and why it’s important to Comcast or business, in general?

Austin: I don’t think it’s unique and I normally think necessarily it’s more important than other things so I think it is important. Even if you’re just doing a wireframe, something for just one screen or one product that maybe you’ve think only one user or need is something that’s to be driven by the business goals.

And that thinking from the goal of perspective like that, makes that one wireframe is sort of just being this one piece that isn’t in the [indecipherable] somewhere catapults that into something that’s part of the business’s conversation as a whole. And to me, that’s the kind of work that people should be doing regardless, like your work shouldn’t be just this one that doesn’t have any legs that should feed the business’s organism. So that’s the [indecipherable] I take.

Now, I don’t think it’s more important or less important than the business, but I do know like at Comcast, a lot of time people would tell me I’ll ask you a question or make a suggestion and I’ll say that’s not what IA does and I think that’s really humorous because that’s part of what I’ve been doing for years. I think it more matter that it doesn’t really belong to a specific job title. People just get together in a room and you do the work that needs to be done.

Christina: Do you think some people are a little too hung up on roles? I hear you say that’s not what IA does but you’ve been doing it for years. Does the person define the role? Does the role define the person? Because you do it does that make it IA? How do you see that relationship fitting together?

Austin: That’s a good question Christina and I’ve done a lot of thinking about this. [laughter] To me, in the new millennium, the concept of job titles and roles as silos is pretty much irrelevant. Everything is networked, everything is collaborative; everything feeds everything else.

So a lot of disciplines, they like to focus on one aspect of the entire experience. And that’s good because you need a specialist. But there are emerging disciplines or disciplines that have emerged, that bridge, that have lots of overlap like IA, like business analysis and architecture. And the overlap occurs not because they own those areas or that they own anything unique. They don’t even own the overlap but their focus is keeping all the small pieces aligned with the whole.

Now in an optimum organization, my opinion is, that you wouldn’t need IA, or an architect or business analyst because everybody on the ground would be going in the same direction but it’s like herding cats. So you need people to help you herd the cats.

Christina: So Livia, you’re a hiring manager. How does this philosophy jibe with your every day day-to-day experience, trying to get stuff done?

Livia: I think there is a very significant disconnect when we talk about those aspects of what is informational criteria, where does it fit and how does it jibe with the business. The need for a specialization and the need for collaboration are two different things. It’s collaboration of work and specialization of function. I think there is great value in specialization of function.

So I think yes! You do need an IA specialization. You need usability; you need business analysis. But the collaboration is a completely different level. The problem is that when we talk in terms of job titles, we’re not making any of those distinctions so you can interpret it in one way or another. So it becomes very convoluted to have a discussion about who is supposed to do what.

But we really should be having that discussion but it’s a discussion about process. Within the process you define roles and responsibilities but that does not at all eliminate the fact that you need to have dedicated functions. That should just exist. That should be part of the infrastructure. However, you are working your process or how rules are defined within the context of a product development process a maintenance process that is very contextual.

So it might be at one point in a particular project, the IA has a more overarching, organizing role like orchestrating what is happening. In a different context and in a different project, they have a more specific role that’s like figuring out taxonomies and categorization systems. And that is really the boundaries of the role.

So I think it’s important to have the function to indicate what is potentially offered by a function and but in the context of the project, a discussion about how the collaboration is going to work.

Christina: So I hear you say, “the business, ” a lot–“the business”–as if it was a very separate entity from Comcast or what you’re doing. How do you see the relationship of the business to your life as a Comcast employee, as your life as an IA at Comcast? How do you make that relationship with what do you say, satisfying the business or meeting that business’ needs? I think that’s the topic of your talk as well more or less.

Austin: I’ll let Livia take this first. [laughter]

Livia: I had it really good inside, during the Summit, with talking to some people because we always refer to what we do as a service to the business. After talking to people they’re like, “Why do you frame it this way? That might be the reason you’re so distant from the business.” And if you consider yourself just another business instead of the service organization that is servicing all these other business units, you’ll become an entity at the same level as them.

You may be doing the exact same kind of work, but just framing it differently might be a way to be closer to the business. So when I say, “the business, ” I mean the organization so I should probably be saying the organization and not the business. But, that’s something that…

Christina: So, it’s less than business people, it’s more Comcast, in general.

Livia: Yeah. So, when, so, we should really make the distinction of the organization and business units which are the people who are generating the initiatives that we’re working on.

Christina: OK. Do you have something further to say, roofing off of that?

Austin: Well, no, I think that’s important. And, that was one thing that, like, Adam, Adam Greenfeld complained once to me that every, all of the IA stuff is all about business. And, that makes some sense because that’s where the money is.

So, people want to kind of be close to the business talk. But, a lot of times we really do mean the organization. And that, and, if we, if we do frame it, if we were just more careful about how we framed it, then, then I think that opens, it continues to open more doors and also helps get us into other, like, other channels because it’s not just a business where you’re doing web stuff. You’re servicing organizations with experience.

Christina: So if I, it isn’t about business, then what else is it about?

Austin: Herding cats.

Christina: I think that’s project management.

Livia: So, one way, the way that we decided how do we address, how do answer that question for ourselves, and the reason why I wanted to do that is because if we don’t know what our team is about, how are we going to really be providing a good service?

So, the way that we define it, is we have a mission statement that says, we’re the field that balance user needs and business goals to create a framework to enable positive experiences. So, that mission statement defines what we do. And, we do information architecture and usability, but to us it’s a really good way to kind of define the boundaries of the responsibilities of information architecture.

Christina: So, you know, it’s always interesting to me when I hear people talk about we represent the user or we hold the user goals because I don’t know if you’re familiar with George Bull’s research but he shows that the company’s that are the single most effective are the ones in which every single person in the company are responsible for the company’s goals. So, how do you define your role in the company because you’re nodding, you know, you’ve seen this stuff, and you clearly believe it’s true. So, how do you, how do you balance both your direct responsibility to the user with the knowledge that that’s something that needs to belong to the entire organization?

Livia: So, one thing is that I explicitly ask the team not to portray ourselves as user advocates. We are user advocates. But, when we do that people have an expectation that they don’t have the responsibility So, yeah, just go to the IA’s guy, they know the users. And, that means that they are making all those, their decisions in the complete vacuum and they are not addressing those needs.

So, one thing that, I wanted to create some kind of mean that would kind of perhaps permeate the groups and kind of have the responsibility to the users in everyone’s hands. So, and I always go back to something that I heard from you Christina, which is you had those me-men, yahoo, which was every pixel has a job to make. And, I thought that was really good because in, regardless of the context, it was a good way to just kind of have that message out there.

And, we had a really big struggle internally about what is user experience in terms of which team should be called user experience. And, the developers wanted it. We wanted it. And, so, eventually, I said, OK, we’re information architecturing because really that’s what we do, but, user experience is everyone’s responsibility.

So, that became kind of the mean – user experience is everyone’s responsibility. And, I don’t know how far that has been dissipated. But, that’s something I’m trying to always bring up. And, some people have actually come back to me and said, Oh, I understand what you mean by that. But, how can I actually do something about it?

So, that allowed us to bridge some connections that we didn’t have, and say, here’s how we can help you. And, that role of user advocates, now, we can give something to them and they can be user advocates. So, it’s a work in progress. But, I’m pretty happy about where we’re going with that.

Christina: Leads can be pretty powerful, I must agree. So, to return to the sort of the concept of servicing business, how do you, how do you, what are some of the ways that you understand business and the businesses needs of the, the business needs of the organization, to use Lydia’s clarification. How do understand the business needs of the organization?

And, also, how do you help the business understand what you can bring to the table? I know that there a lot of young IA’s out there going, you know, they never talk to me. They bring me in too late, you know? How do you, how do you help them understand how you can help them?

Austin: Well, I think in terms of, like, specific skills, some things that I do that I’ve just picked up over the years of my experience is I read the business publications. Not so much so I know what all of the business people are reading. But, it changes the way you talk. You talk about things differently.

Another thing I do is just simple as dress code. If you walk into a room in T-shirt and jeans and you look designery, then, you’re the designer. And, you do, you do visual stuff, or you’re the user advocate, or whatever. But, if you walk in, walk in the room, you look like a business person, then, you’re having a business discussion because they automatically accept you in, and you’re having a different type of conversation. You’re talking about what the business model is. Or, what their goals are. Or, what type of, you know, market they’re trying to get into.

And, that’s the type of information that really helps you innovate good products and solutions. Like, knowing if they want a blue button does you no good.

Christina: Well, I’ve got to admit that looking at you two guys, I can easily picture you pitching the V.C. down in Palo Alto. You definitely are dressing the part. And, just for the folks at home that can’t see. So, you’ve got that sort of visual, business-casual thing down.

But, so to go back to it a little bit, that’s how you speak to them. How do you represent the value that you’re bringing, in particular. You can now put it into their language.

What sort of things do you talk about?

Austin: I’ll use an example because I’m trying to think, I’ll try to think of how to do this. We were discussing the header and someone wanted to put, do a link in the header back to the home page versus back to the sub-section page. So, it’s a very simple, they probably have this conversation in lots of places.

The response that I used wasn’t, you know, the users won’t like this, or blah, blah, blah. It was this will decrease our acquisition rate. It’ll decrease our ability to convert people. We’ll stop getting referrals from people. So, I couched, I couched the design solution in the business vocabulary because design solutions really are business solutions, right?

We talk about colors and experience, but those are fuzzy, abstract things. And, in my experience, couching it using the business terms has been, you’re just using different words. You’re still saying the same things, but they understand it better. They understand that if you, the link doesn’t work the way the user expects, that the business impact that you’ll have, you’ll have less advertising revenue, less traffic. The things that they can grasp.

Christina: OK. So, you’re saying, basically, that you become, in a lot of ways, the resource that they can turn to who knows about how design will affect their job and their life, and you speak to them in those terms. Because if you’re, you don’t own the user experience, but you can speak to an aspect of the user experience where you have a deep body of knowledge. And, you can speak to that in their language. Is that sort of?

Austin: Yeah. I wouldn’t have put it that way. Yeah. That’s probably, exactly what, I think that’s what I try to be is the, a resource…

Christina: Yeah.

Rather than, even more than just the service provider, just, like, a resource that can offer insight and…

Livia: And, that also, the way to do that was something that I struggled with for a long time because if, depending on how you frame it, if you talk, I noticed that whenever I talked about design, people lost interest. So, I stopped talking about design. And then, I started defining the types of things that we have to offer in different terms.

So, the way that we have, and there, we have our mission statement. And, we have like this dot Venn diagram that says, Discovery, Modeling and Validation. So, those are the three strengths that we bring to the team. And, within these three strengths, we have specific types of activities that we can do, like, Discovery and User Research, or Usability Assessments, you know, Task Analysis. Anything that, you know, tools of the design trade that we’re just framing as here’s, are the tools that we have to offer you, and these are the results that you can get out of it.

So, just framing in that way was very, also very helpful in getting people to understand what we do and understand how we can help them. So, they can, you know, it actually generates business for us because now they can come to us and they know what we do and what to expect.

Austin: And, I want to add something. One of the things that, sometimes, I’ll throw emails to Livia that, so that she can look at them and make sure that, you know, I know that I’m communicating, you know, the way I want to be communicating. One thing that she suggested was, not the exact words, but, just lose the agenda. Like, when they ask a question, just answer the question.

And, I think that when we talk about design to business people, we’re carrying our agenda with us. We care about design. We care about that language and that viewpoint, but they don’t care. They have a specific business question and when you answer their question then that’s, you’re solving the problem.

Christina: Great. So, learn the language. Lose the agenda. Be a resource. And, dress better. Secrets to success. Fantastic. Thank you, guys.

Livia: Thank you.

Christina: This was terrific.

Long Live the User (Persona): Talking with Steve Mulder

Written by: Liz Danzico
“Whether you’re designing tax forms, toasters, or retirement accounts, taking time to describe who your users are and what they need can always be helpful for creating a product that will best serve them.”

You’ve tried it all. User personas as posters, ala Alan Cooper, hanging on the office walls. User personas as cardboard cutouts, sitting at the conference table with you and your client. User personas as glossy deliverables. As paper mâché projects. As collages, comics, mood boards, Word documents, lists, charts, and just regular conversations.

Through all your attempts to bring user personas into your project, one thing remains consistent: user personas are hard to get right. And even if you get them right, they’re even more difficult to integrate into your day-to-day process.

Steve Mulder, user persona aficionado, has some suggestions. A whole book of them, in fact. That’s why Boxes and Arrows needed to interview him after getting a preview of his new book, The User is Always Right, late last year. Steve’s been kind enough to talk with us and to provide us with a free sample chapter below.

Liz Danzico: Congratulations on your book. What is The User Is Always Right, and, well, is it true?

Steve Mulder: This book was born out of the sinking feeling that, despite all the constant preaching about knowing your users, too many websites are created and grown without keeping users in mind. More companies are doing user research than ever before, but they’re challenged with making the results of that research understandable and actionable. Enter personas, which are generating more and more buzz.

But what are the various approaches to creating personas? How do I actually interview and survey users? How do I segment users and turn the segments into realistic personas? How do I use personas for directing overall business strategy, scoping features and content, and guiding information architecture, content, and design? The intent of this book is to give practical advice and direction on creating and using personas, and also to challenge all of us to bring personas to the next level.

So, is the user always right?

Yes, philosophically. Successful companies recognize that putting users at the center of decision-making is almost always a good idea. But taken literally, the book’s title is also a lovely, overstated attention-grabber. Let’s face it, users often can’t tell you the right direction for the website. But buried in their goals, behaviors, and attitudes (both stated and unstated) is everything you need to discover the right path. That’s why good user research isn’t just about listening to what users say.

So it sounds like analyzing research—not just plain listening to what users say—takes a certain kind of background and training. Is that true, or can anyone conduct this kind of research?

Sure, anyone can conduct this kind of research provided you don’t care whether the output is useful or not. Okay, maybe that’s harsh.

As our work as information architects, designers, marketers, or insert-your-favorite-title-here gets more sophisticated, so, too, do our methodologies. Talking to a dozen users and making critical business decisions based solely on that qualitative research just doesn’t cut it within some organizations. Increasingly, we need to raise the bar and invoke proven tools from other disciplines, such as statistical analysis techniques that enable us to generate persona segmentation based on quantitative research. We need to incorporate data on not only what users say (in a survey, for example) but also what they do (log files and search logs). All of this can inform the creation of personas that represent a much more accurate and useful portrait of users.

Raising the bar means bringing in specialists more often, or training ourselves in new specialties. But honestly, isn’t that what we love most: pushing ourselves in new directions?

Indeed. But, as you say in the book, “pushing ourselves” means playing nicely with others in the company—others in departments that may not cooperate or throw up roadblocks. You point out, “Increasingly, companies are realizing that their Web sites need to be a cornerstone of their marketing, sales, and servicing efforts.” Can we leverage these departments with their new outlook on research for tools and techniques?

Absolutely, though I’d describe it as “collaborating” with them rather than “leveraging” them. Running a business based on actionable knowledge about users requires understanding those users throughout their complete lifecycle with an organization. Thus, all customer touchpoints within a company (from sales and marketing to user experience to customer service) must come together to create a shared vision of who the users are and how to best serve them. Personas that are more rigorous and that are communicated in the language of business are more likely to bring these different groups together and bring their strengths to the table.

I’d love to talk more about the rigor or fidelity of personas. In the book, you go into great detail on how to show the right personal information in personas. Can you describe the process of turning your research into a reality?

As you saw in the book, I believe that personas are only as good as they are actionable, and that means creating realistic details that will actually inform decision making. If I say that Francis the First-Time Home Buyer loves Billy Idol, that’s an interesting detail that makes her persona more realistic, but it doesn’t help me make critical decisions about the real estate site I’m working on. On the other hand, if I say Francis is embarrassed by her ignorance of real estate and unlikely to ask friends for advice, that’s helpful information for deciding what content the site could offer and how that content should be provided.

With personas, the right kinds of details matter, and they typically involve goals, behaviors, and attitudes.

When you’re unable to talk to real people to gather research (and you give us your blessing in your book to do so!), where do you look for inspiration for creating them?

Let me first say that talking with real people is always better than not doing so. I don’t believe it’s ever a waste of time to do primary research with users. And it doesn’t take much time or effort to set up a few one-on-one interviews with typical users.

However, when even that kind of limited research is impossible, personas based on no research are better than no personas at all. At a minimum, personas force everyone to agree on and apply a shared vision of who you’re targeting and what they need, and that’s a very good thing. When creating personas in this way, involve colleagues in your organization who have direct contact with customers, such as those in sales or customer service. Take advantage of internal knowledge that already exists, then look externally at research by companies such as Forrester Research. These can be great sources of insight for brainstorming which goals, behaviors, and attitudes might be most effective for defining your personas.

I was surprised to see that you recommend using very specific photos to represent the personas. Isn’t a more general photo better? Isn’t that what Scott McCloud taught us?

Ahh, but remember that in Understanding Comics, McCloud points out that generalized sketches work well in comics because they better enable us to see ourselves in the comic. With personas, however, the whole point is to see real people as our users and not focus on ourselves. Choosing very specific photos forces us outside of the habit of thinking about ourselves. Suddenly there’s a very real person staring back at us with specific goals, behaviors, and attitudes that we must address.

Some of the examples in your book are spectacular in that they reveal details of deliverables that are often hidden behind proprietary walls. Of particular interest was the way you wove personas into the process of prioritizing features. Did extreme programming have any influence on this tool? Bringing “user stories” into their feature prioritization is a standard part of that process.

Actually, no. The tools I show in the book were simply a natural extension of what many of us already do. We talk about things like scenario-based design and use cases, but we seldom make the connections explicitly between the user research we do and the decision-making tools we use. At Molecular, we spend a lot of time drawing these connections, so it’s clear to our clients that decisions we make about features, IA, content, and design are all tied back to our knowledge about the real people we serve. Making personas a living part of the entire process is at least as important as creating effective personas to begin with, so we embed personas in our deliverables as much as we can.mulder personas

Can you talk about a time where you weren’t able to make personas part of the process despite your best efforts? Perhaps there are even times when integrating personas is not useful.

I remember a time when my team presented personas to a client using cardboard cutouts and a little role-playing, only to find that this company’s culture frowned on anything remotely touchy-feely. They wanted hard data, and we foolishly didn’t take the time to understand our audience before presenting personas to them. On that project, we continued to use personas, but because our initial presentation left a bad taste in everyone’s mouth, the personas simply weren’t as effective in guiding decision making. As you can imagine, we didn’t repeat that mistake.

I was excited to see you start a book site to supplement and support the book. What are your plans for the site going forward?

The blog is intended to continue the conversation. A book is a snapshot frozen in time, but of course personas continue to evolve as a useful tool for managing websites. So my site tracks the latest news and opinions about personas, and I hope it becomes a useful resource for the community.

Did you use personas to create and guide the content for your book? How applicable are these techniques for other media?

Yes, I sketched out a few personas for the book, and found them very helpful for guiding not only what I wanted to cover, but also how to approach each topic. One persona was very much based on a client that I worked closely with, but I’ll never reveal that person’s true identity!

I absolutely believe that personas are valuable across many different domains. Whether you’re designing tax forms, toasters, or retirement accounts, taking time to describe who your users are and what they need can always be helpful for creating a product that will best serve them.

What’s next? Are you excited about using real stories and people to guide design? Are there changes coming in the way we use personas in the process?

More and more, businesses are letting real users have a tangible impact on decision-making, and I find the results exciting. My favorite current example is the way Starwood Hotels has used Second Life, that crazy virtual environment everyone is talking about, to create a large, detailed 3D model of a new chain of hotels it’s creating. In this virtual environment, users can walk through the hotel and give feedback on everything from the overall architecture to the fabrics. Starwood gains valuable feedback for improving its product before actual construction begins, and users get to contribute in a very real way.

The whole point of personas is to make users an active part of the process of running your business. Virtual or not, personas keep our eyes focused on the people who matter most: the customers we serve and who send us the business results that we so richly deserve.

icon acrobatDownload Chapter 3, The User Is Always Right (PDF)