1 00:00:00,000 --> 00:00:04,800 Over the years, I've developed a series of tools and techniques that have helped 2 00:00:04,800 --> 00:00:08,900 teams integrate, both agile, user experience, and 3 00:00:08,900 --> 00:00:12,800 lean ux, and due process. And I want to share three specific techniques with you now 4 00:00:12,800 --> 00:00:16,700 and tools that can help you start to build this 5 00:00:16,700 --> 00:00:20,800 level of cross-functional collaboration, and increase the efficiency of the 6 00:00:20,800 --> 00:00:24,800 teams that you're working with. The first is the concept of the experiment story, and we 7 00:00:24,800 --> 00:00:28,600 talked about user stories as the building block for an agile backlog. 8 00:00:29,600 --> 00:00:31,000 An experiment story. 9 00:00:32,400 --> 00:00:36,900 Allows you to build learning into your backlog. It's a 10 00:00:36,900 --> 00:00:40,800 story just like any other. But instead of delivering 11 00:00:40,800 --> 00:00:44,400 design or code at the end of it, you're delivering 12 00:00:44,500 --> 00:00:45,300 learnings 13 00:00:47,400 --> 00:00:50,600 You're writing an experiment Story, You're assigning. 14 00:00:52,100 --> 00:00:56,900 Resources to that story. So you're saying we'd like to learn this as part of the story, we 15 00:00:56,900 --> 00:01:00,900 write it like a hypothesis. We believe that by adding a big red button to the 16 00:01:00,900 --> 00:01:04,500 checkout flow, people will buy more stuff and we're going to 17 00:01:04,500 --> 00:01:08,900 assign the product manager and the designer, for example, to that, and we're going 18 00:01:08,900 --> 00:01:12,300 to estimate it at two points or three points. 19 00:01:14,400 --> 00:01:18,200 And we're going to build learning into our backlog and we're going to 20 00:01:18,200 --> 00:01:22,600 prioritize that against delivery stories, stories that deliver 21 00:01:22,600 --> 00:01:23,200 code. 22 00:01:24,400 --> 00:01:28,200 We're going to put it into the backlog where we believe it should go. 23 00:01:28,900 --> 00:01:32,900 Knowing full. Well, that we may learn something from 24 00:01:32,900 --> 00:01:36,800 that experiment that will affect the downstream 25 00:01:36,800 --> 00:01:40,600 prioritization of the backlog. We're going to 26 00:01:40,600 --> 00:01:44,600 assign resources from the team to work on this who will not work 27 00:01:45,000 --> 00:01:48,100 on something else while this story is in play. 28 00:01:49,700 --> 00:01:53,700 We're going to use those learnings to refine and groom the backlog 29 00:01:53,700 --> 00:01:57,800 Downstream from here. Now as the learnings come in 30 00:01:57,800 --> 00:02:01,500 from that experiment, we have to bring that back the team as quickly as 31 00:02:01,500 --> 00:02:05,500 possible but the idea is to build 32 00:02:05,500 --> 00:02:09,700 learning into the execution process. So that you're always checking 33 00:02:09,700 --> 00:02:13,500 whether you're building the right thing or not. And by 34 00:02:13,500 --> 00:02:17,500 writing these stories for experiments and in prioritizing them 35 00:02:17,600 --> 00:02:19,200 just like you would execution, 36 00:02:19,400 --> 00:02:20,400 Delivery work. 37 00:02:21,800 --> 00:02:25,900 You're forcing the team to consider what's more valuable at this point. Should we learn something 38 00:02:25,900 --> 00:02:27,500 about this or should we build it? 39 00:02:28,800 --> 00:02:32,800 And that's a good conversation to have with your team and this is a terrific tool to start that 40 00:02:32,800 --> 00:02:36,200 conversation and to build that continuous learning 41 00:02:36,500 --> 00:02:38,800 into your agile delivery process. 42 00:02:41,500 --> 00:02:45,800 Another tool that's worked really well. For me, over the years has been 43 00:02:46,000 --> 00:02:50,900 a Wiki you can use Wiki's for any kind of knowledge 44 00:02:50,900 --> 00:02:54,300 aggregation, but we've used them in the past for Knowledge Management Systems, 45 00:02:54,500 --> 00:02:58,600 especially Works, especially well, with distributed teams. But this is a great place to 46 00:02:58,600 --> 00:03:02,900 aggregate your project assets to onboard, new 47 00:03:02,900 --> 00:03:06,700 team members who join, and they want to know what's taken place to date. 48 00:03:06,900 --> 00:03:10,600 Take a look at the wiki. All the assets are there you can keep corporate 49 00:03:10,600 --> 00:03:11,000 documents. 50 00:03:11,200 --> 00:03:15,500 You know, that's important. And most importantly, if you need to maintain the product, people can go back to the 51 00:03:15,500 --> 00:03:19,500 wiki and look at the decisions that were made the assets that were 52 00:03:19,500 --> 00:03:23,900 captured, any kind of commitments that were business rules that were 53 00:03:23,900 --> 00:03:27,400 changed based on learnings, it's a terrific way to aggregate 54 00:03:27,600 --> 00:03:31,200 information and, and the benefits of using this is that it's living piece of 55 00:03:31,200 --> 00:03:35,600 documentation. It's not, it's not a static document that lives on somebody's lap top. 56 00:03:35,800 --> 00:03:39,900 It lives in house on site with revision 57 00:03:39,900 --> 00:03:41,000 history. You can 58 00:03:41,200 --> 00:03:45,900 See what's changed, you can see who changed it, you can see the discussion threads 59 00:03:45,900 --> 00:03:47,600 around the things that have changed. 60 00:03:50,800 --> 00:03:54,800 Wiki's typically interface with other project tools so they 61 00:03:54,800 --> 00:03:58,800 can connect with your project management system or your bug tracking system or 62 00:03:58,800 --> 00:04:02,100 perhaps with your with your agile project management system 63 00:04:03,000 --> 00:04:07,700 and they can often send you push alerts when things have changed. So if you're not directly involved with the project but you're 64 00:04:07,700 --> 00:04:11,300 interested in the progress made, you can sign up to get alerts 65 00:04:11,900 --> 00:04:15,800 from that particular page or from that project that says, hey this changed, there's a new 66 00:04:15,800 --> 00:04:16,800 discussion over here. 67 00:04:18,300 --> 00:04:22,600 And this allows people who are not directly involved with the product development process. 68 00:04:23,600 --> 00:04:27,000 To keep tabs on how projects are performing customer service 69 00:04:27,300 --> 00:04:31,100 marketing legal compliance. Branding 70 00:04:31,300 --> 00:04:35,600 Executives can keep track on specific projects by subscribing to the 71 00:04:35,600 --> 00:04:39,900 pages on these Wiki system. And the nice thing is that they're accessible 72 00:04:39,900 --> 00:04:43,700 from any device anywhere anytime. So everyone has 73 00:04:43,700 --> 00:04:46,100 access to these tools at any given time. 74 00:04:47,500 --> 00:04:50,600 Now if you set up a Wiki for your project here's some basic 75 00:04:52,000 --> 00:04:56,900 basic framework for setting up that project. So obviously you'd like set up a project description with a 76 00:04:56,900 --> 00:05:00,500 name and the problem statement. The problem statement being why are we doing this 77 00:05:00,500 --> 00:05:04,900 work? It's a terrific way to frame a project in your Wiki and 78 00:05:04,900 --> 00:05:08,100 your documentation what we set out to do and it's a good way. 79 00:05:09,400 --> 00:05:13,500 To go back and validate some Downstream thinking, maybe your six months into a 80 00:05:13,500 --> 00:05:17,800 project and you're drifting away from why we set out to do this in the first place, it's a good way to 81 00:05:17,800 --> 00:05:21,500 revisit that you set out your success criteria your 82 00:05:21,500 --> 00:05:25,800 outcomes, who's on the team, what they're doing and any lists 83 00:05:25,800 --> 00:05:29,800 of completed stories with links back to those stories. So people can 84 00:05:29,800 --> 00:05:33,500 see what's been delivered, what it look like when it went live 85 00:05:33,700 --> 00:05:37,900 bugs, Etc and you can you can break down the project into a story page, 86 00:05:37,900 --> 00:05:38,800 a page per 87 00:05:39,200 --> 00:05:43,600 Rate that has a link to where you're tracking the story. 88 00:05:44,000 --> 00:05:48,500 It has the assets for that story designs, wireframes prototypes, any 89 00:05:48,500 --> 00:05:52,500 research, efforts and evideos any photos, any documentation that you've 90 00:05:52,500 --> 00:05:56,800 captured during those research with summaries and links 91 00:05:57,000 --> 00:06:01,800 to all the artifacts that allows team members to go back and review, things or new 92 00:06:01,800 --> 00:06:05,800 members to on board to get a sense of why we made the decisions that we made. And again, 93 00:06:05,800 --> 00:06:09,000 this is living documentation. So it's not one person's responsibility. 94 00:06:09,100 --> 00:06:12,400 Its ability to update this, it's the team's responsibility. 95 00:06:13,900 --> 00:06:17,700 To continually make sure that this knowledge management system is up to date. 96 00:06:19,400 --> 00:06:23,900 Now, another tool and a terrific use for a Wiki is the idea 97 00:06:23,900 --> 00:06:27,800 of a style guide. Now, this is my definition for a style guide. It's a set of defined 98 00:06:27,800 --> 00:06:31,600 guidelines for the presentation layer, the behavior, and the 99 00:06:31,600 --> 00:06:34,900 voice of a system, whether it's a website or online product, 100 00:06:35,800 --> 00:06:39,700 marketing, marketing, collateral Etc, and it's also a repository of 101 00:06:39,700 --> 00:06:43,000 assets, both graphical and code, for this system, 102 00:06:44,300 --> 00:06:48,900 There's a big movement Now to create living style guides which are the actual style sheets 103 00:06:49,200 --> 00:06:53,500 for the system. So if you update the style guide, you actually update the site in production 104 00:06:54,500 --> 00:06:58,900 But style guides are extremely powerful. They work really well. If captured if you're not going to do a live style guide, 105 00:06:58,900 --> 00:07:02,300 capturing it in Wiki's a terrific way to do it. And they work really well because they 106 00:07:02,300 --> 00:07:06,900 Define all of the basic components of the workflow in 107 00:07:06,900 --> 00:07:10,900 the interaction of your system. What is the header going to look like? What is the footer going to 108 00:07:10,900 --> 00:07:14,900 look like, what type of navigation are we going to use? What's the font structure? 109 00:07:15,000 --> 00:07:19,800 Do our positive buttons. Go on the left versus on the right. Where do we put our form 110 00:07:19,800 --> 00:07:23,800 field labels? Do we use? Carousels. You know what kind of arrows do we use? It 111 00:07:23,800 --> 00:07:24,200 said all of 112 00:07:24,400 --> 00:07:28,200 Of things that need to be defined once and codified and 113 00:07:28,200 --> 00:07:32,500 reused throughout your system can be captured in the style 114 00:07:32,500 --> 00:07:33,000 guide. 115 00:07:36,400 --> 00:07:40,600 And so, you're building consistency for your customer consistency of brand, 116 00:07:40,700 --> 00:07:44,900 consistency of voice of interaction. I've learned how to use the 117 00:07:44,900 --> 00:07:48,700 system here and it works the same way every single time. They launched something 118 00:07:48,700 --> 00:07:52,800 new or I try something different on the website, you set expectations for your 119 00:07:52,800 --> 00:07:53,400 customer. 120 00:07:54,500 --> 00:07:57,400 To deliver the product, the experience the same way each use. 121 00:07:58,700 --> 00:08:02,500 you're also adding efficiency for your team by defining these 122 00:08:02,500 --> 00:08:03,700 assets, once 123 00:08:05,800 --> 00:08:09,900 Storing them centrally and then reusing them throughout the system as 124 00:08:09,900 --> 00:08:10,900 often as possible. 125 00:08:12,100 --> 00:08:16,800 And so, you're taking all the routine work out of the design and you're allowing 126 00:08:18,000 --> 00:08:22,600 Your team to be much more to focus on the bigger challenges. The more creatively 127 00:08:22,600 --> 00:08:26,600 challenging portions of the experience, which buys them more time 128 00:08:26,800 --> 00:08:30,700 because they don't have to debate. Each time they build a form where the form field 129 00:08:30,700 --> 00:08:31,400 labels go. 130 00:08:33,500 --> 00:08:37,900 And what's nice is that you're creating a foundation and a set of rules on 131 00:08:37,900 --> 00:08:41,900 which you can build and expand the product Suite, which then allows you to easily 132 00:08:41,900 --> 00:08:45,700 scale the system and empowers, the team to move forward without having to 133 00:08:45,700 --> 00:08:49,900 seek approval design approval, interaction approval for every 134 00:08:49,900 --> 00:08:53,600 decision that they make, because the basic building blocks have been defined once 135 00:08:53,900 --> 00:08:56,100 and agreed upon by the entire organization. 136 00:08:58,100 --> 00:09:02,800 There are two ways to build a style guide. I call them slow drip and big bang 137 00:09:02,900 --> 00:09:06,800 and there's pros and cons to each one. The slow. Drip way is to fill out a style 138 00:09:06,800 --> 00:09:10,800 guide opportunistically to create the template for it and to capture 139 00:09:10,800 --> 00:09:14,700 it as you're creating new assets. Hey we built a new photo 140 00:09:14,700 --> 00:09:18,000 gallery interaction. Let's put that into the style guide. 141 00:09:19,300 --> 00:09:23,700 Hey, we figured out there were going to move the form field labels from inside the box to left. Align on top of the 142 00:09:23,700 --> 00:09:27,900 box. Let's put that into the style guide and the benefit. There is 143 00:09:27,900 --> 00:09:31,900 that you don't stop the current development workflow. Your opportunistically filling this 144 00:09:31,900 --> 00:09:32,600 thing out 145 00:09:33,500 --> 00:09:37,500 And it keeps the style. Guide is a living document, that's continually evolving and 146 00:09:37,500 --> 00:09:41,300 learning the problem. With this particular approach, the con 147 00:09:41,600 --> 00:09:45,700 here is that it will take a very long time to get a 148 00:09:45,700 --> 00:09:49,800 complete view, into your system defined and codified into a stock out 149 00:09:49,800 --> 00:09:51,100 of the slow drip method. 150 00:09:52,200 --> 00:09:56,900 And so, alternatively, you could choose to go with the big bang method. When you dedicate some resources, may be a designer 151 00:09:56,900 --> 00:10:00,800 and an engineer and a writer or a Content strategist 152 00:10:01,400 --> 00:10:05,900 to defining the style, guide, all at once. They take some time outside 153 00:10:05,900 --> 00:10:09,800 of their regular work flow, they break down the system into its core components 154 00:10:10,100 --> 00:10:14,800 and they put in all the information into the style guide. Once maybe takes them a month, maybe 155 00:10:14,800 --> 00:10:18,900 takes them a couple of months to get it up and running and and complete but they 156 00:10:18,900 --> 00:10:21,900 build that system. But the benefit is that it makes it 157 00:10:22,100 --> 00:10:26,900 Apprehensive from day one from day. One, all of the components are in there. All the assets that you need 158 00:10:26,900 --> 00:10:30,500 to build an experience to prototype and experience are there and the 159 00:10:30,500 --> 00:10:34,800 efficiency of the team can move forward significantly on day. One on 160 00:10:34,800 --> 00:10:36,000 launch of the style guide. 161 00:10:38,100 --> 00:10:42,600 As if you're thinking about where to start, always start with a table of contents for your style guide. Break down 162 00:10:42,600 --> 00:10:46,700 your, your site into its core components. Header footer 163 00:10:47,100 --> 00:10:51,900 forms, photo, galleries content, tone 164 00:10:51,900 --> 00:10:55,900 voice, editorial, Etc. And then Farm out 165 00:10:55,900 --> 00:10:59,300 those pieces to the people responsible for them and let them fill them out. 166 00:11:00,200 --> 00:11:04,700 But starting with a table of contents, works really well. A couple important things to remember 167 00:11:04,700 --> 00:11:08,800 about the style guide, first and foremost, assign an 168 00:11:08,800 --> 00:11:12,800 owner. Someone has to own the style guide. Now, it's not necessarily 169 00:11:12,800 --> 00:11:16,900 a fun job and so you might want to rotate that own or every 170 00:11:16,900 --> 00:11:20,300 quarter, but someone has to own it and make sure that its current 171 00:11:20,300 --> 00:11:24,700 and it's up to date as soon as that style guide falls out of 172 00:11:24,700 --> 00:11:28,600 date people will stop using it. Someone has to own it and ensure 173 00:11:28,600 --> 00:11:30,000 that it keeps currently. 174 00:11:32,600 --> 00:11:36,700 Make sure that it's accessible to everyone and that it's easy to get to. I worked at a company 175 00:11:36,700 --> 00:11:40,700 once where if you typed the word style guide into the URL bar of your 176 00:11:40,700 --> 00:11:44,700 browser, if you're, if you're on site inside the network, it would resolve to the style 177 00:11:44,700 --> 00:11:48,500 guide, do whatever you can to make it as easy as possible 178 00:11:49,100 --> 00:11:53,600 for people to access. The style guide from wherever they are, especially with distributed teams. 179 00:11:54,800 --> 00:11:58,700 Continue to encourage usage of it and updating Point people to it, 180 00:11:58,900 --> 00:12:02,900 put signs up in the hallways and in the break rooms, make sure people know that 181 00:12:02,900 --> 00:12:06,600 it exists, use a Wiki for a week. He's a terrific tool to make it 182 00:12:06,600 --> 00:12:10,400 happen and most importantly, remember that, it's a living 183 00:12:10,400 --> 00:12:14,600 document as your system involves the style. Guide has to evolve, it has to stay 184 00:12:14,600 --> 00:12:18,400 current. If it doesn't stay current people won't use it and you'll start to 185 00:12:18,400 --> 00:12:22,700 lose that efficiency. Now, the style guide allows your team's to 186 00:12:22,700 --> 00:12:24,300 stop discussing. 187 00:12:24,700 --> 00:12:28,600 What elements they need to do. They need to create in order to move 188 00:12:28,600 --> 00:12:29,900 forward quickly. 189 00:12:30,900 --> 00:12:34,300 It allows them to prototype experiences very, very fast because the assets 190 00:12:34,300 --> 00:12:38,900 exist they can pull together and approximation of a new experience very quickly. Here's a header. 191 00:12:38,900 --> 00:12:42,800 Here's a footer, here's form. Here's some buttons, some content. 192 00:12:43,100 --> 00:12:47,900 And so you can create realistic, prototypes, in a fraction of the effort that it would 193 00:12:47,900 --> 00:12:51,800 take you to code these things from scratch. And that's why it's a terrific tool for the lean 194 00:12:51,800 --> 00:12:52,800 ux process. 195 00:12:55,200 --> 00:12:59,700 And so, in summary, I want to talk about how lean ux merges, the concepts of user 196 00:12:59,700 --> 00:13:03,500 experience and design product management, marketing, and 197 00:13:03,500 --> 00:13:07,700 development, with the agile process, first and foremost, we solve our 198 00:13:07,700 --> 00:13:11,500 problems together as a cross-functional team to build that shared 199 00:13:11,500 --> 00:13:15,900 understanding we get our ideas out of our heads, early 200 00:13:15,900 --> 00:13:19,500 and often. Through sketching, through conversations, through brainstorming 201 00:13:19,500 --> 00:13:23,300 exercises, we recognize that our ideas are hypotheses. 202 00:13:24,200 --> 00:13:26,900 And we validate our design hypotheses quickly. 203 00:13:28,000 --> 00:13:31,600 To know if they're right or wrong. So we don't waste time. 204 00:13:32,500 --> 00:13:35,500 Building and designing things that aren't accurate. 205 00:13:35,500 --> 00:13:38,800 We use scrum as a nice Rhythm 206 00:13:38,800 --> 00:13:42,900 to structure, our lean ux 207 00:13:42,900 --> 00:13:46,600 activities and to build that continuous learning into the Agile development process, 208 00:13:48,400 --> 00:13:52,800 Everyone participates in the process story Gathering, and estimation and prioritization 209 00:13:52,800 --> 00:13:55,800 product design, engineering content etcetera. 210 00:13:57,900 --> 00:14:01,500 Always think about how you can be leaner 211 00:14:02,100 --> 00:14:06,600 in your experimentation, in your process, in your design, in your 212 00:14:06,600 --> 00:14:10,800 engineering. Right. We only want to do what we 213 00:14:10,800 --> 00:14:14,800 need to do to move forward. One step closer to certainty from 214 00:14:14,800 --> 00:14:17,100 doubt. Working in small batches. 215 00:14:18,100 --> 00:14:22,600 Research is an ongoing activity. It's not something that happens once at the beginning. 216 00:14:22,800 --> 00:14:26,600 And once at the end of your project, it's something that we kick off the initiative with and we 217 00:14:26,600 --> 00:14:30,300 build into our iteration Cycles. So that we have that 218 00:14:30,300 --> 00:14:34,900 continuous feedback, both qualitative and quantitative to understand if we're still building 219 00:14:34,900 --> 00:14:38,800 the right thing as you're working, transparency is 220 00:14:38,800 --> 00:14:42,900 key manage up and manage out, let everybody 221 00:14:42,900 --> 00:14:46,300 know what you're doing, what you're learning, how you're 222 00:14:46,300 --> 00:14:47,700 progressing, and why? 223 00:14:47,900 --> 00:14:51,700 Taking the next steps and that will give them a sense of comfort to 224 00:14:51,700 --> 00:14:54,500 stay out of your way and let you continue to move at this pace. 225 00:14:55,600 --> 00:14:59,500 And then finally all of this is an effort and in service of not 226 00:14:59,500 --> 00:15:03,900 designing and not building things that people don't want which is the ultimate form 227 00:15:03,900 --> 00:15:05,900 of waste. Thank you.