Christina York: I'm Christina York and I live and work in Ann Arbor, Michigan. I work for a small not for profit company called Ithaca. Ithaca makes products that support scholarly research in advancing knowledge. J store is one of those products, you might be familiar with it. When Jerry called me, I was thinking a lot about all the different things we were trying at work. I'm fortunate to work in a place where we really have a lot of creative freedom to choose the tools we want or the methodologies we want. We've been experimenting a lot with things, and I've also been doing a lot of reading to and for my experimentation. A lot of things I've been stumbling on recently are debates, discussions in the UX community around design and what is design and the role of design, and how do you define design. Design is a process, not a thing that you own. Or design is a methodology and not an outcome. I really don't want to engage in that philosophical debate, although you might see that creeping into the story I want to tell today. The story I want to tell today is about using design. When you use design as a shared activity, it can improve communication, facilitate communication, and really help you make better decisions around product development. The story begins with our organization that says, "Hey, we have a new business model, and we need you, Scrum team, to create a product around this new business model." All right. Scrum team says, "OK, how do you do that? All we have is a business model." The first thing you do, one of the first things we do in Agile, is we start getting stories and start planning release planning and do planning, planning, planning. One of our first goals we thought about was, we need to help the business owner of this product plan out the approach for the very first launch, and to help scope it right, to help them have a plan of attack that is going to get them to a place where they can say that it was a success. As, at the time, as the UX person -- well, there was a couple of us -- my goal was, "I just need some information that can help me do my job really well." I want to do a really good job. Telling me, "Go make a product to match our business model," how is anybody going to know if I really did a good job? I need some better information off the get-go. Well, especially with any new product launch or in very early stages of projects we had a need to strategize about the approach. We had to think about, "What was the desired experience we wanted to create around this new product?" We did not need stakeholders or team members agonizing over where to place the blue button. At this stage we don't care. We're not even talking about the interface. But as some of you may know, it can be very difficult to manage conversations at the strategic level, to keep people at this abstract level, a big picture level. I think it's human nature to tend toward the concrete, things that we can really sink our teeth into and understand or see or touch. Therefore, conversations always tended toward how to arrange the interface. In the early phases that's not what I needed to know as a designer. So I set out some high-level goals around these challenging aspects of strategic versus tactical. Really, the first goal is all I want to do is facilitate decision-making at this point. Then I do want to enable participation in the design but at the appropriate level. I do want to be perceived as a teammate, as an equal. Not as somebody who walks into the room with all this vast knowledge, and trust me it's vast, and saying, "People.... [laughter] Christina: ...this is how it will be" because as you well know when you say that, that's never what it ends up being when it launches. So I had to come up with a plan. How do we do this? If we wanted to do this as a team and really be perceived as a teammate, we had to have a complete process that screamed collaboration. So the very first thing that I needed to do was level-set. Early on I realized that as a UX person, I didn't fully understand the business model. Nobody did except the business owner. The business owner didn't fully understand the interface that their product was going to be fitting into. They also didn't fully understand the related product offerings that were outside their realm of ownership. So we had some gaps there. So we needed to level-set. The next thing we needed to do as a group is think about this is a new product -- all the great opportunities and all the scary parts, the rest that come with it. What better way than to do that as a team to have lots of different perspectives come in together to quickly brainstorm and do that? Then the third part I thought, "Why not participatory design?" Participatory design, I'd done some stuff in the past I'll mention in a sec. But when you treat it as "design is simply a problem-solving activity," it really opens the doorway for anyone to participate. It doesn't become so scary for somebody who will say, "I don't know how to draw," or "I can't sketch a thing." Nothing to do with that. Every design problem is simply a problem-solving activity. Phrasing it that way and approaching it that way really helped -- it didn't matter whether you were an engineer or a CEO -- to participate in the process. Through those three phrases, what did I do? Came together with a group of stakeholders, and we started to level-set by sketching what was known together. This is just a crappy photo of [laughs] one of the things we sketched. We decided to stay at the work-flow level. We talked about what was going on in the current interface, in the current product offering, and saying, "Well, let's sketch out all the activities that people do, how they're related to one another. Let's just put it up on the wall so everyone can see it." We built it together so that no one person is responsible for remembering every single thing. Starting to level-set, we sat down, then everyone got two different-color sticky notes and said, "Let's brainstorm together." Opportunities and risks. People have different areas of expertise and knowledge about the business. Coming together and looking at this shared picture and saying, "What do you see that's good? Bad? What questions do you have?" We placed those sticky notes -- yellows were opportunity, pinks were risks -- in the appropriate places on the work flow. Then we talked about it, and we stood back and we looked at it, and we said, "Wow, are there clusters? Oh, are there places where there's lots of opportunity and little risk?" Because, for initial product offering, you don't need to build every single possible feature that will ever be needed. You need to come up with the right place to start, and be successful at that, and then evolve your product. Really, visualizing it this way with different perspectives was useful in saying, "Hey, we see a couple of natural starting points for integrating this new product offering into our current interface." Yeah, that's a great process, but we've got to talk about how, as the designer in the room who came up with this activity, I wasn't perceived as the owner, or the expert in the room that really shut down conversation. What I did is I just put the facilitator hat on and made it very clear, not only in what I said but how I acted, that I wasn't a subject-matter expert in this room, that I was a facilitator of the conversation. A facilitator moderates, mediates, mitigates. A facilitator stays neutral. He's not there to express opinion. A good facilitator focuses on listening and paying attention to the dynamics in the room, looking for opportunities to connect, looking for rough patches to smooth over. I never asserted my expertise, even though, as I said, it's vast. [laughs] I, instead, asked a lot of questions. If someone was coming up with something that was a little off-track, maybe leading them to my conclusion via line of questioning was a better approach. Let them think it's their idea. That's a great idea. [laughs] A good facilitator does ask a lot of questions. The general rule is about you guide, you don't decide. A facilitator is not there to make sole decisions. This team really wanted to make decisions together, so I could never present myself as that. Before I finish my story and tell you what happened, I want to talk about the fear -- the fear of giving up ownership of design. Sometimes when I talk about this, I hear the fear or the questions when people ask me. If being able to lay claim to a design is the only value or skill you bring to the table, maybe you should be nervous. I think, more often, UX people sell themselves short. Creating great experiences is not just about design. It's the culmination of the interactions, perceptions, and feelings that people develop around that product you make. This is much bigger than design. If this is much bigger than design, we can bring much bigger value than just owning the design to the table. We can lead decisions around design. We can be leaders in that. We don't need to plant the design flag in the product and say, "We own this." We can actually provide a service to the organization and creating great experiences around product design, not necessarily the product design itself. So if we can get over that fear, we can maybe have some good outcomes. So what happened? Well, we decided on which workflows in the existing product offering to target, how to expose our new product for the first time. We decided ways that we could alter those workflows. I guess the low-hanging fruit, right? The places that it might be easiest to have success. We picked those out as a group. What didn't happen is we didn't get into debates over color, the cadence and rhythm of messaging, or where to place the pink button. We didn't get mired in detail, and that was really important for the early stages. What we succeeded in doing in one very simple meeting I think, and I'm going to oversimplify, is we enabled by setting that direction, that high-level direction, and keeping it at the strategic level. We enabled that business owner to start figuring out real success criteria. You call them KPIs or measures of success, whatever you're going to call them. But that business owner could go away from that and say, "Given those workflows and those entry points, what are the things that are going to be important to measure to see if this is successful?" We also gave that product manager the opportunity to make better scope decisions about the initial release. We gave that Scrum team an opportunity to focus. They came out with something that was very concrete in the approach and really set ourselves up for success as a UX designer to say, "I have my pathway to enter in. I know the approach, and I know what it takes to make a good experience around that." This is an easy measure of success for me. So it allowed me to do my job better. The lesson in this very specific case is because I'm like a manager of a group I tend to try to evangelize as much as I can. There is no need to sell the value of user experience when we design together. The business owners came to that conclusion themselves. The team came to that conclusion themselves, and this became a thing that the team owned. If you own something, generally you care for it. This represented a slight change for us in how we did things. [laughs] By the way, if anyone can name all of these movies? OK, sorry put down your hand. Never mind. [laughter] Christina: We've done participatory design before. A few years back or actually several years back now a colleague and I did our first foray into participatory design using the FIDO method. It stands for Freehand Interactive Design Offline, and it's with end users. So they came in. We had a magnetic white board, and we had them design something. We had 20 of them come in and do it and use that as raw data. But our intention has always been on participatory design with end users. So really the change for us was taking that and turning it inward on ourselves. We're still working on this. We're still expanding opportunities for this. I have a colleague who couldn't be here today. She's doing a lot of this type of activity, via design jams within the context of Scrum teams. So with engineers, QA specialists, product managers. As we continue to evolve this way of allowing everybody to come in, participate, and design in appropriate ways that I think some lessons to be learned. In that one case, it would have been maybe really good to have a more diverse audience. We had a little bit of diversity in the room. But one of the real values that came out of it was during that level-setting activity, hearing what that person had to say and hearing what I had to say and what everybody else in the room had to say we were like, "Oh, that's why you act that way." [laughs] Or "Now I know why you said that." It's not personal. Everybody wants this product to be a success. Nobody is trying to sink it, so remembering that. So the moral of my story, when you hear a stakeholder or a business owner, anybody who is not a UX person, say, "Make this. Do that. Put the pink button over here, and I want more midi," there's no excuse to have the attitude that everybody wants to be a designer, "Oh, everyone thinks they can be a designer." It is an opportunity as a user experience professional to say, "That person needs help in decision-making, and I can design a great experience around decision-making and to put our skills to use in different contexts." So I want to thank you for listening, and you can tweet me or email me if you'd like. Or you can ask me some questions. [applause] Host: Excellent. What questions do we have for Christina? Male Audience Member 1: So you shared this participatory design at the kickoff of the project. Were you able to pull that through the rest of the project or was it just the starting point? Christina: For me unfortunately that's where I dropped off because we hired that guy in the corner, and then he took over [laughs] for me. Yeah, you over there. [laughs] I didn't get to see it through, but I have that colleague and others on the team that are trying to work that through with the Scrum teams. But not just with the Scrum teams. Sometimes we do Agile, and it's obvious because I've said "Scrum" 50 times. But there are other departments in the organization that are often excluded in our development process that have valuable information. So we've been trying to do more type of participatory design with them. So for example, we call them support, but our call center essentially has a wealth of information. They talk to those people every day. So working with them and trying to pull ideas out from them, you never know where a good idea is going to come from. They're often not included on Scrum teams. So I know I have some colleagues. I keep pointing to the back corner because most of them are sitting back there. He's over here. Most [laughs] of them do those type of activities anyway, and we've been doing more and more of that. Male Audience Member 2: I have a question from the twitters. [laughter] Male Audience Member 2: I loved what you said about framing design as being simply problem-solving and how that expands the space and invites more participants in. If you let some of the shiny off of it and say, "No, this is just problem-solving. Come on." Erik Dahl from Columbus, who many of us know, wishes he could be here but he can't. So he's following this on Twitter refreshing every couple of seconds. He has an objection which is... [laughter] Christina: Is it about maternity pants? [laughter] Male Audience Member 2: He says he hugely disagrees with the approach to say design is simply problem-solving. He's saying, "Design is as much problem-finding as problem-solving." Did you have problem-finding and changing of the sense of the problem by doing this participatory design? Or was it more mostly about the solving? Christina: So I'll say it's about the framing because I treated what the business came to us with as the problem to be solved. So I don't disagree with what Erik says, especially if you're doing exploratory things. At this point they had already created a new business model. So for us that was the problem. "Here's [laughs] your business model." Oh, what do you do with that? How do you turn that into something that's awesome on the website that everyone's going to agree is awesome? So we had already had the problem in a way handed to us, but I do believe that that is another huge strength of our profession, is in the ability to take a look at things and winnow down and say, "This is the core of the problem." That's what we do. We assess the need. Well, I suppose we have to listen to what people say, but what they say [laughs] and what they need is not always the same thing. So that skill is really important. So I don't disagree with Erik, but he's wrong in this situation. [laughter] Cynthia: Hi, Christina. It's Cynthia from TechEd. Christina: Hi, Cynthia. Cynthia: Some of the clients we work with will talk about a challenge that's universal, and that is selling the value of user experience internally. You said something really wonderful. You said, "No need to sell the value of user experience when we design together." So this whole concept of participatory design seems to address that challenge, and I wonder if you could say anything more about that because it is such a common refrain. [laughs] Christina: In my younger, maybe more passionate days, I always complained with people were trying to butt in on what I was doing. "Why are you bugging me? I'm not done yet. I'll show you when I'm done." Very impatient. Just experiencing the success that it speaks for itself. So I had a wise boss at one point that was talking to me and saying, "You're spending a lot of energy trying to convince people of the value. If you just really spend a lot of time doing your work really well, they would see it themselves." Sometimes that works for me, but I tend to be a little more aggressive with things [laughs] like that. But when I started to see, when I included people in instead of keeping people out, to say, "Tada! This is what I made." When people see the journey from Point A to Point B, they're much more likely to say, "This is where we want it to be" than for you to say, "This is where I started and surprise. This is where I ended up." So just over time learning that lesson and figuring out ways to include people and making mistakes and including them at the wrong time or the wrong people for the wrong things or setting wrong expectations. I think it is a journey in learning for that, but the more you can bring in the better the outcome is. Thanks. Male Audience Member 3: I had a quick question. As a UX professional a lot of times, depending on where you start out either as an outside consultant or someone internal in the organization, it might affect your style. As an outside person you are encouraged to look like a thought leader, and you are encouraged to throw out answers and then defend them, that kind of thing, which is forcing you into that position of being the owner. I was just wondering if you'd maybe considered whether you're an innie or an outie? Does that influence style or are there ways around that? Christina: I have very little experience being an outie. [laughs] But I have the... Host: Well, boy, now. [laughter and applause] Christina: Yeah. [laughter] Christina: I opened myself up for that one, didn't I? [laughter] Male Audience Member 3: Sorry. [laughter] Christina: Good on you, Jerrod. [laughter] Christina: I'm the new united. [laughter] Christina: Of course, I did try this once with external clients in the setting I'm in now, and I would describe it as an outie situation, where they're our clients and they want to have confidence that we have this expertise. I might have changed the tone a little bit, but ultimately what I had done is had them do the participatory design activity, which I had already done with end users. Then when they were done, I showed them the two together. I said, "Tell me what you see here" and let them start to draw conclusions. So there were aspects of this participatory thing that really did work with an outie, with someone that I wanted to be confident in my skills. I think it was more in how I managed that conversation and managed that interaction with those clients that garnered the respect. We had an issue where they wanted something that was going to be really, really bad for their user experience, and me walking in there and telling them that, it's not always that convincing. So I think it was more in that relationship management. Host: Thank you very much, Christina. Christina: Thanks. [applause]