Bummer! This is just a preview. You need to be signed in with a Pro account to view the entire video.
UX Track: Collaborative by Design - Teresa Rench41:20 with Teresa Rench
Teresa is a User Experience Designer with over 15 years of experience in strategy, visual design, interaction design, information architecture, usability, and front-end development. Due to her wide range of skills as a generalist, she is a strong “utility player”, enabling her to act as a hands-on lead for interdisciplinary teams and fill multiple roles as needed to best suit the team and project. Teresa has spent the majority of her career specializing in web-based applications and consulting with companies both large and small across a broad range of industries. She has more recently delved into cross-channel customer experience and service design. She currently works for Wells Fargo as a Customer Experience Lead
[Collaborative by Design - Teresa Rench] [Blend Conference 2013] 0:00 [Teresa Rench - Wells Fargo] Hi. >>[audience] Hi. 0:04 I'm Teresa Rench. 0:07 I'm on the customer experience team at Wells Fargo. 0:09 You're probably wondering what the heck I'm going to talk about today. 0:12 I don't think my description ever got posted on the website. 0:15 I'm actually really excited because there's been a whole lot of talk 0:18 the last couple days about collaboration. 0:23 We need to collaborate. Designers need to collaborate with developers. 0:26 But what I'm going to talk about is actually how to make that happen, 0:29 how to set up your teams in a way that they will communicate 0:33 and collaborate kind of naturally, organically. 0:37 A little bit of background about me. 0:43 I was trying to see how many pictures of my tongue 0:46 I could get other people to post on Facebook. 0:50 I only got 3. [laughter] 0:52 But I thought it was funny. 0:54 I've been in web design and development since around the mid '90s, so quite a while. 0:58 I've mostly done web-based applications, not as much websites. 1:03 I now act as a team lead and interaction designer at Wells Fargo. 1:08 But for the past 10 years I've been consulting. 1:14 I have been on lots of teams, many different situations— 1:18 remote teams, small teams, big teams— 1:22 in many different size companies, many different cultures. 1:26 So I've kind of over that time learned what works, at least a repeatable process. 1:29 There's lots of ways to get teams to collaborate, 1:38 and there's lots of information out there for it, 1:39 so I'm just going to share with you what I've found to work personally 1:41 and what I've found to be repeatable, no matter what the team structure or the culture is. 1:45 How many people in this room would consider themselves designers? 1:54 And how many developers? 1:59 Other roles? 2:03 A few people? Okay, great. 2:06 I want to step back just for a moment before we get into collaboration 2:08 and examine what is design? 2:11 >>[audience member] Making something. 2:16 Making something. That's great. 2:19 I think we often think of it in very simplistic terms. 2:22 We think of it as the look and feel of whatever we're creating. 2:25 We think of it as this interaction designer is creating these wireframes 2:30 and then this visual designer is coming and putting some color onto them, right? 2:33 But that's not very collaborative, is it? 2:37 There's no evolution between that one state and the next state. 2:41 I actually had a project manager many years ago who liked to give the analogy 2:44 that design was the paint on the car. 2:48 Interesting. Didn't necessarily agree with it, but that's what he liked to say. 2:51 I like to think of design as this. 2:59 It's not just what it looks and feels like, but it's how it works. 3:01 Whatever we happen to be building, it's actually how it works. 3:05 So for the car analogy, it's not just the paint. 3:08 It's the paint too, but it's also the instrument panel, it's the steering wheel, 3:12 it's the airbags, it's even the engine. It's everything about that car has been designed. 3:17 So what this means to me is that design is everything. 3:24 In software terms, it's not just our user interface, our graphics, 3:29 but it's also the back-end services and the infrastructure that supports what we're trying to create, the data. 3:34 Everything behind it is design. 3:39 That also means you are all designers. 3:44 Whatever your title may be, whatever your role, 3:46 you are all part of designing this larger project. 3:49 And I also like to say that the best ideas when we're solutioning 3:55 don't always come from someone with the term designer in their title. 3:59 They can come from anywhere. So we need to be open to that. 4:03 We need to collaborate with everyone on our team, not just our designers 4:06 and developers, for that matter. 4:09 How does this change how we all work together? 4:12 I'm sure you guys have seen this in a lot of presentations today, right? 4:16 Or even today and yesterday. 4:19 I'm not really talking about process so much here, 4:22 but this is kind of representative of a typical waterfall process. 4:24 But I've even seen Agile teams do this. 4:28 Basically we end up segregating ourselves. 4:31 And it's natural. We flock together with people that are like us. 4:33 It's much easier to communicate with people that speak the same language, right? 4:37 But even though it may seem easy at the time, it's very inefficient and painful. 4:44 Because what ends up happening, even if up front we are communicating in the design phases, 4:50 if we're not communicating also with the developers and the testers, 4:56 we're going to have a lot of gaps. 4:59 I can just tell you from personal experience how painful 5:01 hours and hours and hours of ambiguity meetings are 5:04 when we're trying to fill those gaps way too late in the process. 5:07 So I think we really need to work more like this. 5:14 Imagine the old Tetris game was a multiplayer game. 5:18 We're working together, so we have to pass the controller off at the right points in the game 5:22 to make sure that we fill in all the gaps as we build out our project and our solution. 5:27 This isn't easy, right? It's not easy to work this way. 5:38 It's not the way we're used to working, but it's really good. 5:40 I also wanted to point out we've been talking a lot the last couple days 5:42 about designers and developers collaborating, 5:47 but I also think we need to pull in our business folks and even our testers. 5:49 When you work with a really good QA team, 5:54 I think what you'll find is that they are super, uber detail oriented. 5:58 They're going to be able to help us to resolve any gaps right from the get-go 6:03 that we may not even have thought of. 6:07 So I'd really like to have them involved in the early stages as well. 6:10 The problem is we tend to when we say, "We want to get a collaborative team," 6:16 we throw a bunch of people together and we say, "Okay, go forth and collaborate." 6:20 But it's not that easy. 6:24 You can't just put a bunch of people together and say, "Hey, collaborate." 6:27 The problem is initially we don't speak the same language. 6:30 And I don't just mean that literally, 6:34 I just mean that even people in general, not even thinking about different disciplines, 6:37 when we first get together we don't know each other, we don't know how to communicate, 6:41 maybe we don't have the same sense of humor. 6:45 There's a lot of things that we need to learn about each other 6:47 before we can really communicate well. 6:49 We need to design a collaborative team. 6:54 We need to set out to set that team up for successful collaboration. 6:57 And to me, design is really creative problem solving, 7:03 and everything is a design problem. 7:06 And designing your team is just another design problem to solve. 7:08 Why is collaboration so important anyway? 7:14 To me, collaboration is the key to innovation. 7:19 We get the best ideas, the best products by building on the ideas of others. 7:23 A few others have talked about the genius or the rock star designer 7:29 that just wants to go off and do their own, but I really think that's extremely rare. 7:36 Maybe it happens, but for most of us, we need to be able to work together to create something really great. 7:38 It's kind of like improv, which would be much less fun if there's only one actor involved. 7:44 So how can we make that happen? 7:52 I've got a few steps I'll share with you or tips, if you will, 7:54 of things that I've seen really work. 7:57 They can work in this order, they can work in different orders, 8:00 but I think the first thing you need to do is start with the right team lead. 8:02 We definitely don't want a dictator. 8:10 A team lead is not someone that tells everybody else on the team what to do. 8:12 What we really need is a facilitator. 8:17 Your team lead should have, as our keynote spoke about this morning, those soft skills 8:21 to be able to work with other people, to be able to communicate well. 8:26 They should be a consensus seeker. 8:31 They will help bring that team together. 8:34 I also think that the best team leads are T-shaped. 8:40 Is anybody familiar with the term T-shaped? 8:45 We've talked about it during this conference as generalist or hybrids or unicorns. 8:49 But generally how I think of a T-shaped person is someone that has not just depth of skill in one area 8:56 like a specialist would but they also have breadth of skill. 9:03 And everyone's T can look a little different. 9:06 I may have multiple verticals of depth. 9:08 Maybe I'm really good at both interaction design and front-end development, for example. 9:11 I may have a different length of breadth depending on how many different things I've dived into. 9:16 But the point is that I have that breadth and that depth 9:23 and can be that translator for all those people who are speaking different languages. 9:27 And that's one of the things I'm really loving about this conference 9:31 is it's kind of helping to create more Ts in the world. 9:34 I know this is a really long quote to put on a slide, 9:40 but I thought it really got to heart of why Ts are so valuable as far as being a team lead. 9:42 Their empathy. 9:49 They create collaboration because they have so much empathy for their team members 9:51 that they're able to put themselves in their shoes. 9:56 They also tend to be enthusiastic about other people's positions, 9:59 and that's how they became a T shape in the first place— 10:04 they wanted to learn more about what other people on their team did and other disciplines. 10:06 And I think the more of these we can have on our team or to grow or develop on our team, 10:12 the more collaborative our team is going to be naturally 10:16 because of that empathy and that enthusiasm. 10:19 The next step, which we often neglect on teams, is spending a little time getting to know each other. 10:25 We get in a room and we start trying to solution right away. 10:32 We don't know how each other communicates, 10:35 we haven't spent any time together most of the time. 10:37 We need to facilitate this in some way. 10:44 It's really hard to make it happen naturally. 10:47 I believe the first thing that we need to do is colocate. 10:50 Get in a room together. Get in a space together. 10:53 I am a huge proponent of virtual teams working remotely. 10:58 But what I have seen is if the team can at least early on in ideation phases 11:03 get in the same room, it's super, super valuable for their communication and collaboration going forward, 11:08 even if later they need to be able to work remotely. 11:14 And I'll talk a little bit more about working with remote teams as well. 11:18 [water sloshing] 11:24 Sorry you have to listen to that. My mouth was getting a little dry. 11:26 [chuckling] 11:31 If you're sitting in the same room, a lot of things happen. 11:34 You get each other's body language, you get each other's facial expressions, 11:36 you start to learn about the personalities and the communication styles, the sense of humor. 11:40 I also believe that it's important to arrange the room 11:45 because what could happen in this situation is your front-end developers could all sit together 11:49 and your interaction designers could all sit together and your visual designers could all sit together, 11:53 and that's segregation, like we talked about before. 11:57 It's not going to facilitate that cross-disciplinary collaboration. 12:02 So I think it's good to be mindful and thoughtful about how the people in the room are arranged. 12:07 I see Victor laughing over there because he knows where this came from. 12:12 This is an actual chart we put together for a team. [laughing] 12:16 And we also actually like to move people around as necessary. 12:20 As we get into different phases of the project, 12:24 it may be necessary for me to put a visual designer next to a front-end developer—right, Vic?— 12:26 so that you can work through some solutions. 12:30 I've had people ask, "What if we can't get a room that we can all sit in?" 12:35 And that happens, right? 12:39 I think you need to be creative. 12:41 Tear down some cube walls, make a space somewhere where you are, 12:43 or even get out of the office. 12:48 Go to Starbucks. Go find a collaborative space somewhere else where you can get together and ideate. 12:50 The next thing we often don't do is we don't get personal— 13:00 at first, at least. 13:05 We don't talk about our families, our hobbies, our pets. 13:07 This is my dog, Gypsy. She's my furry child. 13:10 We don't get drinks after work. 13:16 Whatever it takes, we need to get a little personal and get to know each other 13:18 at a little bit of a personal level. 13:21 It doesn't have to be every day, all day. But hey, let's get to know each other. 13:23 By the way, if you want an explosion of cuteness, go check out DogsTiltingTheirHeads.com. 13:29 Totally cute. I've posted her picture up there because I just thought it was adorable. 13:35 But I'm her mom, so—you know. 13:39 The next thing, this is really the team's first opportunity to collaborate. 13:44 We want to set some ground rules. 13:50 How do we want to communicate with one another? 13:52 It shouldn't be the team lead coming in here with the stone tablets and, 13:55 "Here are your rules; you will follow these," because that won't be well received. 14:01 We need to be able to talk about it and discuss it and write it down on a whiteboard 14:04 and erase something and write something else and just come up with, 14:08 what are our rules of engagement for working together 14:11 in a way that we're all going to be happy? 14:14 These are just a few examples I threw up here, but I don't think there's a one size fits all. 14:17 I think every team is different, the dynamics of the team are different, 14:23 so it's really important for that team to work together to come up with their ground rules. 14:26 Tip or Step #3, whatever you want to call it, setting the team's focus. 14:36 I really think that this is one of the most important things you need to do. 14:41 It's something that you may need to return to often. 14:45 Refocus the team and get the team focused on the products, the problem we're trying to solve. 14:50 It's not about personal perspectives, personal opinions, 14:58 it's about we're trying to solve this problem together as a team. 15:02 And I like to also remember that our stakeholders or clients or business partners 15:09 are part of our team, and we should treat them like they're part of our team, 15:15 and we should try to understand their needs and their objectives 15:18 just as we would want to understand those of the others on our team. 15:21 So why are they paying for this thing? What's in it for them? 15:25 What's important about it to them? What is their vision? 15:29 A lot of times a client or a business partner will have a specific vision in their head, 15:33 and we can much better communicate with them if we understand what that is from the get-go. 15:37 We can speak their language. 15:42 Also, how are they going to measure success? 15:46 What does success look like to them? 15:49 As we come out of the end of this project, what do they want to see from it? What are they going to measure? 15:51 This will also help build trust with our clients, our stakeholders, 15:57 that we find their needs important, that we're thinking about what they want. 16:02 And of course, user experience people, we all like to concentrate on the customer. 16:09 And I don't think that this is any stretch, but I will say this: 16:13 we need to make sure we all have the same understanding of who the customer is. 16:16 Even often if we have all this great research, we have all this ethnographic research, 16:22 we have task models, we have personas, we have all of this data to support knowing who our customer is, 16:26 it's great for the team to just get together and talk about them. 16:33 Relate them. "Oh, that persona is kind of like my mom." 16:37 "That persona is kind of like my Aunt Debbie." 16:40 Try to as a team come to that shared understanding of who this customer is. 16:44 And also, it helps to make sure that the team remembers we're not designing for ourselves. 16:54 It's really hard to do that. 16:59 When you get into design phases you're thinking, "I wouldn't like that," or, "I wouldn't like this," 17:01 but it's not about you. It's about that end user. 17:05 We are never designing for ourselves. 17:08 So really, the solution we're seeking is at the intersection of what our client is willing to pay for, 17:13 what our customer is willing to buy or use, 17:21 and also what's feasible—what can we do given our timeline, 17:24 given our budget, given our constraints from a technical perspective—what's possible. 17:28 And having all of this focus will help us to set our sights on that center point, on that solution. 17:38 Our next real great opportunity to collaborate 17:47 is now that we have all this background and we know at least where the solution may lie, 17:50 we can start to work out our goals and principles as a team. 17:55 Was anybody in Garren's talk about Lean UX and Agile? 17:59 He talked about how his team returns to their design principles frequently 18:04 and they really use those to guide what they're creating. 18:09 So this is that step. 18:11 This is again your team getting together and saying, "Here are the principles, 18:15 here are the guidelines that we want to follow as we create our solution." 18:19 [chuckling] Vic recognizes this also. 18:24 This is just one example. This team decided to do a mission statement. 18:28 I highlighted a few of the goals throughout this mission statement. 18:32 But you wouldn't need to format it like this. 18:37 It's again—I'm going to say this a lot—no one size fits all. I truly believe that. 18:39 These processes need to be flexible. 18:45 They need to work for the team that we're working with. 18:48 Often we don't need to be this formal about it either. 18:55 We can draw it up on a whiteboard, we can erase parts, we can change it over time 18:58 if something is not working for us or we need to add something. 19:02 Also level of granularity. This is pretty high level, but maybe we want to go deeper than this. 19:05 Maybe we want some more specifics that we can measure against later. 19:10 But the point is that we keep it somewhere, we refer to it often, 19:15 we revise it as needed, and we objectively measure our products and our design by these guidelines. 19:18 This is just another example. 19:28 I guess Google has been using these for 10 years. 19:31 You can see that they're not really focused on a very specific solution. 19:34 They're at this higher level of what are their overall company's goals in general. 19:37 I highlighted the ones I liked. [laughing] 19:43 Finally we're getting to the point where we usually try to start, 19:53 and this is Step 5. 19:56 Spoiler alert: there are only 7. 19:58 We usually just throw people in and we say, "Go have ideas, go collaborate, go talk to each other." 20:00 I really think that the 4 things we talked about getting up this point 20:08 are vital in making this particular point a successful one. 20:13 We also tend to dive into—at least me, I'm an interaction designer primarily— 20:22 we tend to dive right into screens, and I think we need to start with stories. 20:28 Were any of you in Patrick Quattlebaum's workshop? 20:35 Yeah. So you got a little taste of low-fidelity story and ideation. 20:39 We're going to use these stories as we go along to focus us, 20:46 we understand what we're building, 20:50 we're creating stories about what our customer needs and about what we're going to build, 20:52 and we're also going to use those to validate our work 20:56 and to share our work with our stakeholders. 20:59 There are lots of ways to do this. 21:04 What's really important is that you don't have your people go sitting down at computers to do it 21:07 because that is not going to create a collaborative environment. 21:14 Everybody is going to get their heads down in front of their computer, 21:18 and this also leaves out the people who don't have Photoshop skills, 21:20 they don't have OmniGraffle skills, 21:25 they don't have whatever tool it is that your team is using. 21:26 This leaves them out. They can't ideate with the team if they don't have those skills. 21:29 So I like whiteboards, sticky notes, paper early in the design process in particular, 21:34 but you may need to return to this low-fidelity process repeatedly 21:43 to get out the ideas of the team. 21:47 I'll mention Garren again. We're good friends, by the way. 21:49 He also talked about how he likes his team to get the ideas out of their heads and up onto the walls. 21:54 And maybe you don't refer to them again, but at least they're out there 21:59 and everybody can see them and everybody can share them 22:02 and everybody can introduce their own ideas to the mixing pot. 22:04 And even if you don't ever return to that piece of paper on the wall again, 22:12 it's in there. 22:16 You're building on it whether you know it or not. 22:18 There's no original idea. Sorry. [laughing] 22:20 The stories, because we are going to continue to refer to them, 22:30 it's often good to document them and keep them around, be able to show them to our stakeholders 22:33 because as we show them our solutions, we want to refer to, "This is the story we're building the solution against." 22:39 And again, there's lots of ways to do this. No one size fits all. 22:45 These are some examples of journey mapping, 22:48 blueprinting, which I know you guys talked about in Patrick's presentation. 22:50 This is really a funny, whimsical, almost like a scenario, I guess I would call it, 22:55 just walking through the customer's feelings and emotions. Really cute. 23:01 But the important thing is, at least in the early ideation phases with our collaborative team, 23:10 we need to stay low-fidelity until all the ideas get out on the table to start with. 23:15 I should also mention we shouldn't just ideate against screens— 23:27 I've got a couple of example screens up here—but we should also be looking at information architecture, 23:32 system diagrams even, working with our developers to understand 23:37 what does the system look like that's going to support the solution we're trying to build. 23:43 We can start doing that early, before we've even drawn any screens. 23:48 Is anybody familiar with this book, Gamestorming? 23:55 It's awesome. I love it. I give it away at Christmas. 23:59 To coworkers, of course, not like my family. They would have no idea what it is. [laughter] 24:03 There's a short section in the front that talks about some basic brainstorming ideas— 24:10 how to get people brainstorming, the diverge and converge methodologies. 24:17 So that's great, but what I really love about it is it has page after page after page 24:23 of all of these low-fidelity methods that you can use to do collaborative ideation 24:27 and pulling in all your business people, all your designers, developers, 24:33 everybody getting involved in that process. 24:37 So it's really great for that. 24:40 I go through and I just mark all the ones that I want to save for later. 24:42 I'm like, "Ooh, this would be really good for that," and, "Ooh, that would be really good for that." 24:44 So if you see my book—I should have brought it just to show you— 24:47 it's got all these little sticky note flags sticking out of it. 24:49 Daily, daily, daily working sessions. 24:57 I expected to hear some groans, but I see a face over there. [laughing] 25:01 Meetings are evil. I agree. This is not a meeting. 25:07 And I have to say this is the number 1 most effective thing I've seen to get teams collaborating. 25:13 Have a set time every day when we get together. 25:21 So that room we're in, maybe we're in there all the time, which is great, 25:23 but that doesn't mean we're collaborating all the time, even if we're in the same room. 25:26 We might stick our heads in our monitors and go away and we don't talk. 25:30 So we need to set a time where we put our heads together. 25:33 This is not a morning standup like Scrum, not at all. 25:36 To me, this is a working session. This is where we share our ideas. 25:39 This is where we share what we've been working on, where we get feedback and critique. 25:43 Whoa, what happened? Sorry. 25:52 I pressed it too hard or something. 25:55 Uh-oh. 26:01 PowerPoint has crashed. That's shocking! [laughter] 26:03 They didn't put Keynote on this machine. 26:08 Otherwise I would have used that. 26:11 [laughing] 26:22 Okay. 26:26 Okay. Back where we were. 26:31 Where were we? We were like on Step 6. 26:38 Am I talking too fast? 26:43 Okay. 26:49 I've done these daily sessions in many different ways, 26:52 just playing with what's worked with different teams. 26:56 And basically there's 2 flavors. 27:00 There's a very structured session and then there's a very unstructured session. 27:04 I personally like unstructured best. 27:08 I like it just to feel like the family is all getting together 27:11 and talking about whatever the point of the day is. 27:14 But sometimes the structure is needed 27:21 because particularly if you're in a situation with a brand new team 27:25 that's never worked together, it helps you to define your roles and responsibilities. 27:29 Like what are you coming to these daily sessions with? 27:34 What are the expectations? 27:36 What are you going to do before to prep for this? 27:37 What are you going to do during it? What is your output after it? 27:40 This piece right here is like half a page of a 7-page document 27:44 that I had to create for a client who they wanted me to come in and lead this team, 27:50 and they wanted to know how I was going to get this team to work together 27:55 and what was the process, what was going to be our inputs and outputs to this process, 27:57 which was actually a really kind of cool exercise. 28:03 I know that sounds geeky, but I've been called a process geek. 28:06 But it was just neat to really think about what would we need to support the daily working sessions 28:10 and also reviews with our stakeholders and customers on this. 28:17 I like unstructured. 28:27 You can't always do it from the get-go, particularly depending on your team, and it's all about your team dynamics. 28:29 But once your team is really gelling well, you don't need a lot of structure to these sessions. 28:33 It almost becomes like this, where everybody is really eager to share their work 28:38 and get feedback from the rest of the team. 28:43 And participation is uber important. 28:47 A lot of times when you have a cross-disciplinary team in these sessions, 28:51 like my content strategist won't think she should say anything about the visual design 28:56 because she's not a visual designer, 29:00 as a team lead what I'll try to do is draw those people out. 29:02 Everybody has an opinion. Everybody should have an equal voice. 29:05 And just because that's not your particular area of expertise 29:09 doesn't mean you shouldn't, as part of the team, be able to voice your opinions. 29:13 And also, introverts—my content strategists are often my introverts— 29:21 making sure that those people aren't left out too. 29:27 Some of us extroverts stick our opinions in there. 29:31 I always say I'm full of opinions and I'm not afraid to share them. 29:34 I promised I would talk a little bit about remote team members. 29:41 It is vital that you get together face-to-face up front 29:46 and then periodically at key points in your development design process. 29:53 I actually years ago was on a team where I was in Indianapolis, 29:59 I had team members in Boston, New York, California, Amsterdam, and St. Petersburg, Russia. 30:04 I needed to be able to collaborate with these folks. 30:12 I worked with them over the phone initially for a while, 30:14 which didn't go poorly but we didn't have as good a rapport as after we got together. 30:17 We actually got together in one place about quarterly, 30:22 which is a big deal for people from all those different places. 30:25 My first face-to-face meeting with any of my teammates was in the Boston airport 30:29 on the way to St. Petersburg, Russia. [laughing] 30:34 It was a little bit nerve-racking. 30:38 After I met all these people face-to-face and kind of understood them, 30:39 it was so much easier for us to be able to collaborate virtually after the fact. 30:43 And what you're seeing here now is a map of my current situation. 30:48 A bunch of us are here in Charlotte, designers and developers, 30:52 we've got a designer up in New York, we've got some designers and developers in St. Louis, 30:56 we've got a BA down in Texas, we've got some developers and business folks 31:00 and all kinds of stuff out in California, and we've got some developers and testers out in India. 31:05 We don't all collaborate all the time, but we do need to be mindful of these folks. 31:10 Our daily sessions are even more important. 31:16 We're doing them virtually. 31:17 We do them as screen shares and Spiderphones and whatever. 31:19 But they're not in the room with us. 31:23 They're not talking to us, they're not getting that instant communication 31:26 that happens naturally when we're in the same space. 31:29 So it's super important that we have these daily sessions to include them. 31:31 It ensures that communication is happening even though they're not in the same space with us. 31:35 You can also take pictures of whiteboards and share those via email if that's the only method. 31:42 You've got to get creative. 31:46 If you don't have all the proper tools to do video chats or whatever, 31:48 you've got to find what else you can use that works— 31:53 Skype, whatever. 31:55 My last tip, number 7 and certainly not the least important, 32:02 is how do you present teamwork? 32:06 Remember, we want to include our stakeholders as part of our team. 32:11 Our clients are part of our team. 32:15 We want to treat them like they're part of our team. 32:17 We want to listen to and respond to them as if they're part of the team. 32:19 And we want to make sure we're sharing those goals and principles 32:24 and stories that we created up front with our stakeholders 32:27 so that they have that shared understanding with us. 32:30 And we want to speak their language. 32:33 So we learn what their goals are, what their needs are. 32:35 When we're presenting our solution back to them, 32:38 we want to make sure we're using those words to them, 32:41 explaining how our solution meets their needs. 32:43 And throw the word I out of your language. 32:48 Try never, if you're presenting— 32:52 I often end up presenting for my teams. 32:54 I try never to say I. Say we. 32:57 "We thought this. We decided this." We, we, we. 33:01 It's hard to do, especially if the idea was predominantly yours, 33:05 which I don't really believe in, but you kind of have that notion in your head or that feeling. 33:10 It's kind of hard to do. 33:14 It's okay to give credit. 33:16 If my visual designer had some particularly brilliant idea, 33:18 I want to call them out if I'm presenting in particular 33:21 because my stakeholders will hear that and remember that this isn't a single person's solution, 33:23 this is a whole team working on this thing. 33:30 But never blame, ever. 33:32 Even if it is somebody's fault, it doesn't matter. 33:35 If your client is saying, "I hate the way this, this, and this was done," 33:37 don't say, "Oh yeah, that was so-and-so." 33:41 That's not going to be good for your team. That is going to destroy trust. 33:43 Just never, ever do it. 33:46 Not saying I and not taking that ownership as a team lead 33:49 really helps to strengthen the individual's feelings of contribution on your team. 33:54 They feel like, "Hey, this is going to be presented as my work as well as everybody else's work." 33:59 [chuckling] I thought this was really cute. This was somebody's logo idea. 34:08 Switch presenters. 34:11 Again, particularly if you're in the situation which we often are 34:14 where our stakeholders are over in California for the most part 34:19 and they don't see us face-to-face, they don't know that I'm sitting in a room 34:22 with a whole team of other people while I'm presenting. 34:25 So it's often good to switch presenters. 34:28 And this can be done in many ways. 34:30 Often we just have somebody that's sort of the main presenter 34:33 and then other people chime in or are called on to chime in on particular pieces. 34:35 So that's one way. 34:39 Or you may decide, "This is mostly going to be a visual design presentation, 34:40 so I'm going to let my visual designer do the presentation this particular review." 34:45 But some people don't like to present. 34:52 I think it's okay not to make everybody on your team— 34:55 I wouldn't make everybody on your team present. 34:59 If they're not comfortable presenting, don't make them do it. 35:01 I try to make my team members who aren't comfortable 35:03 at least help them to chime in here and there. 35:07 "Hey, would you mind saying something about this piece of work that you did on X." 35:09 And then it's a little less daunting than, "Hey, you're going to present this work to our client." 35:13 Speak with one voice. 35:22 This tends to happen naturally. 35:24 Once you've set this team up to collaborate and you're talking to your client 35:26 and you've been talking to each other so much and you've really gelled, 35:30 you don't really need to force this. It just kind of happens. 35:34 You'll be presenting something to your client 35:37 and you don't even need to prepare who is going to talk about what. 35:40 You just sort of all chime in where you should, naturally. 35:43 It's pretty beautiful when it happens, I have to say. 35:48 Another point about this is you don't want to disagree with each other 35:55 about the solution you're presenting in front of your stakeholders. 35:57 So hopefully you all agreed and came to consensus before you presented the solution 36:00 because that's not a good thing either. 36:05 Also, when receiving feedback, it's kind of a natural to respond to it immediately. 36:07 Like somebody is saying, "I don't like the way this little thing works," 36:13 or, "I don't like the content you have there," or whatever. 36:16 It's kind of easy when you're presenting to go, "Oh yeah, we should look at blah, blah, blah," 36:19 and coming up with a solution right then and there. 36:22 But the problem with that is that doesn't include the rest of your team. 36:25 You haven't come to consensus about that response. 36:27 So what I try to do—and again, this is another hard thing to do— 36:30 is just take it all in, write it down, keep track of all the feedback that's coming from my stakeholders. 36:33 And then as a team, after the presentation we get back together, 36:39 we discuss all the feedback, and we decide as a team how we're going to respond to it. 36:44 And this is just another trust-building thing, 36:50 another feeling of, "Hey, my opinion is going to be heard," on whatever the point is. 36:53 And it proves as well to the stakeholders that you do make decisions as a team 37:00 and that you're a well-oiled machine. 37:04 Given all of that, what can go wrong? 37:09 There's lots of things that can go wrong. 37:11 I'm not going to even try to get into everything that can go wrong or that I've seen go wrong, 37:13 but I'm going to talk about a couple of them. 37:17 I know we're getting short on time here. 37:19 First is difficult team members. 37:21 There can be people who are sensitive to criticism, which is really hard when you're collaborating. 37:25 They don't like their designs picked apart or however they want to put it. 37:29 Dictators, people who want to tell everybody what to do. 37:34 Their idea is the only right idea. 37:38 Order takers are just as bad, people who want to be told what to do. 37:41 They don't want to participate in ideation. 37:44 But the thorniest issue for me with difficult team members has been those that are very territorial. 37:46 That's why I picked— I love dogs. 37:57 I picked one who is being territorial over his bone. 37:59 They don't want to share their ideas or they don't want people to evolve their ideas. 38:02 It's very hard to deal with on a collaborative team, 38:07 and it's disruptive to the collaboration of the team. 38:11 So as a team lead what I would try to do is talk to them, 38:14 see is there anything with those rules of engagement we set up early on that we might need to change 38:18 to make them feel like they can participate and be part of the team and share their ideas. 38:23 Are there trust issues there? Are they afraid I'm going to take their ideas and go present them as my own? 38:27 What is the issue? I'll try to resolve that. 38:34 But the fact of the matter is some people just don't like to collaborate. 38:37 They want to be the star. They want their name in lights. 38:41 They don't want it to be a team effort. 38:45 Honestly, I find most often that those people self-select their removal. 38:47 They go away eventually because it's so painful for them 38:54 to be involved with this collaborative team where everybody else is getting along great 38:57 that they end up removing themselves from the situation. 39:00 The second biggest thing I find is difficulties coming to consensus. 39:07 We all have different opinions. Some of them are strong. 39:11 We might disagree about things. 39:15 When this happens I find the first thing I want to do is return to our goals and principles, 39:17 see if there's anything in there that can help us make a decision, 39:23 or return to the stories as well. 39:27 Is there anything in there that's going to help us make a decision? 39:30 Sometimes people would appoint a third party decision maker, 39:33 maybe have the stakeholder decide. 39:36 That can work, but I don't really like it because I don't think it resolves 39:39 that discomfort on the team that they didn't agree. 39:41 It's like somebody won and somebody lost, 39:44 and that's not, I don't think, the best way to handle it. 39:46 Another way you can do it is do user testing. 39:49 If you have a couple of ideas that are both strong ideas, you can't come to consensus, test them with the users. 39:51 That's still a third party deciding, but because it's the end user it doesn't feel quite so painful. 39:56 It's still not ideal, in my opinion, because I think the most likely reason 40:01 the team can't come to consensus is because they haven't found the best solution yet. 40:06 So what I like to do in that situation is return to the collaborative ideation phase. 40:11 Low-fidelity. Let's get some more ideas out on the board and see if there's one that we can all say yes to. 40:17 Just to bring it all back together, start with the right team lead— 40:26 facilitator, not a dictator, someone with soft skills. 40:29 Get to know each other, both personally and professionally. 40:33 Get in a room together. 40:36 Set the focus. 40:38 Make sure your team is focused on the product that you're trying to deliver, 40:40 not on personal opinions or perspectives. 40:43 Agree on your goals and principles. Collaborate on your goals and principles. 40:46 Change them as needed. 40:49 Start with low-fi ideation including storytelling. Very, very important. 40:52 Get everybody's ideas on the table. 40:57 Return to this number 5 as needed. 41:00 And then daily working sessions that everybody groans at. 41:03 But trust me, try it. [laughing] 41:06 And present your work as a team. Make sure you're all speaking in one voice. 41:09 Thank you. 41:13 [applause] 41:15
You need to sign up for Treehouse in order to download course files.Sign up