SpoolCast: UX in an Agile Environment with Jeff Patton and Jared Spool - Transcript Brian Jeff Patton, interviewed by Jared Spool; recorded July 25th, 2008. Christiansen: [music] Brian: Welcome. I'm Brian Christiansen, the producer of UIE Podcasts. In this week's episode, Jared speaks with Jeff Patton, a leading consultant from Salt Lake City who specializes in the challenges of integrating user experience work within Agile development environments. Jeff will be presenting his full day seminar, Bringing User-Centered Design and Practices into Agile Development Projects, at our User Interface 13 conference; which will take place this October 13th through 16th, 2008 in historic Cambridge, Massachusetts. You won't want to miss it. Now, here's Jared. [music] Jared Spool: Welcome, everybody. I am here talking with Jeff Patton, who is our go-to guy when it comes to building great user experiences with an Agile development environment. He's going to be presenting at the User Interface Conference in October in Cambridge on developing in Agile and creating great user experiences. I'm very excited to have this opportunity to talk to Jeff today. Hello, Jeff. Jeff Patton: Hi, Jared. How are you today? Jared: I'm doing great. So, I thought we would talk about the way that user experience has been done and the transition that it's going through; in particular around the area of iteration. When I started in this business, we quickly learned that the way to get a great user experience is to be able to create a design as quickly as possible -- a mock-up of a design -- get it in front of users, ask the users to work with that design, get feedback on how it works. Then try that again. We found that the faster we did that, the more we were able to iterate just like that, the better our designs were. The secret seemed to be not in getting the right design in the first place or just sitting and thinking about the problem for a really long time; but getting things in front of users and really designing well. Interestingly enough, the big gating factor when we were doing that was the development community. It was the development side, they would push back and say, "No, no, no, we need a long time to think this through, come up with the right architecture and build out the design before we can have something ready to test." Jeff: Yes. Jared: But things have changed. The Agile world has come around and now it's different, right? Jeff: It is. You gave me a lot of little threads to pull on there. I want to grab onto a couple of them. Yes, now it's different. When I start talking about the Agile community and where it came from, I'll often make the point that a lot of Agile processes we use today; a lot of what we recognize as a common Agile process emerged from a bunch of people that were practicing software development in support of traditional IT work. They were working inside of environments where they were building software for large organizations, for that organization's internal use. These are environments where user experience people are scarce, so one of the things that the Agile people figured out -- or at least Agile developers figured out -- is that they worked in short iterations. If they developed a little bit of something, got it in front of people as quickly as possible and got feedback on it; then they would ultimately arrive at something better. In a way, when I look at Agile development, sometimes I see it as developers figuring out what iteration actually meant and figuring out that user experience practice. So that's one thing to pull at. Jared: Yes. Jeff: One of the problems that I've run into now as Agile development matures is that term 'iteration' gets thrown around. Agile people will use the term 'iteration', but they actually don't mean that. What they mean is incrementing. Basically, if I was building a wall and I was doing it incrementally; I'd add one brick at a time. If I was using iteration, I might stack up a bit of the wall and say, "Nah, that doesn't look right," then push it over and rebuild it. I find in a lot of Agile environments, they don't have a lot of tolerance for iterative development. Meaning they want to increment in development or add things a brick at a time, but the tolerance for rebuilding, redeveloping, reworking or trying something different in the code is fairly low. It ends up being an organizational thing. I probably lost the plot of your original question. Where I'm seeing user experience people work really well these days is to pull that iteration outside and up front in development. To actually use prototypes and get either paper, HTML prototypes or other low-ish fidelity ways of prototyping in front of users. Doing a lot of rapid iterations before it's handed off to the development people. Jared: So now, given that we're iterating a lot, one of the things that we're seeing is that it is; in fact, the user experience part of the process that is sometimes feeling like the bottleneck. Jeff: Yes. What's interesting, one of the things I heard -- I was jotting down little thoughts as you were talking -- strangely, I find a lot of user experience people... Being in this weird space where I've got both some user experience understanding, knowledge and process behind what I do, and Agile knowledge, I find myself in a lot of companies that are adopting Agile development and have user experience people. I find a lot of user experience people that aren't iterators at all. They prefer to go into a room and work alone, really quietly, and think really hard. They produce one pixel-perfect image of what the user experience ought to look like and behave like; without actually getting in front of anybody, without actually iterating. So I'm finding a lot of user experience people that need to relearn how to iterate. Then they need to learn how to do it faster. Jared: Yes, I think there is a real temptation, because of the speed, to think that what you have to do is cut out the user. Jeff: Yes. [laughs] Users always slow things down, I find. [laughter] Jeff: If you can work around users, it works best. I come up with the design much faster if I don't actually involve the people that have to use it. [laughs] Jared: That's right, that's right, yes. I think computers would be much better if we didn't have to actually have users. Jeff: Yes, I do too. That's been a problem. I think we've been trying to work this out incorrectly all the way around. [laughter] Jared: Right. That's right. [laughs] We keep trying to make the software for the user to use. We should just make the users work better. Jeff: Computer friendly. [laughs] Jared: That's right. [laughter] Jared: So all of a sudden, I was at the recent Usability Professional Association meeting. There were a lot of folks there who are now involved in Agile projects for the first time. They're really struggling with how fast the team wants to go. These guys want to have scrums that happen on a weekly basis. Somehow or other we're supposed to figure out the design, get it in front of users and get feedback by the end of the week. I don't know how we're going to do that. Jeff: Yes. I guess what I'm seeing as common practice. I find that a lot of UX people aren't given time. Or don't necessarily take the time, to do a little bit of pre-work. To design at a high level first; to maybe sketch the user experience such that they know in general what the application does and how navigation works. Have a bit of a framework to hang things on. So, sprinting starts. They start the application in the middle. They're asked to design these little bits of user interface without having this bigger context. So, they're struggling on both sides. They're struggling to see how this little bit of user interface design fits into a bigger context. They're struggling to get users involved; how to do that in a short amount of time. If you give some examples of people that have coped a little bit, they've figured out how to do it, the best people who are doing this--Heather that I know--Heather knows that she's got sprints that start every single week. She knows that she needs to get her user interface looked at. She builds a big stable of users that she can call and work with. She builds prototypes that she can share electronically. She gets in the habit of taking her stable of 50 or so users that she can call on; calling a couple of them every single week to review the user interface for the things that she's putting into the next sprint. She cycles through these people, so no one person gets called every single week. They get called every couple of months. So they're always happy to hear from her. They're always happy to see where the software has gone since they last talked to her. She refers to these people as her development partners. I end up seeing that same pattern repeated among a number of different companies. Basically they get ready to involve users and get in the habit of doing it. Another example is the folks at Google who were doing paper- prototyping. She explained putting together prototypes sitting in the Google cafeteria during lunchtime. Since they're doing consumer software the employees at Google are maybe reasonable proxies. They'll sit down at lunchtime and have a lot of users go through and validate the user interface there. So, the people who are working in an Agile environment--it's not a nice way to say it--but they suck it up and figure out a way to do it and make it fit in that short cycle. Jared: So, a lot of this has to do with, I think, minimizing those elements of the design process that probably are not giving that much value; focusing on just the core things that are really important. Making sure that you test with eight users so that you can get some sort of statistical validity is probably not what's really going to buy you as much as having just some one-on-one sessions with a handful of people that give you feedback and insights that you would otherwise not get. Jeff: Yes. I think that's correct. It's strange. I end up getting put into a lot of environments where user experience people insist on a certain amount of rigor. Often times the organizations around them opt to not include user experience at all. So, I end up seeing a choice being made of user experience done right with a certain amount of rigor, or none at all. It may be a bad trade-off. In short strokes, yes, we need to jettison or get rid of things that don't add value; and question the amount of rigor that we're giving things. Is this the amount of rigor that we need now? We know that we're designing just a little bit of user interface. It'll go in there with a little bit more user interface, and a lot more user interface. A lot of the design decisions that we make now for the little bit that we're testing to go into the next two-week sprint or two-week development timebox may be questioned or changed later on. How much rigor do we want to put into something? Jared: I think there is something to that. I've often wondered about the amount of rigor that people insist on, because that's not where the real value comes from. The real value doesn't come from being able to put up a report that says, "Six out of eight people were successful." The real value comes out of talking about the two people who weren't successful. What was it in their heads that caused them to think that this design worked one way when the design really worked another way. That's really where the value is, so you only have to talk to those two people. The other six people weren't that interesting. Jeff: I may be unique in this, but I find that my first few designs stink so bad that I don't need to put them in front of eight people to figure out what's wrong with them. I can put it in front of one or two people. I can grab a coworker and put it in front of them and realize how bad it stinks. Jared: I've often thought if we designed bridges the way that we design interfaces, we would first build the bridge. Then we would send a car across it. We'd watch it plummet into the depths below. Then we'd go, "Huh, maybe we didn't do it right. We should try again". Someone would raise their hand and say, "Well, that was only one car. We should see if we send eight cars across." Jeff: Exactly, it's not a big enough sample size. Jared: Exactly. I think that we get into that trap where we think, "Well, it's just one user. We shouldn't be paying attention." I think there are some problems, many problems; where just a single person will run into things where we'll go, "Yes, we need to fix that." Jeff: I find as a designer, and working with other teams of people who are designers; they get these permanent bruises on their forehead from slapping and saying, "What was I thinking?" Yes, we make some dumb or questionable design decisions that we want to reverse as soon as we see the first user start to work with it. In talking with a lot of people doing user experience work in Agile practices, I'm seeing the emergence of the RITE method: Rapid Iterative Testing and Evaluation. I think some usability professionals might question its rigor, because the idea behind that is; we'll run a person or two through a test. Discuss it, and make changes right away. Then run a next person or two. The idea is after testing eight or ten people, we've eliminated the number of large errors. But we might have changed the software in between every iteration. That's becoming a popular method, especially in Agile environments. Jared: Yes, the RITE method is--for people who don't know about it-- actually a very old technique, but it was termed RITE... I'm trying to remember what RITE stands for. Jeff: Rapid Iterative Testing and Evaluation. I rambled it out fast. Jared: Right. It comes out of Microsoft. They've been using it for a while now in a more formal setting. But it's basically about, you get a user, maybe a couple of users, put it in there, make changes, then try it again. Jeff: I was sitting at a workshop, actually, last week with someone from Nielson Norman group who knows one of the guys who wrote the original RITE paper. They wrote this when testing the Microsoft game Age of Empires. It was describing in early tests that people using the software couldn't figure out how to send their little men out and chop wood. If they couldn't chop wood, they couldn't build houses. If they couldn't build houses, they couldn't build a civilization and get further in the test. It didn't help them to design a test where they would have people doing all of these things. They would fail on the first task, and couldn't get any farther. There was a little bit of practicality in the reason they started doing things that way. Basically, people couldn't get through the test unless they figured out how to chop wood. They had to make design changes right away to help people learn how to chop wood, if that makes sense. Jared: Oh, yes. Jeff: It doesn't make sense to keep running through multiple subjects for something you know is bad user-interface design. Jared: Yes. That whole process is something we've been looking at for years with things like paper prototypes, where you just sketch something out on a paper. It gives you a chance to see what's going to happen. The whole point of usability testing is to be able to see the design through the eyes of the user. You can look at a design and it makes perfect sense to you. Then you ask the user to do something simple with it. They just stare at it. They say, "I don't understand what this means. I don't understand what these terms mean. I don't understand what this is trying to tell me." All of a sudden, once you have that conversation and you're hearing their reaction to the design as they're trying to work with it; you get a completely different viewpoint. It is like, "Oh, of course. If you didn't know that this was how this was connected, you wouldn't know that you need to click that button to make this work." Jeff: Yes, that's right. One of the things I jotted down as you were talking about innovating and getting in front of uses, is that not all designers or user practitioners believe that or see things quite that way. I've worked with-maybe I shouldn't name names-but I've worked with people from a very large, reputable design company that believes that the iteration happens within the design team who's done their research well; knows their users well and can place themselves in the users' shoes and they might, within the confines of that design team, iteratively discuss the design and walk through it themselves. Not necessarily put it in front of users. Jared, how often do you see that? If you look at designers that are in the iterating-with-users camp versus designers that are in the keep it away from users until it's fully gelled camp. Jared: I think there is some complexity that comes from putting things in front of users. But it really depends on the application, I think. It really depends on what you're building. The example that I like to use is the iPhone. Apple didn't do a tremendous amount of formalized usability testing on the iPhone. As far as I know, they didn't do any. They just built it and tried it themselves. Because they're all cell phone users and because they all experience that every day, it wasn't hard for them to build something to turned out to be a really slick interface; for the most part, worked very well. But, that's that design, right? That's that team with that design. If I was building something for a cell phone, I might be able to pull that off. But, if I was building, let's say, a system that's going to be used by pediatric ICU nurses ... Jeff: [laughs] Hey, why did you use that example? I'm just curious because that's one of the tougher systems that I've built. It was exactly that. Jared: Oh, that's funny. Jeff: Yes, and I've spent a little bit of time working in a pediatric intensive care unit, watching people work and watching people record daily records and just observing; watching doctors and nurse practitioners and people key in piles of data into electronic medical records as they're taking care of very sick infants. It's tough to imagine what their day is like. I can't put myself in their shoes. Jared: Exactly. The reason I picked it was because it's a project that we did fairly recently, too. So apparently we're both working in the same area. That's pretty funny. To our audience, we did not prepare that example. [laughs] That's just really funny. It's exactly that. When I got in there-and I don't know about the hospital you were working in-but the hospital I was working in had several different types of nurses. Some of whom had been in the department for 22 years and really knew the process. But then they also had nurses who rotated through different departments and weren't very familiar with the practices and daily routine. They would need different support from the systems than the people who'd been doing that for 22 years and knew every little intricacy of the system. Then we found that part of the thing was the way the shifts changed. There was a lot of information that was getting dropped. Jeff: Yes, I saw that. Jared: We wouldn't have picked that up. We would have thought that that was pretty much a standard process. The ICUs that we were looking at had been around for 25 years. You'd think they'd have that sort of practice nailed, but they didn't have it. Where we saw opportunities for technology support came from that switch. But the thing is, we weren't trained people so there was no way we could pick out what were the important key nuggets of information that need to move from one shift to the next. Jeff: Yes, exactly. I'm thinking back-it's been three-plus years ago since I engaged into this work. It was in the context of doing agile software development. Our agile customer/product-owner team was composed of me, a couple other people with usability experience and several nurse practitioners that formed our subject-matter expertise. Together we went out and watched people. They helped us interpret what we were seeing and explained what was going on. Because we built a bit of a product-owner key, we did have some subject-matter expertise in our group; we could evaluate user interface a bit. But we just weren't in the thick of things with these folks every day. It was very important to get feedback on the software we were building long before we delivered it to them. In this particular case, the one I'm thinking of since I don't want to fabricate history, we actually didn't have them look at prototypes. We actually had them look at finished software, every single development iteration; which was two weeks. So that we were getting feedback on the finished stuff. Jared: But even so, you were getting feedback every two weeks. That's the key thing. Jeff: That's right. Jared: The thing that I see is that part of it is getting feedback on the specific elements of the prototypes: Is this button working, or the flow is matching up. But part of what you learn every time you interact with a user, is: you learn a little bit about their life and their job and their experience. What it's like to be them; how what they do is different from what you do-even if you do those things in some other way yourself. That becomes valuable because it allows you to refine your gut sense, right? If before I go in and I watch users work with something and I say, "I bet they're going to have trouble here, but this part, they're going to find really easy." Then I find that I'm completely wrong on both counts. I know going forward not to trust my gut as much. Jeff: Yes. [laughs] It's interesting that the mark of a good designer is learning not to trust yourself. Basically, it takes a while to learn that you're not the user. Until you spend that fair bit of time with them, it's tough to trust your judgment about how they'll behave. Jared: Yes, I think that's absolutely true. So what are some tips that we can possibly pass on to folks who are looking to speed up their iteration process a little? Jeff: I'm thinking, the obvious ones and maybe they're not so obvious. I remember teaching a class many years ago at a UPA conference. Again, this was an agile class. I wanted to simulate an agile process. But we were going to paper prototype and we were going to do this in iterations and tests. I was at a conference that was filled with usability people. I said, "OK, how many people in the room are familiar with paper-prototyping?" All hands go up. "How many people in the room actually do paper-prototyping?" All hands go down except one. I find that it's actually getting back to those basics. It's actually getting back to pencil and sketching. Working with paper and working quickly. I've been a fan of the Caroline Snyder approach to paper-prototyping; which I think came from you guys for a little while. Jared: Yes, she worked for us for a long time. Jeff: That's right. So, my paper-prototypes tend to be not just sketched on paper, but sketched on little bits of paper and constructed; or built up in much the same way that I build software. I draw components and put double-sided tape on the backs of them--so that I can move those components around and play with the design of the user interface. It's not just with pencil and paper, but by moving these cut-out shapes around. So, the tips for me would be to start sketching sooner, to start sketching user interface in a way that's malleable. That's easy to change; to start vetting it with other people sooner. As we describe when we're talking about the difference between doing medical records in a pediatric intensive-care unit versus doing an iPhone, you'll find that it's easier to find proxy users in some instances and not in others. But I am a big fan of just getting it in front of somebody sooner, to get rid of my dumb mistakes. So, I don't mind finding someone else in my organization and explaining to them a little bit about who the user is and what they're trying to do. Then dropping a prototype in front of them and having them act as a proxy user and try to do something. They're not an ideal user, but they get rid of a lot of my dumb design mistakes. Jared: Are there things that folks can do up front as they're getting ready for the first round of iterations? Are there sort of iteration zero-type activities? Jeff: Yes. The term "iteration zero", "sprint zero", "something-zero" and a "starting cycle" is becoming common. Where I see Agile development go wrong, at least for user experience people; is if we start with sprint-one and a handful of user stories, or little bits of functionality to build. Where things go terribly wrong is if the user experience people weren't involved in the writing of those things. Weren't given any time to start sketching or thinking about how things look. Weren't given any time to understand who the users were, talk with them, meet them, or spend any face time observing them doing contextual inquiry things. The things that I would recommend to do to get ready would be all of those things. Usually a sprint-zero, or iteration-zero is a matter of a couple of weeks to a couple of months. It's important to get involved early, to be part of the product owner team, be part of the team that is actually making decisions about what to build and what to build first. How to chunk up the work that we intend to build; to help that product owner team understand who the users are, to schedule some face time with users, or at least leverage what you understand, common assumptions about the users, to construct some kind of user model. Then to start to sketch what the user experience looks like from end to end, and expect it to be wrong or dead-wrong. But I find that the activity of writing something like an end-to- end user scenario and sketching something like a storyboard that spans end to end; walking through it with other people that know the users, or with other people on the product ownership team, is valuable. It gets everybody on the same page as far as what the software is about; where we're going to go with it. We may not get that in front of users at this point, but at least it gets us all on the same page. Do that ahead of time. Then, when we actually start working with little bits of user interface in these sprints--I like prototyping as much as is necessary to let users sit down and go through a full task. So, it means that in early sprints you probably have to prototype or design more interface than is needed for those first sprints to make some good decisions. If you want to put things in front of users, they've got to be able to successfully complete what my friend Alistair Cobrin refers to as a "C-level task" or a "C-level use-case" in his terms; something that I would reasonably expect to sit down and do and complete in a single setting. Often times these little things that we put into Agile sprints or development timeboxes are smaller than that. So we need to prototype it at a little bit higher level. Jared: Yes, so that makes perfect sense: thinking about the bigger picture, figuring out what the user story should be; how they're going to connect for different parts of the development process as the Agile team starts to break things down into their smaller pieces, and implement the smaller piece. It's keeping the thread going along the larger experience and keeping it under control. Jeff: I find that UX people are really valuable in Agile environments. Often times in an Agile environment there is this group of people that steer. They're referred to as the product owner team or the customer team. Often times business people are placed in that role of steering, and these might be product managers in traditional product companies, or business stakeholders in IT-centered companies. They don't have practices or tactics that help them see that bigger picture. Often times developers don't either; so the user experience people help keep everybody on the same page. In the context of the one-day workshop that I'll be doing at UI XIII, I will talk a bit about what I refer to as "story-mapping". But it's a common practice that I've run into in a lot of other UX people that do this. It's basically taking these little bits of stories and arranging them into some sort of plot or large arc that lets us see the end-to-end user experience. The life cycle of someone using the software looks a little bit like this. We're working on this particular user story here. This is where it fits in this larger context. So, UX people can build these kinds of big maps that help people see where the work we're doing is now, and how it relates to the bigger picture. Jared: That's interesting, I hadn't thought of it that way. But a thought that just occurred to me is: when filmmakers create a feature film or even a short, they don't film the scenes in order. The scenes are filmed in an order that makes sense from a business setting: they can get this location cheap today if they do it today, but if they wait two weeks it's going to cost more, or it may not even be available. So, they have to do it right now even though this is somewhere in the middle of the movie. The actors haven't even done the beginning parts, so they don't know how their characters quite develop, but everybody has to get into place. They have these continuity people who make sure that if in scene 27 the actor gets a big gash on his forehead; that gash is there on every scene after; but not on every scene before. I could see to some extent that part of the role of user experience in an Agile space is that sort of continuity. Jeff: That's a fabulous metaphor, because that's what starts to happen in Agile development is we sometimes start doing this weird thing where we prioritize user stories by business value. We basically make some choices about what to build first. Sometimes we're like a movie director filming scenes out of sequence because those are the scenes that are technically tricky. We're filming this today because it's sunny today. We need the sun and it won't be sunny three months from now. In Agile development we end up building things, possibly out of order. But somebody has to keep the plot. [laughter] The UX people end up being the ones that kind of have the modeling techniques that help us keep that plot. Jared: Well, that's interesting. I had never considered that aspect of the user experience in an Agile world before. But that makes perfect sense to me. Jeff: I'm a fan of Indie Young's mental models. I end up building something that's a little like Indie's mental model because, you see, that mental model runs end to end, runs left to right. It walks through the space of a user as they go about meeting their goals. I built something sort of similar but I end up using those user stories to sort of construct that space. Then as we pluck off user stories we can say 'OK, this is about where we are'. As we look at one of these big wide story maps we can say 'OK, we've taken on this, this, and this and here's where our holes are, we still haven't hit this part of the user experience'. Jared: OK, well, that makes sense. So we've talked about a bunch of stuff here. Jeff: We have. Jared: We sort of talked about ways to speed up iteration. We've talked about ways to prepare for the first iterations - that sort of sprint zero type idea of getting things ready. We've talked a little bit about the role of rigor in the user experience process. We've talked about how in an agile project, probably more so than in any other type of development process; you get to play the role of continuity, which you don't really have to do when you're in a waterfall development process or something that's more grand scale. Because by the time you get the design, because you're working on the whole thing at once, you can always play it end to end. Jeff: Yes, that's right. In a waterfall process - and I don't think anybody works in a good, safe waterfall process - but, in ideal circumstances, you might be given the time and space to create a perfect design and then hand over that - back to our movie metaphor - hand over that screenplay and storyboard to someone else and let them screw up your movie. In an Agile world we're writing the screenplay and deciding what the scenes look like as we film. We don't have that safe space to do that. We have to be responsible for helping keep that continuity so that others who we're working with can understand. Jared: So, let's talk for a second about the User Interface 13 Conference. You're coming to Cambridge in October. Jeff: Yes. Jared: You're going to have a full day. We haven't covered everything here today have we? There's hours of more stuff you could talk about. Jeff: Yes, there's an awful lot more stuff to talk about. Jared: So what are some of the highlights of the other things you're going to talk about for people who are coming to this workshop? Jeff: I spend a lot of time talking at a lot of conferences talking to agile people teaching them about user experience stuff. I'll teach them how to build personas and to prototype user interface and to test that stuff. I'm making an assumption going into this that at your conference we've got a lot of user experience people. They may know all those basics. I want to teach them a bit more about their life in agile development. So we'll spend a fair bit of time talking about a national life cycle and their role in it as a member of the product owner team - the team that steers this development cycle; decides what to build and decides precisely how it looks and behaves. Their role on the team is validating that doing this continuous iterative validation of what we built, not only does it work well? Was it the right thing to build? Do we need to course correct and steer? In Agile development there's a mantra that agile people use a lot - they use the term 'business value' an awful lot. They talk about where the value comes from in something. When I look at user experience practice a lot, I see a lot of emphasis on users. We'll build something like a persona but we often don't build an equivalent model that helps us understand what the business is getting in return for building this software. Knowing what's most valuable about the software helps us understand what users are most critical and what kind of views are most critical in order to get the rear turn on investment from our software. So we'll talk a lot about that. Then, early in this conversation, I talked about this idea of understanding the big picture and I do that by using this agile user story thing but knitting those into a bigger end-to-end map, a story map. I want to a lot about what I'm observing and seeing as best practice for user experience practitioners in Agile development. So, we'll give some examples of that and talk quite a bit about that. Jared: I think that would be great because I think a lot of folks are coming into this - the people I've been talking to lately are either just starting or have been doing it for a little while. They feel like someone else should have figured all this out. Jeff: Yes. [laughter] Jared: So they want to know what mistakes have already been made so they could avoid them? Jeff: That's one of the things I was talking with a new friend of mine, Katherine Courage, who's at a company called SalesForce.com. I was asking her, in getting ready for this, "What should I talk about?" She says "There's a list of things I wish I had known before going into this". She gave me a couple of hers. She's come out the other end. It's been a year since they've been doing it. They've adapted very well and changed their practice an awful lot. I hope to talk a lot about those common pitfalls or common mistakes that people make. Jared: Excellent. Well, I think it's going to be a great seminar. For folks who are just getting into user experience, but are also having to work in an agile development, the rest of the User Interface 13 Conference has a lot of great stuff to cover all those things that Jeff said he's going to assume you know about. His session's on Wednesday and there's a whole set of full-day seminars on Monday. In particular, I'm thinking about [inaudible] session on usability testing, which we'll cover many of those things. You could take that on Monday. Then come to future talks on Tuesday. Then on Wednesday take Jeff's full-day session and come back with an entire spectrum of what you need to start doing to make this all work. Jeff: That's what I'd like to do is sort of fill in the gaps. Jared: Super, super. For those of you who have been paying attention, we've been talking with Jeff Patton. He's been talking here about the process of starting to increase the speed of your iterations when you move to an agile development process. He's going to be teaching a seminar called "Bringing User Center Design Practices To Agile Development Projects" at the User Interface 13 Conference. You can also check out his writing at AgileProductDesign.com. And thanks, Jeff. Jeff: Thank you, Jared. It's fun to talk to you always. Jared: OK. And thanks to everyone for listening and we'll talk to you next time. Thanks for encouraging our behavior. [music] Jared: Don't forget if you'd like to hear more from Jeff Patton, be sure to sign up for our user interface conference this October, 2008 in Cambridge, Massachusetts. Learn more at UIConf.com. That's all for this week; thanks for listening. Goodbye. [music]