Straight From the Horse’s Mouth with Dan Brown

by:   |  Posted on

iTunes     Download     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”: and “author”: 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.


[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

by:   |  Posted on

iTunes     Download     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.


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 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

by:   |  Posted on

iTunes     Download     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 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

by:   |  Posted on

iTunes     Download     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!”


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

Transitioning from User Experience to Product Management

by:   |  Posted on

iTunes     Download mp3     Pod-safe music generously provided by Sonic Blue

banda_headphones_sm.gifI had the pleasure of talking with Jeff Lash and Chris Baum on their two part article, Transitioning from User Experience to Product Manager. We talk about how more and more UX professionals are looking at taking on the role of a product manager.

This is a valuable conversation for those looking to make a change in careers; an honest discussion about the pros and cons of each profession.

We discuss:

*Product Vision – The importance of creating a vision and educating others about it.*

We discuss the Product Management Vision framework discussed in their article and how creating and educating others about the vision for a product is a key aspect of the Product Manager’s role.

*UX vs. Product Management: Responsibility, Focus, and Reliance*

Jeff and Chris discuss the following elements that outline the three central differences between the UX professional and Product Manager:

a. Responsibility
b. Focus
c. Reliance

*Coach vs. Tyrant*

We also discuss the importance of conflict management and how the product manager acts more like a coach in getting the team to move towards the same goal. Understanding both the market and the user are key aspects of the product manager. In essence, the Product manager has to not only “make the Kool-Aid”, they have to drink it as well.

*All Responsibility, No Power, So Listen!*

Jeff and Chris provide a realistic definition of a Product Manager as someone who has all of the responsibility and none of the power. They go onto to discuss the need of the product manager to listen carefully to not only their team, but also how to lead without authority. As well, the importance of knowing where your product can fit with all other products offered by the company.

*Let Go of the Details*

Chris talks about the importance of realizing that as a Product Manager your role shouldn’t be focusing on the UI in creating Wire Frames and Site Maps. As a Product Manager your role is to see the bigger picture and provide the vision and clear direction for your team.

*IA Summit Presentation Recap*

Jeff and Chris discuss the presentation they gave at the 2007 IA Summit in Las Vegas.

*Other notes:*

Check out these great blogs on Product Management:

Pragmatic Marketing
The Product Management View
Tyner Blain
Michael on Product Management & Marketing


[intro music]

Jeff Parks: This podcast is brought to you by TechSmith. Right now, millions of people are snagging, are you? And by The IA Summit. This year, your peers and industry experts will speak about how topics such as social networking, gaming, patterns, tagging, taxonomies, and a wide of range IA tools and techniques can help as users experience information. Further events happening all over the world, be sure to check out

The other day, I had the chance to speak with Jeff Lash and Chris Baum on their two-part article, “Transitioning from User Experience to Product Manager.” We talk about how more and more UX [User Experience] professionals are looking at taking on the role of a product manager and the pros and cons of both professions. In particular, things to be very aware of, if you’re going to make that transition, and knowing the differences in the roles and responsibilities, and what, ultimately, you’re accountable for as a product manager that you may not be currently accountable for as a UX practitioner.

A huge thank you to Jeff and Chris for taking time to join me today, and I hope everyone enjoys the podcast. Cheers!

[podcast begins]

In your article, you mentioned that product management is garnering more interest from interaction designers, information architects, and UX designers looking to increase or influence and ensure user-centered product development. Jeff, the first part of the article talks about defining–“What is a product manager?” Maybe you could talk to our listeners a little bit about that?

Jeff Lash: Sure. I think, as we described in the article, traditional product management treats the product manager as kind of president of the product. So, really, there should be one person who’s in charge of all aspects of the product, and, obviously, you need to work with people from different areas of the business. So, finance, sales, marketing, development, engineering, production, things like that. But, really is, I think we’ve seen on lots of projects and products, you need to have that one person who’s coordinating all those elements and really taking ownership and overall responsibility for the success of the product.

Parks: Exactly. Chris, you go on to talk about the responsibility of product managers. You note that because user experience professionals are often already fluent in understanding customer needs and knowledgeable about the markets for which they’re designing, they have the potential to make very good product managers. Maybe you can outline some of the key points and why they make good product managers.

Chris Baum: First and foremost, we really understand, as UX professionals, our job is to understand how people approach using a product. Really, at its core, when you start going across all those different elements that Jeff mentioned, the idea is that you can bring that knowledge to the entire product not just the user experience to the interface, but also things like the marketing and the service aspects of the product. Really, having that larger purview, it really leverages the knowledge that we have as user advocates.

Parks: Right. In the article as well, I guess, address this question to both of you, you outline a framework for how to monitor a market response. The framework follows a vision strategy, a roadmap, requirements, and features. As UX professionals moving into product management roles, might there be a tendency for them to jump straight to the roadmap without having experience in developing vision strategies before, vision and strategy?

Jeff: Yes, this is Jeff. I think it’s always a challenge. I think that’s not just for user experience professionals. I think it’s for anyone as to really be able to step back and say, “What is the purpose of what we’re doing?” I think, the tendency, a lot of times, is if you’ve got a product that was, you know, a single inventor had a great idea. He says, “Oh, we’ve got this great idea for a product, let’s go ahead and start building it.” I think a lot of people even skip the roadmap and just get to, “All right, what are the features it should have?”

I think that as UX professionals, a lot of times, you know, people are brought in kind of once the requirements or features have been defined. They’re used to spending most of their time really saying, “OK, how can we best design this feature or what’s the interface that it should work with?” But, I think, really, good product management spends a lot of time on those upfront activities and really establishing what is the vision for this product? What’s the market for it? How are we different than our competitors? What are the market needs that we’re going to be solving?

I think, like Chris mentioned, I think user experience professionals have a lot of the traits and experience that helps, because really we spend a lot of time in usability research, and site visits and things like that, really trying to understand the underlying needs and problems of our users that we’re trying to solve. That can flow into that process of creating that vision and strategy.

Parks: Exactly. Chris, the other point that was mentioned here was this idea of the roles and responsibility would be something like portfolio management. Maybe you could talk a little bit about that and what that involves?

Chris: I mean, for example, one of my positions is I worked at eTrade, and eTrade, of course, has several different business lines. There’s not only the website aspects of it but the software that–they have a trading software as well. The thing is that you, as a product manager, learn more about the customers that you’re serving and bring that knowledge into your product, you can also start to gather knowledge and share your knowledge with people and other products.

For example, like when I was at eTrade, I did a lot of things around the customer service aspects, like the content around that, helping people find information, et cetera, et cetera. Of course, customer service, in and of itself, is really more about finding content about the other products on the site. So, I was working very closely with the product managers there to figure out what they were trying communicate with their product and make sure that, not only could the customers find the information they were looking for, but also that we represented those other products in the right light that fit with their vision and their strategy. Then also, influence that vision and strategy through what we were finding out, what customers were having issues with.

Parks: Yes. That’s interesting, because you also go on to talk, in this article, about the roles of a UX designer versus that of, say, a product manager. You outlined three main areas of responsibility, focus, and reliance. Jeff, maybe you could talk a little bit about those three areas and how they differ?

Jeff : Sure. I think, this part of the article came about because, in talking about this and discussing and talking with other people I know, there’s kind of, sometimes, a lot of confusion. There’s a great article that we referenced on by Jonathan Korman of Cooper who really kind of, I think, hits the nail on the head as far as describing what key areas a user experience professional does. And then having people say, “Well, in my organization, we call that a product manager.” So, really, we wanted to try to delineate how that was really different.

So, I think, responsibility is probably the biggest area and kind of what we were talking about earlier, in that, a product manager is responsible for the overall product. While each individual contributor to the product should be concerned with its overall success, really they’re not responsible for it. So, a user experience person should be, obviously, concerned with the marketing strategy, the pricing, and the engineering work. But really, they’re not responsible for those aspects, whereas the product manager is.

Focus, kind of, ties in to that, and again, that each contributor, the user experience person is focused on these experience aspects, that software engineers focused on the software development. They’re focusing on those individual areas where the product manager is not really focusing on any one area, but needs to understand what’s going on in every area.

And lastly–reliance, and just that, as a product manager, I rely on the people I’m working with on my product development team to do their work. An information architect usually is not relying too much on anyone else. They’re, in general, responsible and accountable and have everything they need to do their own job. But, in my case, as a product manager, I’m relying on all these other people, and obviously, working with them. So it’s a different–and that kind of gets into the more of the softer side of product management. You have the leadership, team building and cross-functional teams, and that sort of thing.

Parks: Yes. Exactly. Because also, you point in the article, Chris, that how to deal with conflict between product management and user experience. Because ultimately a product management role, at, least from what I gathered, from these two articles is really looking at the bigger picture and not focusing on a niche area as Jeff just described around, say, an information architect. And dealing with conflict is a critical part of a product management role, I would imagine.

Chris: Exactly, I mean in part of the article, in the second part, we talk a little about the product manager being more like a coach on a professional sports team. It’s someone who is trying to gather all these people that have amazing talents and get them all moving towards the same goal.

Using the sports analogy seems a little tired, but it is so true, especially as a product manager. In many cases, you don’t have authority over the usability people or the engineers, they’re reporting into other structures in the organization, and unless you can communicate your vision in a way that gets them excited to participate in it, you’ll end up having them refocusing on what they want to do as technologists or what they think is right as a user experience professional, so the idea behind being able to get all those people going in the same direction is actually, when it works really well, is really powerful.

Parks: Yes.

Chris: But it can be tricky.

Parks: And following up on that point, Chris, in your article you said, “a product manager should not be detached from customers sitting in the office and meetings while user researchers are conducting research, ” is there a tendency for product managers to not be involved in the UX process in general from your experience?

Chris: Yeah, it’s really easy right? Because you have the user experience people and especially at first it can actually be, you can let go more of that, especially if you trust the user experience people you’re working with, because you can be worried about, you know, like focusing on the vision or examining the market opportunities, et cetera, et cetera, but the thing that any product manager has to do and it’s too easy to let go of, is make sure you’re touching the people that you’re affecting. But, you know, seeing as you have to touch all these different areas, it’s really easy to focus on, you know, managing up–

Parks: Right.

Chris: –getting the programmatic aspects of your product in order, you know, getting the resources for it, but unless you continually come back and touch the market yourself–

Parks: Mm-hmm.

Chris: –you lose that perspective and so it’s something we really wanted to put forth in the article.

Jeff: Right. I think just to add onto that I think it’s again, you know, if your job, your sole job is to understand the users and create the designs around that then obviously you’re going to be focused on spending a lot of time talking with customers. But as a product manager, that’s one of your many responsibilities, so it’s you know, it’s tough to get out of the office sometimes. When you’ve got meetings and you’re talking about pricing and marketing and logistics and operations and things like that, it’s a lot tougher but I don’t think, I’d be surprised if user experience people who transition into product management have a problem doing that.

I think it’s kind of in our blood, you know it’s something that I don’t need to be told to do, I just understand I need, you know, I set goals for myself and I make sure I do it. But I think for people maybe transitioning to product management from other areas who haven’t had as much of a background in getting out and talking with customers, you know, face to face, you need to be kind of reminded.

Parks: Right.

Jeff: And I think, you know, it’s probably the central tenet of good product management is really to understand the market, not just what your customer needs, but what’s the competitive space, what’s the market, you know is it growing? Are there technology changes? Are there society changes that are going to be impacting it?

Parks: So ultimately those experiences as UX designer is actually a strength going into a product management role. Would you say so?

Chris: Yeah, I think that’s one of the biggest things that’s helped me into transition is that you know I’ve been able to really focus on you know what do our customers need? What do our users need? How can we provide that to them? I think that’s been the biggest thing that helps me out. There’s a lot of other things that I’ve had to learn along the way that I didn’t have as much experience in, but I think if there’s one thing that I could say if, you know, you want to be a good product manager it’s to really make sure you understand your market, understand your customer needs and create your vision and strategy around solving those customer problems.

Parks: Exactly, and that is actually a great transition into the second part of your paper, because you talked about the idea of, you know, making that transition and things you need to understand about that–the product management role. In the first part of the paper you talked about what you do as a product manager that you don’t do as a UX professional and a couple of points that I found really interesting were, the first one, which is, “evangelize the product, you must champion, you must be, you must champion both the product internally and externally, ” and that’s a bit of a difference, a shift in the way UX professionals work.

Chris Baum: I mean, it’s really true.

Jeff: Yeah.

Chris: You know, being the product manager, puts you in a position that, as I mentioned before, the whole idea of being the coach, and you know part of that is the motivational aspects of it. And not only do you need to motivate internally with the people that you work with in the various engineering team, the finance team, the marketing team, et cetera, it’s really important for you to, as Jeff has said before, and it’s really I think kind of brilliant, you have to not only drink the Kool Aid, you have to make it.


Chris : And get everyone else to drink it too.

Parks: Yeah, exactly. And Jeff, the other point that was of interest to me in here was, “provide input on strategies of other products within the organization,” so again, I think it speaks to this idea of being able to really communicate effectively and sort of think outside the UX box and look at the bigger picture.

Jeff: Yeah, and it gets back to what we were talking about earlier about you know how your, the portfolio management aspect. And that’s actually one of the areas that, I think, prompted the most comment on the first part of the article is just about, you know, great, you’re managing this product, but no product really stands alone, and I think more and more we’re starting to see within organizations, you know really, some, some, more attention being paid to how products fit together.

You know the Google example of Gmail, and the Google calendar, and Google documents, is a good one–you know Yahoo has done this for a long time in making their products work all together but I think unless your company has one product, and most companies don’t, really you need to start thinking about that. And it’s one area I know that can be frustrating sometimes as a user experience professional saying, you know, well this seeing what’s going on in one area of the company and saying, “oh geez, I should be able to give some input on that, I have some experience talking with customers and things that I’ve learned that could help provide input, ” and sometimes you’re just not, you know, they don’t invite you to the table.

Parks: Yeah.

Jeff: And for better or for worse, whether it’s right or wrong, as a product manager, you know, you, just by default, sometimes get invited. I know lots of people who are UX professionals who are involved in those, much, those important, higher level strategy discussions but a lot of times, you’re not, so I think that’s a big responsibility of not only having ownership for your product but then working with the other products in the system and making sure everything works together well.

Parks: Absolutely. The next part of that paper you talk about challenges and forces working against you, which Jeff, you just, which Jeff and Chris, excuse me, you both talked about at the first part, but one of them was, “as a product manager you’ll have little to no actual authority, ” and you’re quoting a guy, Kowaski, I think that’s how you pronounce his name.

Chris: No, [Greg] Kowasaki.

Parks: Kowasaki, thank you, described a product manager as someone who has “all of the responsibility and none of the power, ” so I read that and I think, “well, why in the world would you want to get into product management then?” But this is a reality of the role of a product manager. Correct Chris?

Chris: That’s absolutely true in more ways than we can really express in just the article.

Parks: Mm-hmm.

Chris: Because you know when you start talking about touching all these different practices within an organization, like they all have their own portfolios, too, so you have the engineering team all talking amongst each other about what the next technologies are, and they’re trying to bring those influences into their work as practitioners, same with the user experience folks and the same with the marketing folks and the same with finance folks and so it’s really, it’s a challenge because you want to listen to all those influences.

Parks: Yeah.

Chris: but you also don’t really have direct control over them and so it’s really an interesting, it’s really interesting that dynamic to try to take you know, take the input, but make sure that everyone kind of goes for the same goal. And you know, personally it’s been a very interesting adjustment to go from making recommendations about what the product should do, and you know sometimes having them honored and sometimes not, to being the one that takes the recommendations and you know, makes a decision for the product, but yet you need to make sure that, that we honor where they’re coming from so that you make sure that you give the people the right attention and that they get, you make sure that they get, they feel like they were heard.

Parks: Right.

Chris: in the right way, and that you really seriously considered it.

Parks: Yeah. Exactly.

Jeff: I think that’s you know probably the biggest misconception that people have a product management is you know, if you’ve never, if you’re a UX person you’ve been on a project and said, “Oh, you know if they’d just put me in charge of that website,” or “if I was in charge of that software, like, I’d fix everything,” and this, I think there’s this misconception that you know just because you have the title “product manager” you can change all these things. And that’s the biggest thing that you have to learn, you know, how do you lead without authority?

And I think it goes back to a lot of the concepts we’ve been talking about, again about, you know, establishing that vision and like Chris said, working with the other teams and really it’s also at an executive level of trying to get, you know you need to get funding for your project, why is this product more important than something else? And it’s really about, you know, setting the–telling the story of why this product is important, what you’re trying to do and getting people on board with it, because, yes, you’re competing for resources.

Whether you like it or not, you’ve got to get people excited. It’s much easier to make things happen in an organization when you’ve got a product that people want to be a part of rather than something where you’re just telling people what to do. And that’s tough. That’s really an issue about, like, management and leadership not specific to product management, even.

Parks: Yes. And at the heart of a lot of this is the fact that if you have all the responsibility and none of the power, it speaks to the other key points here, is that you’ll be at the center of regular disagreements between stakeholders. And managing that conflict is–well, personal-professional relationships, in order to move forward, you need to move through the conflict to get to the other side, sort of step yourself up to keep getting better. But, there aren’t very many people that are very good at dealing or managing conflicts. So, obviously, as a product manager, I would imagine, Chris, this would be a key part of the person’s job and to be able to be very good at managing.

Chris: That’s a little bit of an understatement actually.

Parks: And a half. Yes, I didn’t articulate that as clearly as I should have, maybe. But if this is– if someone’s moving into this role, this is something they have to be aware of, that this is going to be a part of their daily life.

Chris: Absolutely. It comes from every direction. Really, being someone who has been interested in the whole, like, kind of aspects of user experience, it’s been really an interesting function to, like, step back and watch my own reaction to things.

Parks: Right.

Chris: Because your reaction actually dictates, in many ways, how other people react to you–and reacts to the problem, reacts to the decisions you make. Because as the product manager, you’re the most basic, you represent the product overall. People are constantly looking to you, for how you feel like certain decisions and certain effects are going to change the product, or help or hinder its vision.

So it’s been interesting for me to, kind of, step back and understand the personality aspects of it.

Parks: Right.

Chris: Make sure that I’m giving people the right amount of attention. That you take into account all the effects, not only from a business standpoint but from a personality standpoint, and kind of keep those all up in the air at the same. It’s very much a juggling act.

Jeff: There’s really a fine line that you have to walk. If you’re too authoritative and too much of a “This is how it goes,” then you’re going to turn off people that you need to have a good relationship with. If you’re not enough of a leader, if you’re not forceful–strong enough–then you’re essentially going to take a backseat to whoever’s the most influential or yelling the loudest. There’s a fine line that product managers need to walk, taking responsibility, and showing their authority but at the same time, not steamrolling over everyone else.

Parks: Right. In the whole–[inaudible 22:08]

Chris: Sorry, Jeff.

Parks: No, go ahead, Chris, please. No, that’s great.

Chris: It doesn’t change whether you’re working for a big company or a startup, because I have done both. It’s heightened in the startup situation because everyone is so close together. Yet, things change so quickly that you can always take time to normalize all those relationships. Whereas, in a large organization, it seems like you have time to do that.

Everyone has a lot going on, and they’re all kind of facing inward many times. But, when they come back out in the product situation, whether or not just focusing on the marketing aspects of their organization, it seems to me like that was a little easier at the bigger company. The startups are much more concentrated, and I found that very interesting.

Parks: Absolutely. Another main section of the article you talked about is what you do as UX professional, that you won’t do as a product manager. A couple of key points that I found in the article are product managers do not have the luxury of shooting for perfection in the theoretical ideal. You talked about how the joke is the user experience people always answer the question with, “Well, you know, it depends.”

So, Jeff, can you talk a little bit about that shift in terms of what they do now as UX professional that they wouldn’t do as a product manager?

Jeff: Yes. I think that’s a good one to start with. As a UX person, you’re maybe a bit removed from the overall big picture–the budgets, the timelines, and things like that. So, you kind of say, “Well, look, this is the best decision for the user.” Without knowing, really sometimes, all the implications that go into that. Again, I’ve worked with product managers who aren’t as good at striking that balance and still do shoot for that ideal.

But, ultimately, it all comes back to having that good solid vision for the product and saying, “Look, you know, is this good enough to get us towards our vision? Do we need it to be perfect?” and since you’re ultimately responsible, it’s about making a lot of those trade offs, I think.

As Chris mentioned, you know, UX people are used to making recommendations and saying, “Well, look, this is what I think the best thing for our users or customers would be.” But, the product manager needs to decide, “Well, that’s great, but that might take an extra month to develop. Can we go with the simpler thing that might not be as good for our users but would only take a week?”

I think, the good UX people are doing that now; I don’t mean to say that that’s something you’d automatically switch on when you become a product manager because I think as UX folks start getting more awareness of the business context around in which they’re working, they’re making a lot of those decisions today, even in their user experience role.

I think the other, and probably the biggest shift, and this was something that I heard from people when I talked to them before I started my product manager position, is that you’re not going to have the luxury of being down in the details. If you really like doing wire frames, and sitemaps, and doing detail design–you might not be a good product manager.

I mean I like it, but I also had to accept the fact that I’m not going to be able to do it and I just don’t have the time or the luxury to be able to do it. I work with great designers, and people who can do a lot of that detailed work. But that’s, I think, a challenge for anyone moving to product manager from any role.

If you’re a salesperson and you become a product manager, you’re going to want to become very involved in the sales process of your product and a lot of the decisions around the how the product is sold. But, you got a whole sales team that can work on that.

I might want to spend a lot of time working on the pixel-by-pixel design for the interface. But, I’ve got a whole team of designers; hopefully, that can be working on that. I’ve got other things I need to look into, at other aspects of the product that have more strategic level maybe. But that’s, I think, probably, one of the hardest things to do–to switch your mind from working as an individual contributor to now being kind of an overseer of everything that goes on.

Parks: Right. The other point that you make in this, Chris, is that product managers are not artists or expert practitioners. Can you expand a little bit on that idea? How it relates to what they do now compared to what they would do as a product manager?

Chris: Sure. That, actually, goes a little bit towards what Jeff was saying just a second ago, is that everyone comes from somewhere. You’re going to be thinking about the place where you came from. User experience people are going to be, especially at first, and I was totally guilty of this myself, like really thinking of the interface a lot when I first became a product manager.

But, what I’ve quickly found out was the time that I did that, the product suffered, because the other aspects of it–engineering, the trade offs, trying to fit the puzzle together in a way that makes sense for that moment. It falls off, and definitely, one of the worst things you can do, is be meddling with other people’s works. Somewhat, we need to be able to trust them and be taking their work and fitting that into the larger whole.

And then coming back with feedback and new work that actually satisfies what that vision is. That’s the whole idea of that cycle between from vision to features and then using the market to monitor the results of that. You want to make sure that no one is coming to you and saying, “We need a new widget for this feature,” or whatever.

You need to make sure you’re pushing the entire product going forward and that the interface part, the engineering part, the marketing part, pricing part, the service part–all that stuff is going the same direction, adding to that moment, instead of taking away from it.

Parks: Right. And you follow up with this idea about how to work better with your product manager now. Jeff, you point to the one idea of just start working with them more closely and understanding what they’re doing specifically.

Jeff: Yeah, I think thinking back to experience I’ve had in the past about where I had questions about, “Why was this decision made?” You know, “Well, this would have been better for our customers and why we’re doing this instead?” I think, sometimes it was really that I didn’t understand the bigger picture and the whole context of what’s going on.

So, working closer with your product manager now, as a designer, to help understand– “What is the big picture?” And if you’re recommending one thing and we’re doing something else, what are the other impacts? Because it’s not always about what’s best for the interface, or what’s best for the customer and user. There might be other products that we need this to do things for.

There might be strategic priorities that are outside of your product that you need to focus on. There might be engineering, or marketing, or sales, or finance things that you just don’t have awareness of. And I think a good product manager will communicate that information as much as possible, but I know I’m guilty of it.

You know, there’s just so much information. I try and share as much as I can with my team, but there’s some times that I just don’t know–I don’t know what people don’t know. So, I think, to work better with product managers now is just to understand the context of what you’re working in, rather than having it be a kind of adversarial relationship–in some cases I know it can be.

Really, trying to seek ground…and you want to be someone you can–who can–you turn to as what they call the trusted advisor. Not just on the user experience aspects, but potentially other aspects of the product as well.

Parks: Yeah. Absolutely, and in the last part of the paper you start talking about studying and preparing for our product management role, and you list a series of links, and… But I also wanted to help you promote your presentation that both of you are doing at the IA Summit coming up this year in Vegas. Maybe talk a little bit about what that’s going to be about, Chris?

Chris: So, what we’re going to try to do, is take some of the ideas that we started to put forward in this article, especially the part about thinking about how to relate to your product manager. And, kind of, take what aspects you can take from UX, bring that into the product management role, and then also start to think about the challenges part.

So that, you know, you go through from a workshop aspect and do comparative, and be able to understand how, what information you have to use for a decision at the higher level, so that as you’re starting to examine the possibility of moving into product management, that you really understand at a very hands-on level what it means. So you can have some idea of what that experience feels like, and maybe make a more informed decision.

Jeff: Yeah, I mean I know I’ve talked with a lot of people in the past few years who are user experience people, kind of looking for what’s next. I don’t want to be designing screens ten years from now. There’s some people who do and that’s great, and they’re great at it and I think we need people like that.

But there are also people who are looking for what’s the next step in their career. And I think our goal with these articles, and our goal especially with the pre-conference session at the IA Summit, is really to help UX people who are interested in maybe moving to product management, just understand a little bit more about whether it’s something they want to go into or not.

So explaining a little about what you do as a product manager, going into more detail than we can really hit in an article, and then also having it so maybe some people walk out and say, “Look, I understand more about product management, and this isn’t for me. Now that I know a little bit more about it, it’s something that I don’t think I want to go into. But I at least know how I can work better with product managers now.”

And then for the people who come and say, “Yes, this is something I want to do. I’m definitely interested in it, ” giving them some things that they can start doing to better prepare them. Because I know when I started as product manager, and most people I know who started as a product manager, it was kind of, one day you’re a product manager–Here you go.

Parks: [laughs] Right.

Jeff: And there’s not a whole lot of preparation and training, and I think it actually, it parallels a lot with the user experience professions in that there’s a lot of misunderstanding and mischaracterization. And different organizations treat the roles differently, so there’s not a real commonly accepted set of things.

And I think that’s probably a little bit more mature maybe in product management than in UX, but there’s still a lot of people who are product managers who don’t really know what a product manager should be doing. And our goal with this is really to help people who are interested in product management understand a little bit more about it, and learn what they can do to prepare themselves for that role.

Parks: Absolutely. You mentioned, just one final thought, you mentioned two major organizations for product managers: Product Development and Management Association, as well as the Association of International Product Marketing and Product Management, so people can Google those things, or of course they can look them up on your article. Are these associations sort of like the Information Architecture Institute? They provide a high-level context and information for product managers?

Jeff: I think both these are really more–the PDMA is–the more well-known, at least as far as my experience has been. And as an organization that deals with product management, not just technical product management but any kind of product management and development.

AIPMM focuses a bit more on the marketing side as well. There really isn’t any technical on-line or software type product management organizations. I think both of these are pretty mature and they’ve got training, and resources, and local groups, and things like that.

And there’s also, again, a lot of informal groups either that are, around the country and around the world, that are either formally affiliated with one of these two, or informally just you know, groups of people in a city who are getting together to talk about product management.

Chris: One thing we haven’t really talked about, and it’s part of not only if you find that product management is something you really want to look into but, is the aspect of helping a product manager if they aren’t getting out in the market enough. Like, talking to them about bringing them along on your research.

Or if they’re going out to talk to customers, that you go with them. As a user experience person, that would be an amazing way to really get into the mindset of your product manager. Or as the product manager it’s to really come together with your attitudes with your user experience people. Because, what that does is it really shows you the kind of things that the other person is looking for in their exploration.

And that’s not just a practitioner thing, it’s not just a product manager versus a user researcher or a user experience person. That is a personal connection. And obviously it would be ideal if you can have that same connection with your technologists and your marketers and your service people as well. But that is one way, as a user experience person going into product management, or vice versa, if you’re working with your product manager, to really understand where they’re coming from and to get resonating with each other on what you’re really thinking.

Parks: Right. Well… yeah. I’m sorry, go ahead.

Jeff: I was just going to say, the overlap, that’s one of the major overlaps between product management and user experience is that you need to be talking to the customers. And so, the more you get on board with each other there, the more that will infuse the product with the idea of serving customers.

Parks: Right. Because, ultimately, we all learn best by experiencing the lesson directly. And if product managers don’t get into the field, then they can’t really understand what the crucial nature is of understanding your end users. It was interesting, I was listening to a podcast by Marissa Mayer, from Google, who’s the Vice-President of Usability at Google, and she was talking about the Ten Commandments of user experience, and the ninth one was about how–was users, not money, and how Google has always followed the needs of their end users, and not jumped into the latest fad in technology. And to help create products. And obviously Google Gmail, Google calendar, all of these tools online are some of the most popular tools for people to be using today. So that, I think that speaks to your point. Right. Exactly.

Jeff: And just to add to what Chris said, I think pretty much every user experience person I know is told the frustrating story about, we found these things from the users and I have to spend weeks trying to convince the product manager that this is what people actually needed and that this is what we’re supposed to do.

Parks: Right.

Jeff: And it’s frustrating and you feel like you’re banging your head against a wall. And I know I’ve been through it before, and I think most people have. Wouldn’t it be great if you could not have to spend your time doing that, and instead spend your time actually executing on what you learned?

I worked on a product a couple of years ago where we did a bunch of concept testing. We went out into the field and talked with customers and users, and it was just me and the product manager, and we, after those couple days–and then as Chris mentioned, it’s not just the research you’re doing, it’s, well, you go out to dinner and drinks afterwards and you talk about stuff.

And when we got back from that trip, we both really had a good understanding of our customers and we agreed and we really understood what we were supposed to be doing. So I didn’t have to spend my time writing up a trip report, and putting a presentation together, and trying to convince them what we should do. It was, we knew exactly what we needed to do and let’s just start doing it.

So that was such a valuable experience for me and I know the product manager benefited a lot as well, because it was something that maybe, if I hadn’t asked, or really pulled him out, he might have not done that one his own. So it worked out great for both of us, and ultimately helped the product out a lot.

Parks: Brilliant. Well, Jeff Lash and Chris Baum–Thank you very much for joining me today.

Jeff: Thank you.

Chris: Yeah, thanks for having us. It was great.

Parks: Cheers. Again, the article is Transitioning from User Experience to Product Management, and you can find it on