Bummer! This is just a preview. You need to be signed in with a Pro account to view the entire video.
How to Design Things that Make Sense30:11 with Johanna Kollman
In this talk, Johanna will introduce you to concepts and practical modeling tools from the fields of information architecture, lean management, and systems thinking. We will discuss how to turn research data into insights, how to make sure that everybody in the team is on the same page, and how to design things that make sense.
Good afternoon everybody. 0:07 Thanks for choosing to spend the next half hour with me. 0:08 And I'm gonna talk about, how to figure things out. 0:12 How to make sense and, in my professional life there's kind of 0:17 three times when I have to figure things out. 0:20 Firstly, it's making sense of data. 0:25 That can be quantitative data but in my case it's often qualitative information. 0:28 I go out, I observe people. 0:33 And I have to figure out from what I see, what does it mean and 0:36 how does it actually matter. 0:40 Secondly most of us these days work in teams and we have to figure out 0:43 together are we on the [NOISE] thanks for kicking over my timer. 0:48 [LAUGH] It still works. 0:53 No troubles. 0:57 [LAUGH] So we have to figure out together. 0:58 Are we mean, are we meaning the same things? 1:02 Are we agreed on the vision? 1:05 Have we agreed how to build whatever we're building? 1:06 And then thirdly, it's actually designing things that make sense. 1:10 Cuz even if we understand our customers, we work really well as a team, 1:14 we can still make mistakes and think this makes a lot of sense, 1:18 put it in somebody's hands and realize it's not as intuitive as we were hoping. 1:21 So I'm gonna share some of the tools and the concepts that helped me. 1:26 It's really things that shape my practice, that shape my thinking. 1:31 [NOISE] So first let me start with talking a bit about research. 1:38 I do various things in my current job, my current job title is Product Architect. 1:43 Yeah, my, my, it's kind of made up. 1:47 But one of my roles is to go out and 1:50 either observe something that people are already using, it can be competitors or 1:53 it can be their existing workflow, if we're introducing new products to them. 1:58 And see how they're we getting on. 2:03 Sometimes it can be taking a prototype, taking a concept that we are working on, 2:05 put it in front people. 2:10 Now, whenever I do research I always try to combine just interviewing people but 2:12 also showing them something at the same time. 2:18 And whenever possible I love to go out and 2:21 actually do this in their context to see what devices are they're actually using. 2:23 What are their, what are their browsers of choice, what are the tools around them, 2:29 do they still use other things that I wouldn't have considered. 2:32 And if somebody uses their own machine or 2:35 you're at their desk in their office, that's something that's really, 2:38 really good to see that wouldn't get otherwise if you only use Ability Lab. 2:41 Now I currently work with a client in healthcare. 2:45 And in this case it's very hard to get people into a lab. 2:48 You know, if you wanna see what's going on in a hospital you have to go and 2:51 you just have to be flexible and 2:55 whenever somebody has time you have to be ready to talk to them now. 2:56 This also makes it very hard to take my team with me. 3:00 Cuz it's hard often to get into these places just as one person that's not 3:03 allowed to, you know, record anything or take any pictures. 3:07 You're just relying on your notes. 3:10 And I thought this experience that when you are presenting things to people or 3:13 you're watching them use something, 3:16 you can get very tactical insights really quickly. 3:18 And people who start bringing research to an organization who has maybe relied on 3:21 quantitative data about their customers, they often have quick wins. 3:25 Just with calling and saying, look, 3:29 there's a few small changes we can make that will make everything more usable. 3:31 So this is a good strategy of getting by in. 3:36 But very often when you are out talking to people. 3:39 You observe these kind of bigger issues that are going on and 3:41 sometimes it's not that easy to fix. 3:45 Sometimes the way that your product is set up and 3:47 that can go all the way down to your back end of your data structure. 3:49 Maybe there's just some fundamental concepts that are clear to you and 3:53 your organization but people just don't really get it. 3:56 And a great tool to actually get that across, especially if you and 4:00 your team are out there, but not everybody has the great insight. 4:04 And to actually battle for these bigger changes that can be quite hard, 4:08 because sometimes you have to remove things and 4:11 take your product apart a bit, is a tool called the Mental model. 4:13 So, I don't know if you've heard about it. 4:18 But, Indi Young wrote a really great book on the topic, 4:20 published by Rosenfeld Media, that is, 4:23 you know, in all details explaining to you how to do this technique. 4:25 But the concept, the term mental model has been around before Indi used it for 4:29 user experiences. 4:33 And the Mental model is, it's an explanation of somebody's thought process, 4:35 about how something works in the world. 4:39 And it's a representation of the surrounding world. 4:43 Or the relationships between it and the rarest parts in it. 4:46 And a person's intuitive perception about the impact that his or 4:51 her own act, actions will have. 4:55 And the word intuitive is really, really important here. 4:58 If we weren't able to categorize the world and build up models in our heads about how 5:01 something works, we would suffer from cognitive overload all the time, and 5:05 wouldn't be able to make decisions, or solve problems at all. 5:09 So Mental models can really help shape behavior and 5:15 be set an approach to solving problems and to doing tasks. 5:18 So, it's important to see what are existing mental models people have. 5:23 These can be based on competitor products, 5:26 on their training that they've received, on existing best practices out there. 5:29 And sometimes you want to design for this Mental model. 5:33 However, sometimes you want to get people, help people form a new mental model, 5:37 break with what they know and give them something different, something better. 5:42 This is how it normally works when you put a mental model together, writing a lot of 5:47 post-its and jotting down what's the task that people actually do? 5:52 What's their work flow? 5:57 What's their decision process? 5:58 How are they going about things? 6:00 And you know then what's happening. 6:02 But a really important thing is to pay attention to, what are people's own words? 6:04 How are they describing what they're doing? 6:09 Because it's really the language that people use that often expresses the model 6:11 that they have in their heads, and that can differ quite a lot 6:15 from the product that you have in your head and the language that you are using. 6:18 And this is great to do with everybody who goes out and does research but I 6:22 think also involving customer support with sales people is a really great idea here. 6:25 So in the healthcare sector, the sales guys that I'm working with are all trained 6:30 healthcare professionals and they can tell me a lot about my assumptions about 6:34 why are people deserving, like why are they doing this in a certain way. 6:37 What's going on here? 6:41 They're always choosing this one approach. 6:42 And they can tell me, oh, because that's how you train in med school. 6:43 That's what it is, and I wouldn't have an idea about that. 6:46 Deliverables of mental models, deliverables, like, 6:50 models, look like this, sometimes. 6:53 Here's another one. 6:56 And here's another one. 6:59 What all of them have in common as you can see here. 7:00 It's basically mapping out the tasks and 7:03 this can be tasks where your product is being used. 7:05 But it can also be before and after. 7:08 And the green part is all the actions that people take. 7:11 What they say. 7:14 What problems they have and their language about it. 7:16 And then the blue parts here is mapping your product against it and seeing what's 7:19 the language we use, what are the features we are providing or we want to provide. 7:24 And you can also spot gaps in here. 7:28 So I find it quite useful as an exercise to do with people to stimulate these 7:31 discussions about what are the bigger things that are going on and 7:36 making sense of these deep problems. 7:38 That sometimes require much bigger changes in 7:41 a product than you were willing to make in the beginning. 7:43 And it's really about figuring out, why are people doing something. 7:48 And helping you figure out what to do next. 7:52 So I found this is a good technique to help everybody agree on these kind of 7:56 bigger issues, and 8:00 as a person going out and getting feedback from customers has helped me to, 8:01 just over a period of time that I am lucky to spend with the same group of users. 8:05 To just understand is there any big mismatch between what 8:10 they have in their heads and how we've designed, how we've structured everything. 8:15 So that's one of the things where I feel I have to make sense of things I see and 8:21 share it with others, and align, 8:25 and this is one of the tools that I found really useful. 8:27 Secondly, I've been lucky in the last few years to mainly work on new products. 8:32 Something that hasn't existed before. 8:38 And I've been lucky to always work in teams that have all the skills we 8:41 needed and this is when I realized I love working with back end developers. 8:44 And I love working with data things and 8:49 especially when it's, how are we gonna get the data? 8:51 How's it gonna look in the database? 8:54 How are we gonna structure it? 8:55 How are we gonna collect it, where are we getting it from? 8:57 And then how do I re-jiggle it, to actually present it to users, and 8:59 with the intent of what we want them to take away. 9:05 I completely love that process, and I was like ignoring some of 9:08 the nice front end decisions, and like oh back end guys, let's do this together. 9:11 So I really loved that, but 9:15 I was lucky that I was there when these fundamental decisions were being made. 9:16 I worked their large Telco before, 9:21 and a lot of back end decisions had been made ages ago and 9:23 when we were coming in it was like oh, not possible, not possible, not possible. 9:27 Takes too much rework. 9:31 So that was such a shame, such a missed opportunity. 9:33 Because we might know about people's Mental Models and the ones that they 9:37 existingly have, but often there's a big gap between the Mental Model, and 9:41 the model that we've decided our system to have, our data to have. 9:45 And this maybe sounds like it was the old and dark days where we all had to 9:48 understand technology like very properly to be able to use anything. 9:54 But there are a lot of people out there who still suffer from the System Model 9:58 being exposed on the interface layer, 10:02 preventing them from really building up an understanding about how that works. 10:05 An example is often enterprise software business to business solutions. 10:09 So this is, I worked on a financial services project earlier this year and 10:14 I was going out and observing people using what 10:18 they're using right now to help us build up a strategy of what we wanted to build. 10:22 And this is a screenshot of one of the services. 10:26 It's not, yeah. 10:29 It's not that great to see it here but 10:30 it gives you an idea of this software doesn't look very great. 10:32 But people had lots of issues with this because it 10:36 just didn't match their expectations from how they were using the web. 10:39 So for example when you were logging in it didn't show you your information that you 10:43 wanted to see and for a lot of people that wasn't very much. 10:47 You had to search. 10:50 People like, I don't really know what to search for. 10:51 Now back in the olden days, 10:54 performing an empty search often tricks the database to turn, return all results. 10:55 A few people had figured that out and 11:00 were so happy, but others really struggled to even get started with the system. 11:02 There were a few other things like, 11:07 to get your account details, you couldn't just get your account details. 11:08 You had to run a report. 11:12 For every single thing, you had to run a report, 11:14 which makes sense, because that's how things were built to work at the back end. 11:16 But a lot of these people are very young administrators who use technology in 11:21 a very different way. 11:26 And they just completely lacked these mental models about how to 11:27 trick an older system into giving them what they wanted. 11:30 And to bridge these two, there's a way of doing that and 11:36 it's called a Conceptual Model. 11:41 So a Conceptual Model is really an expression of what we 11:43 want users to be able to do with our product. 11:47 And it can be quite abstract. 11:51 It's basically deciding, what are all the things that we want people to do. 11:52 What are the tasks we want them to do, what are all the entities? 11:58 What are the elements, the objects in there, and how can I interact with them? 12:01 And you could say that if you write up a backlog, 12:05 if you write a list of features, this can be a conceptual model. 12:08 But I think we have to go a bit further of defining this together. 12:13 Because conceptual models will matter in the future. 12:19 Right now it's fairly easy to have an understanding about how your house works. 12:23 If the electricity goes out, I know exactly how to fix it. 12:27 But if you're thinking about the future of connected homes. 12:31 The mental models we have right now about how our house, 12:34 how our house works, will be very, very different going forward. 12:37 And if everything's connected, 12:41 connected to servers talking to the internet talking to our phones, 12:43 if something breaks we have to figure out how to fix it as users of this technology. 12:46 So I think while we don't, not many of us work on enterprise software and 12:52 like these dark days of designing things, but this is a new frontier for me. 12:56 And I think this is almost the next one we have, where we have to make 13:00 sure we are teaching people correctly about how everything works. 13:04 And this is when the conceptual model I think, is really important. 13:10 The banking software that I showed you. 13:14 A lot of users said, only knew how to do things in one way. 13:16 And they were not clicking anywhere else. 13:20 They had what we call, procedural knowledge. 13:23 So if you are going to a city where your friend lives, and you've never been there, 13:25 but you know how to get to their house, you will probably just walk the one way, 13:29 because if you turn a corner you might even be lost. 13:33 You don't really know what's going on. 13:35 However, if you have a concept of how the city's structured, 13:38 maybe it as landmarks or river that helps you sort out where you are. 13:40 If you know where north and south, west and 13:44 east is, you have something called survey knowledge. 13:46 And when you have survey knowledge, you're more likely to explore but you understand, 13:48 in this case, how a city's connected and where you have to walk to get somewhere, 13:52 approximately, and you can figure it out. 13:56 And the conceptual mode is really about giving the people 13:58 the survey knowledge to help them understand how something works. 14:01 And with new things like this or even just, you know, it can be mind 14:06 boggling that something actually works on your, on a website in your browser. 14:10 But you can also have a mobile phone if everything talks to each other. 14:15 There's so many things that we are working on now that are like already taken 14:18 for granted. 14:21 But it's our job to help people really understand those. 14:22 Now when collaborating together on defining things early on, as I mentioned, 14:27 I was very lucky to work with a great team that every, we had all the kind of 14:32 business design and tech skills that we needed to form something new. 14:37 But it's still often hard to then agree what we're gonna build together. 14:42 A lot of the start up teams that I've mentored, 14:47 one of the fun things that you get to do. 14:50 You get invited to meetings, but you don't have to do anything. 14:52 You just have to observe. 14:54 And I've often seen them jumping back and forth between, 14:57 you know, what's our current product and what we want to fix in the short term, but 15:00 here's the bigger roadmap, and here's all the things that are broken. 15:04 You know, seven, eight people looking at visual designs, but 15:07 discussing everything from all different layers across what makes up the product. 15:11 And it can be quite hard to then figure out where you wanna go and 15:16 if we're actually agreeing. 15:20 Cuz I think collaboration problems arise when teams lack the tools to agree meaning 15:22 and structure, and that is key to make sense of what we're building together. 15:27 We have to agree on what we're achieving. 15:32 What's the meaning? 15:35 What's our intent? 15:35 What do we want to get across? 15:36 And what's the underlying structure that holds everything together? 15:38 And I think structure really matters. 15:42 In Megan's talk she talked about how her clients were often bad clients when 15:44 they hadn't figure out what their intent is. 15:48 And when there wasn't a fundamental structure in the product. 15:51 What Anna talked about just now about the console browsers it made me think, no 15:54 matter what you're showing on both device, if you have an underlying structure of 15:59 content and of how things are connected in your product, that should be there. 16:04 That will work no matter what a user is using to access your information. 16:08 And the tool that helps me to pick the right technique, for 16:14 me to explain what I mean and share with others. 16:20 And agree, there's common understanding of what we're actually doing. 16:24 For me, that's really information architecture. 16:27 And I'm gonna break it, information architecture, down into kind of, 16:30 three components of it. 16:33 And the first one is Ontology. 16:36 Do you know what you mean when you say what you say? 16:39 So this is really about figuring out what is the thing we're building made of and 16:43 what are we gonna call it. 16:48 Think about it. 16:50 A lot of the things we make these days are actually made out of words. 16:51 Content and words will be there. 16:55 The things we, how we label things, how we categorize things is often very, 16:57 very important. 17:01 And if we pick a certain language, 17:03 that often has a certain meaning that changes how a product feels to others. 17:05 There's tools to define ontologies. 17:11 One of them is a controlled vocabulary, 17:14 where you decide these are all the words that we are gonna use. 17:16 Here's all the other stuff that we don't want to have in it. 17:20 I've seen this used in design guidelines. 17:24 Very often, good content editors will have something like this, 17:26 where they say, these are all the things we want to use. 17:30 This is how we're going to talk about it. 17:32 But I've also just seen it in teams when they collaborate and agree early on. 17:34 This is how we're gonna call something for these reasons, and 17:38 we all agree what it means. 17:40 So it's not really a tool for me. 17:42 It's more something that I'm just always aware of, 17:45 just think about what decisions are we making just about language? 17:47 And then secondly it's about Taxonomy. 17:50 This is often what people think of when they, 17:54 when I say, information architecture. 17:56 Have you provided logical structures that bring meaning? 17:58 How are you organizing things? 18:01 You can have sitemaps, you can organize things in facets, but 18:03 just thinking about, how does everything hang together and how does it make sense. 18:09 And because we have to make sure while our products are constantly evolving, 18:16 if you start content first, you have to figure out, is there a place for 18:21 content across what we're building and will there be, 18:24 where is gonna be spaces for content in the future. 18:27 And the thing that brings it all together is Choreography. 18:29 So, How is meaning affected across various channels and over time and through usage? 18:33 And this is why we have things like flowcharts, swimlane diagrams but 18:38 for me, this is merely prototyping. 18:42 To figure out, okay, we've defined what's part of what we're building. 18:44 How is it all structured and connected, but now, how do I interact with it? 18:48 What are all the user journeys that we're gonna have? 18:52 My workflow at the moment is a lot taking, sketching something and 18:55 putting it into POP, prototyping on paper, on the phone. 19:00 I mock something up in whatever tool I'm comfortable using and 19:03 I put it in tools like Flint or Invision. 19:07 And I do this just for myself as a way of thinking about it, but 19:10 also to share it with my team and see is it all holding together. 19:13 Because there's so many things you're not necessarily considering and 19:16 the structure that feels really good if you're considering, 19:20 when is somebody gonna access this? 19:23 How are they gonna do it? 19:25 What've, what've they done before? 19:26 That element of choreography and 19:28 how users are going to interact is something really important. 19:29 And the earlier you model this and 19:32 you prototype this, the easier it will be for you to understand. 19:34 Have we thought everything through, does it all make sense. 19:37 So these three things together make up the wider field of information architecture. 19:42 If you're interested Dan Klyn, Abby Covert are people who are great looking up deeper 19:46 definitions about this and the guy called Peter Morville has just written a book 19:52 called Intertwingled, that goes a lot into the topics I'm talking about in this talk. 19:56 So these are kind of my tools. 20:02 Information architecture helps me to be mindful about the decisions we're making. 20:04 But it also gives me a range of different tools, diagrams, things that I can use. 20:08 So go out and use diagrams, use prototypes to think for yourself. 20:13 But more importantly, communicate with each other. 20:18 And it's not that prototypes are deliverables and mental models and 20:21 drawing up are kind of things that are sorted now. 20:26 It's just tools to help us think and 20:29 to see are we on the same picture, are we all agreeing. 20:31 But I often still get it wrong, 20:38 making sense of things is really hard working with other people. 20:40 Is really, really hard. 20:44 This is actually not an ant. 20:46 I struggle to pronounce the word. 20:49 But this is a spider disguising as one. 20:51 So often things are not quite as they seem. 20:54 But, just by using some of the tools and just thinking about things that I've, 20:57 just a few concepts I've just explained to you. 21:02 That helps me to figure out things and 21:04 hopefully designing things that make sense. 21:07 Now, I looked up sensemaking as a term because there's a big field of people who 21:10 are actually talking about complexity and systems thinking and sensemaking. 21:15 And what was interesting to me is that sensemaking is taught in business schools, 21:19 so what I'm gonna show you is from a book by a lady from the MIT. 21:24 And sensemaking is there taught as a key leadership capability in MBA programs. 21:29 And I was interested what the sensemaking mean in this kind of business context and 21:35 does it apply to my understanding of, you know, figuring things out. 21:40 Collecting data, modeling it, 21:44 expressing it, prototyping it, collaborating, sharing it with others. 21:46 And then experimenting and putting things out in the world to get more feedback, 21:50 is that the process that these business people mean when they talk about it. 21:54 So, they define sensemaking as it refers to how we structure the unknown, so 21:58 as we are gonna be able to act in it. 22:03 And sensemaking involves coming up with a plausible understanding, 22:05 a map of a shifting of a changing world. 22:10 When in testing this map with others through data collection, through action, 22:13 through conversation. 22:18 And then we refine it or abandon it depending on how credible it is. 22:20 So this is a lot about modeling, making maps, 22:27 collaborating, sharing the experiment. 22:29 I found it very, very similar. 22:31 And I think it matters for us because I'm gonna show you a quote from 22:34 Simon Collison from 2009 where he said, what we build is rarely finished. 22:38 We build systems that flex and grow with the client, the business, 22:43 the organization, the community, and the availability of new devices. 22:47 So, this was in 2009, five years ago. 22:54 I think it's even more important now. 22:57 I find in my job I'm often the one that, 22:59 especially when you build new products, it is a responsibility to client's business. 23:03 You're coming in, you're shaping a strategy. 23:08 And a lot of it is also about how we work as an organization, 23:11 how the client works as an organization. 23:15 And I feel that it, the more we work in, on products that are part 23:18 of an ecosystem of devices of other products if we work on a bigger service. 23:24 We have to think more and more and more about this complexity. 23:29 And I looked a little bit into, how can I unravel this complexity and 23:34 just help figure out this, often sometimes quite challenging situations. 23:39 And there's a framework called Cynefin by a guy called, Dave Snowden, 23:44 that if you're interested in this you can look into this for a bit more. 23:48 But he defines situations into categories of complexity. 23:51 And the first one is Simple. 23:56 And he says our approach to decision making when there is 23:57 a simple problem is often cause and effect. 24:00 We understand how to fix it. 24:04 And we can just go and do it. 24:06 The second one is Complicated. 24:09 So if something's really complicated you maybe need more time to figure it out. 24:11 Maybe you realize you lack the expertise to do this. 24:15 So your strategy to resolve it is to go out build up your expertise or bring 24:19 somebody else in who can help you figure this out, or you give yourself more time. 24:23 But I find we often operate in very complex situations solving 24:29 complex problems. 24:32 When you're putting out a new product. 24:34 When you're making changes to something, 24:35 you don't know what's going to happen very often. 24:37 And that's because we work with people. 24:40 We design for people. 24:42 And people make things complex because you can never predict their behavior. 24:44 You can't predict how your client will behave. 24:48 You can't predict what the users are gonna do. 24:50 Yes, you can go and test and 24:52 prototype it, but this is the only way to find out what you're gonna do. 24:54 You have to run experiments. 24:57 So for complex situations, 24:59 running experiments is the best way to getting more information and 25:01 help you with your decision, and make sense of what's going on. 25:04 There's a fourth category. 25:07 This one is called Chaos. 25:09 There's some very philosophical discussions about chaos. 25:10 But in a simple way, if there's chaos, you often have to fix things quickly, and 25:13 just act really quickly. 25:17 There's a few sensemaking principles that I have found in 25:22 some of these business books. 25:24 And I feel they're very much aligned with the process that we all already use. 25:26 So, collect many types of data from different sources and bring them together. 25:32 For me, I always advocate to get quantitative data about your customers, 25:36 but also get qualitative data and go out there and 25:40 combine different techniques to get data. 25:43 Collaborate with others. 25:48 And I wish there was more, especially in agency and consulting land. 25:50 I wish more people would put full teams on projects from the beginning onwards. 25:54 To allow us to have this collaboration where the people are defining the data 25:58 structures, how the system works to collaborate really quickly with the people 26:02 who will be defining, define the kind of layer it uses will interact with and 26:06 bring those two together from the beginning onwards. 26:10 So everybody has a shared understanding of who the users are and 26:13 what their mental model is. 26:16 And about what the technology we have chosen whether the opportunities and 26:18 constraints, and how can we make sure those two are better aligned. 26:22 And I can't stress enough to model and prototype. 26:29 And that can be anything from making a prototype in 26:31 whatever medium you're comfortable with, just drawing, drawing a diagram of your 26:36 backend architecture on a napkin and sharing it with each other. 26:40 I find that sometimes there is a lot of obsession about making these things and 26:44 getting things out there really, really quickly. 26:48 But agreeing together, what are we gonna do, how does it all connected? 26:50 What's the structure that binds everything? 26:55 For me, that is really, really important. 26:58 And I see that as part of making, and as a key thing to help us collaborate and 27:00 not as a, as a waste of time that y stops us from actually getting things out there. 27:03 And then finally we learn from experiments. 27:10 Again, this is a list from a business book. 27:13 This is not a summary of my talk. 27:16 But I think that it is really, really interesting that this way of 27:18 working that feels so natural to lots of us. 27:21 That books like The Lean Startup that was mentioned earlier today by Chris that 27:25 they're already talking about, it is something that people who are in 27:28 leadership roles in organizations are being taught to help fix 27:31 organizational team problems and make the big decisions. 27:35 You know, how to spend your next multimillion dollars. 27:39 What are you gonna do it with? 27:42 You know, how, how are you going to stack the whole department? 27:43 What are you going to do. 27:45 So they are trying to apply a similar kind of process to figure things out. 27:46 And, I am going to bring this quote back again. 27:50 I am really lucky that I have a toolbox of things that I can choose and 27:55 by being able, having been able to observe lots of teams. 28:01 Obviously I still make lots of mistake myselfs. 28:05 But I've often seen what it causes if a team starts discussing something 28:08 without the right tool, without the right collaboration technique, or 28:11 just without a pen and pencil to draw it out together. 28:16 So, if you are working in a team. 28:20 You are equipped with tools to make everything better by 28:22 just choosing the right way of expressing something that you're working on and 28:25 sharing with others visually. 28:29 So I encourage you to extend your tools box and 28:31 to just let the, always let the problem that you're in, 28:34 or the project that you're working on decide what you're gonna use but 28:38 have a list, have, have some tools ready, have some prototyping techniques ready. 28:43 Have some different ways of drawing up diagrams or 28:47 collaboration tools ready for your team. 28:49 Because sensemaking is a process and I feel that design is a really powerful tool 28:52 to do that, and especially as the context we work in becomes more complex. 28:56 And our clients sometimes see design as the savior. 29:02 You're gonna come in and fix everything and make everything beautiful. 29:07 Often you have to look into underlying flaws in structure. 29:10 In how data's being collected and how data's be, data's being presented. 29:16 Says a lot of underlying things that we suddenly have to deal with. 29:20 Sometimes our role is being brought in as a strategist or 29:23 as a designer, as a developer. 29:26 But we often spot everything else that's going on because I 29:28 believe we're naturally trained as thinking more holistically. 29:31 And that's the kind of message I want you to take away, 29:34 that you have all the tools and hopefully you can pick up some more from my talk. 29:37 This was it for me. 29:43 I'm around at the after party as well. 29:45 So if anybody has any feedback or 29:46 any further questions, let me know and I'm at @johannakoll on Twitter. 29:49 This is my Twitter avatar as well. 29:54 I don't look like this today. 29:56 But you can, maybe I should have brought this to make it easier to find me. 29:58 But you can tweet at me. 30:01 I'll tweet back some time later today. 30:02 And thanks very much and thanks Generate for having me. 30:04 [APPLAUSE] 30:07
You need to sign up for Treehouse in order to download course files.Sign up