 No, that's okay. We don't bite. Who here has worked with a UX designer? Guys you're awesome. I already love you very much. And if you have worked with a UX designer and you've found it difficult, can you raise your hand? It's okay. All right, good. So everyone else, you've had great experiences, but you want to crack it down. This is awesome. How are we doing this sound? Yes, you'll make it work. Okay. Let's start. This is just about integrating Agile, sorry, UX in the Agile development, and this is a case study. So I'm going to tell you stories and stories is what user experience is about. So I'm not going to drown you in too many bullet points, but they'll be just enough for you to get what I'm talking about. So this is a story in three acts and I'm using the Shu Hari evolution, the learning method of mastery to describe it. The first project I'm going to tell you about is going to tell you the story of how I discovered Agile. The second one is about refining skills and the third one where I did mastery is working with a development team amongst others. Anybody not familiar with Shu Hari? Okay, so Shu Hari comes from martial arts. It's a learning process. Shu is the very beginning when you're learning something, you follow the rules, you need the rules. Then as you evolve and you master some moves, some gestures, remember it comes from martial arts, it's very physical. You get to the high level when you start feeling the limits of your learning. Your experience has grown and then you go beyond those limits and you learn to read where you freely play with options. You don't even know the knowledge you have and that's the mastery level. So Shu, when I got started, I was a mid-weight UX designer working in very traditional creative agency space, which is very, very waterfall. You get passed on stuff. You don't get told the story. Communications are very broken. If you're quite junior, you don't have access to users or customers. And in general, in creative agencies, you never see the final user of the product, which kind of puts a spin on the user experience part of the title of the job, but it's okay. So I got involved in a project with French telecom operator in the UK, Orange. And Orange had quite a few problems with their work stream and getting work out and they've been sold the idea of Agile and they wanted to try and embed an Agile team in their head office, not in their development headquarters in the countryside in Bristol. They wanted in their head office, a small team, to try to see how this Agile thing works. And I got placed there from my creative agency, sitting down with a team. And the first thing we did was we set up, I got myself in a room, a very small room, a very, very small room. There was a table about the size of this blue one. There were four guys. I was on another desk and we had a single plug for the five of us. So I can tell you collaboration was at an all-time high. When every two minutes, somebody's got to ask for power. And it was very confusing. I had no idea what was going on. Nobody had really explained that Agile thing to me. I just knew I was there to do my job, whatever it was. I'm retitling myself Team Dolphin because I just jumped on command. And it was all about like, I was told to reuse existing specs and the guys will figure it out. Well, there was a lot of maniacally typing on a keyboard from the PO and the three devs. There was me just handing out stuff I had already done for a previous project and kind of wondering why I was there. So not a great start. I mean, it was kind of fun with sitting with these guys and thinking that I was doing something great, but it wasn't really working. So if anything you want to start your UX designers in shoe, give them an intro to Agile. I had to go and hunt for myself and go and figure it out. And there is a lot of information everywhere and it's not easy to make sense of it. I also had no clear understanding of what the learning was about. And it wasn't about delivering a project. It was about learning how this Agile thing works, like how vague it is just makes it unachievable. A bit clerical always helps. You want to get a scrum master in if you're adopting scrum or somebody to help give the pace, set up the rules, explain the game. And then you want to get designing. Like, so designing, so doing this project in the abstract, you were using work. Just wasn't working. I was literally just standing there twiddling my thumbs. And every now and again, one of the devs would have a question and I would think, oh great, I'm being useful. So you want to get designing from the start. The stage two of shoe, which is a three stage process, we moved into the open space. We exited the tiny, tiny room. We had a plug each. We had one more dev come and join and we started properly designing. So I was engaged. I was asked to recreate design specs. Now, I still don't understand that part and that was quite a few years ago. But the idea was you really don't have the time to do all the thinking. But, you know, just, I don't know, iterate a bit, like change a little bit, make them better. I'm like, oh, opportunity of doing things better. But the idea was for me to take that time to design and then pass it on to the devs so that they could grow into the cycle of UX, getting the thinking, bouncing on the dev and then getting the collaboration working. There was a small hiccup in that team, which was I already knew the product and the platform quite well. I had been working on it quite a lot. These guys were new to Orange. We were all a bunch of externals. And the pace was just not really, really gelling. So, what could really have helped at that stage is to get a coach in and to really limit the artificiality. I think very much this was a, it was a fishbowl, it was an aquarium experiment. Like when I put a small set, we're going to recreate an ecosystem and try to pretend that it happens like this in the real world. And inasmuch as I appreciate that those boundaries made it quite safe, you know, gave us a really clear scope, it was too artificial to really learn and to really gel. And for my part, I struggled working very much in the abstract. So pure abstract, I'm like, where's the product? Where are my users? Can I talk to them? Can we get things done? I want to see this product out. So thankfully, we got to stage three. And the two previous stages were quite rapid. We were about two, three weeks, I think in that small room, about a month, sorry about that in the stage two. And then we got really running. So by that time, a coach had come on board. She was awesome. And one more dev, two visual designers, like we were ramping up to do good stuff. The product we were working on was the e-commerce shop where orange customers could buy their phones, their dongles, their plans, their minutes and everything. And the plan was really to design and build in each sprint and deliver to QA. You may notice we're delivering to QA. QA is not part of the team. I discovered later on that was quite an interesting thing. That was quite an interesting thing because when we had enough for them to start QA, we started saying, come on and join us. We're having stand-ups. We're having boards. We have stuff on the walls that come and join us. And the open plan was kind of L-shaped. And we were at the end of the L and we had to turn the corner. And then there was a door on the left and a small room. And in that small room was the QA team, about five of them. So we knocked on that door and we said, come and see and work with us so that we get this agile thing going because so far it's going pretty good. And the QA team closed the door and they shouted over the door, no, we're not, you have to send us emails. So we knocked on the door again and we're like, guys, like we're right here, like we can bring donuts. Just come out and play. No, no, no, you have to send us emails. We need the specs written down. Like, well, how about you come and talk to us first and they put up a massive fight. There was about a fight going on. It was really awkward because remember, like we're in the same space. Like they would be right there passing through. And there was this really awkward moment of like, I don't know why you don't want to play or why you want to try this. Like we're not trying to make your life complicated. We're actually trying to make it easier by not having you figure out the whole thing from lines on emails. Eventually the coach worked her magic. QA manager came out, observed the situation from a safe distance, deemed that we were not rabid or dangerous and agreed to begin considering the eventuality of participating in a possible process. Like we were a long way from playing together. So what did I learn from this? Well, I learned it's not easy, but you have to keep it running. You have to keep trying. The fact that we were already engaged in the process was really useful. And there were lots of little things that were kind of funny. So we were discovering ways of working together, which is so agile. We were discovering ways of building better products by trying to remove the problems. We were discovering the skills that were needed on the team as we were going. The coach was doing great work at educating us on the process as we pretty much were all fairly new to agile and the client, the orange, the client that was kind of a foreign entity to us all was also new to it. There was a lot of learning and adjustment and little funny stories. So for example, because I came from an external agency and I had that agency's laptop, Orange could not plug me into their broadband into their internet, their telco, but they can't plug guests on the internet in their own building. So amongst my two other, three of us from the agency, we had one single dongle to share. So we basically had no emails for a couple of months, which was just the best part of it because we were not bothered by the mothership and we could develop ourselves solely to the team. The project was canned after a while. It was way too artificial. We were not permanent staff. We were doing good things. The problem came out that they could not integrate what we were doing into the mainstream of work. So the implementation into the final product was just not happening. What did I learn? Well, I learned that UX and agile is very much firefighting. There are fires everywhere. You're running around like a mad cow. I did not have a helmet. And I don't know if you see those tools, but firefighting is not subtle. It's not heart surgery. You don't have scalpels. You're not precise and methodical. You're fast, but you're not precise. You use axes and you just bash things down and you cobble things together. There are no subtleties about it. It's not elegant at all. But hey, I quetched the fires. The other thing that I learned is that, working in a team, everything is awesome. This is where I fell in love with that job. Like the proximity with the developers, the proximity with the designers and the PO, the collaboration ticked so many of my buttons. So I was having an absolute blast. A really good fun. And the last thing I learned, amongst many others, was that with collaboration, you can finally make things happen. I was having a lot of frustration previously in the fact that my UX designs in this very waterfall process were passed on to the dev team. And I had no visibility as to what they were doing. At some point, I would see the product come out live and it would greatly differ from what I had designed. And every now and again, I could come and see somebody and say, why is it so different? Say, well, we couldn't do these things. So we figured out a way of doing it ourselves. I'm like, I was right there. Why didn't you come and talk to me? I'm like, well, that's not the way it works. Well, that's not the way it works, but it's kind of broken. So all of a sudden, that job, we had this thing where the guys could just literally turn around in their chair, tap me on the shoulder and say, all right, that thing here, not possible. Let's figure out another way of doing it. I'm like, rock on, we're doing that. So shoe, a bit chaotic. I was a bit of a ball and a pinball machine. Like it was going bing, bing, bing, bing, d-d-d-d. And, but it was fine. I liked it. I came back full of enthusiasm to the agency. Those were quite early days. That was about five years ago. And at that point, creative agencies were not embracing the agile thing. They hadn't heard of it. They were very waterfall. And I kept on the lookout thinking, if there's more of this agile thing going on, call me in. The next step was growing into my skills and going into how. Now how I applied it in another stream of work, still for Orange, which was business as usual. And we set up a small team with no developers. So that was also a bit of a strange environment. Remember, agile is very attractive outside the dev room. And I came in as UX and product owner because I had a huge experience of the products, of the platform, of the clients. I basically knew more about the capabilities of the e-commerce shop than the customers at Orange who were asking us to do things. We had a constant stream of incoming work. There was me, a visual designer and a copywriter, remember, a creative agency and a project manager who was just managing the relationship with the people at Orange. And we had one evil goal, which made it a lot of fun. The evil goal that was fully admitted was that our job would be to clog the pipeline of the dev team in Bristol. And the reason behind it is that there was a strong suspicion at Orange that the marketing and product teams were not fast enough. They were not getting enough work done and it was their fault that things were not happening live on the site. The product and marketing teams knew they were fast enough. There was a bit of hiccup, but they thought, you know, we're gonna create that work, we're gonna smooth our process. Very much lean at actually, like, let's get going. And they're going to see that the bottleneck was already there in the dev team at Bristol. So my job was to get that side road, like clogged with work, to ship it out. Ship it out, ship it out, so that the existing bottlenecks, which I knew was already there, could be highlighted. The product and marketing team could raise their hands and say, that wasn't us, it's these guys over there. Which is just this lovely culture of enterprise. But anyway, I was on with this. And it gave me the opportunity, while you're thinking flow, you're thinking consistent stream, I was thinking Kanban board. And literally I was receiving every day between one and five requests for work. Put a table here, improve that page there, tweak that button that doesn't work, create a banner, all kinds of stuff, like build me a pony, I want it pink, make it blue, have some glitter. And my job was not to prioritize, it wasn't a regular PO job, it was just to triage. And I was receiving those queries and every morning in my product owner hat, I was triaging, okay, this is, there's no UX here, straight into design. There is UX here, I'm gonna keep it for me. This is, you need to sort out your stuff, fighting back to the client. Your platform, come do it, fighting back to the client. We need to have tech confirmation, put it on hold. So I was triaging, triaging, and getting things done and moving my little cards around the board. And I was sitting in the UX team at that time, the designer and then copywriter were on another floor. I was running around all day long with my brand new iPad one and checking on them, moving my cards, moving around. The rest of the UX team had no idea what I was doing. But the UX director was really happy to see the cards, thing like she thought that I was doing stuff, like I had no idea what was going on. But it had the magical Kanban effect of look, I'm moving the card. So the columns, just to tell you what they are, are in scoping, so that was, I received something I need to triage it with client services, so to be sent to the client, ready for user experience, ready for copy, so in UE review, ready for creative, ready for copy and done. So I was, and I adapted the columns as I went. And after four months of work, I got a hell of a lot done. And I had changed the copies of it. I had created another column for standby or not business as usual, when the project looked much bigger than our capacity to deliver, I immediately flagged it and said, that's a proper project, this is not business as usual. And I moved cards around. And I, you know, that was a brilliant system. Remember that the aim of Kanban, and I'm quoting Taishi Ono here, is to make trouble come to the surface and link them to Kaizen, to the continuous improvement. Well, that was certainly doing it. Because very rapidly we saw some bottlenecks. So there was a big bottleneck here with, that's the with clients. So basically there was stuff that I sent back, either for review, clarification, for final approval before placing in my done column, and they were clogging things in. And then the copywriter got a bit busy at some point, so there was a bit of a clog there, but I was moving things out. So what happened really in my half phase of learning about Agile and UX? Well, I got to play with the Kanban board and understand how it works, understand how it matches my process, understand its power, understand its power for me to organize my work, to get visibility that I need. I need to view things. I need, I do the meerkat. Like I stand up on my little pause and I look around. I need to see what the environment is to be able to make decision. It gave visibility, of course, to the people around me, who were very, very remote from what I was doing. It made the project managers life a dream. They wanted a webcam onto it, because basically I was doing their job of project management. We implemented daily stand-ups. So every day, met the team, discussed what we're going, getting that collaboration going. I literally overtook delivery from the project manager, which was fun for me. And I really increased my knowledge. I had the space of finding the process that worked for the work on hand. I had the space to find the process that works for the team I had and the constraints I had within the agency model. So if you wanna do this, literally enable growth of your UX designer. There is really a strong proximity between UX and product ownership. It's great to have the two roles as separate so they can have healthy discussions or bloodbaths, depending how you wanna do it, on should we serve the user or should we serve the needs of the business? But you want that tension. You want that discussion. You want that ambiguity on where is our best interest? And let the team experiment with practices. Now, I got to experiment because I already knew from my shoe period I knew a bit of those practices but I also knew where to look out. And there's a big agile community. I'm based in London. There's a big agile community there. There's a lot of resources. There are meetups. There are lots of people happy to chat. There's lots of conversations on Twitter. I was able to grow. But I'm not gonna fool you. What I was doing was just spinning Chinese plates. Like I was literally running around trying to keep them all spinning. I loved running around. Was it a sustainable model? Probably not. I think after a while, so we stopped after three months when I left the agency. I know that it did not survive my departure. They handed the project to a very junior UXer. I'm still laughing, poor guy. He still doesn't know what it does. But I discovered a bit of the magic that the PO does and the product owner, I understand has this role of keeping those plates spinning figure out how many plates need to be there. Can we take a plate down? How fast do we need to spin them to get them going? And I understood the power of user experience in the agile concept into building the products. How does it play? How does the cadence play? How does the collaboration play? Then we moved on to ring. So more time has passed on, I've changed agency. And we're engaged in a process building an e-commerce site. Fairly bread and butter for me by that stage and plenty of those. But the fun part was it was for a luxury brand with clients in France. Make it a bit more fun. And beyond the challenge of distribution, it's not too bad France. You're two hours by train. There's a bit of a language barrier because the French are not that great with English. I'm French, I know. And every now and again in a meeting, they would stop and they say, Sophie, can you translate? We have no idea what you guys are talking about. So I have to make sure that we could work. Our job was to wow the customer. And we engaged in agile and I decided to go for the agile process in collaboration with the rest of the agency because agile could give us this opportunity to deliver early some visual design, some visual realization that would make it seem like the work is much further advanced than it is. So we'd have an early wow factor. But the secret to that is that we had a big sprint zero. There is a huge debate in the agile UX community whether a sprint zero is proper agile or not, whether a sprint zero is waterfall in disguise, whether it's evil or whether it's actually common sense. What we did in our sprint zero was very simple. We learned about the white label e-commerce platform we'd be using, valuable learning. We learned about the users. I was not familiar with luxury ready to wear customers. I wish I could buy 5,000 pound handbags every day, not yet. And I got a little bit of time to organize the UX design flow, not to do the design upfront. My aim was I will not do the design upfront. I want to, always up for a challenge. I want to go and figure out in the cycle, in the scrums, in the sprints that we're doing how to make UX work. I was ready to work evenings and weekends if it wouldn't work, but I'm like, I don't wanna do big design upfront. I wanna step away from this because also there's way more we need to learn in terms of the platform. Now, we had new to agile customers. So the client was very new to agile. They did not know it, they did not understand it. They were kind of going with it because we were taking them pretty much by force. Telling them how awesome it would be and how great it would be and how it would be the best way to collaborate with such model with them in Paris and us in London. And we had always making it difficult. An external graphic design team. And that external graphic design team was another agency and they were also new to agile. So what did we have to do? What did I have to do? I was the most knowledgeable person about agile. Remember that I had just done this role where I had undertaken product ownership responsibilities. I was still working my knowledge. I'm keen and I was going out and attending events. So I had to educate those people. Not as a coach, not as a trainer, but we had to educate them. We had to educate my internal staff, my internal stakeholders, my colleagues and the cluster. We had to go from invisible, sorry, from visible to invisible work. Now, what I mean by that is the only way we could keep that customer engaged, and they were a bit like a three-year-old, very short attention span, is to give them something tangible early. And I wanted that something tangible, not to be wireframes. I wanted to be as early as we could, something that looks like the final website. So the way we did this, and this is how I use that big sprint zero to plan the UX work, is I said, well, the easy pages are the ones that have been done already because the design team had done a lot of, that setting the design, the design was set in stone. So we knew the grid pretty much. We knew the colors, which I don't care about. They knew the typography, which I didn't care about as well, but we had kind of the grid. So I could play with this and I said, okay, let's get easy pages, easy content pages. In e-commerce, the easy pages would be the contact us, would be a bit of information, would be FAQs, this kind of stuff. Not the product page, which is incredibly complicated, and potentially the homepage. Homepage is actually a lot easier than we think, but we spend way too much time on it. So I'm like, okay, let's start with those easy pages and let's just put those templates up. And I said to the dev team, like, I just want cosmetic. I don't care, it's not plugged in in the end. The customer will not know. So let's just put those elements in place. And in the meantime, it's buying us time to figure out the invisible. The invisible being in UX, the flow between the pages, the experience that we want to give. And remember, this is a luxury ready to wear. Like, luxury is the staple. Like, it had to be premium. It had to echo the experience you've got walking in those stores. It had to echo the space, the calmness, the perfection. We couldn't do messy. We couldn't do haired. We couldn't do go buy, buy, buy, but we still had to engage in to buy. So in the first print, all we did is build those easy, literally was cosmetic, but just the front of those pages so that by the end of the first print of two weeks, in the demo, we sat down the client. We sat them remotely. We had to reschedule twice, but we sat them and we showed them stuff. And they were just gobsmacked. They were like, oh my God, you've done so much work. What they saw was just literally modules on a page. Nothing was plugged in. It was all dummy data, dummy content, no database plugged in, nothing at all. But it looked like something was there and it gave them confidence in the process. And we made a huge win that way. In terms of UX, I had made a huge win by giving myself time to design those tricky journeys, which I really needed. I needed to think them through to make them excellent. So we went from very visible work early on, very front-facing modules, a bit of dummy copy, those pages that they wanted to keep. And then it bought us work and it started the questions and the discussion. We needed to get into the trickier work. It bought the development team time to get the invisible, the plug-in work done as well. The next thing we did is that we used the demos not just to showcase our work. We used it to sell the process. Remember, it's very new to clients, very new to our clients, very new to our designers. I wanted to demonstrate to them every single step of the way that it was working pretty well for them. That we were delivering results, that we were covering ground. We were uncovering what we didn't know and we were building shippable elements that were ready for implementation as much as we could. And finally, I discovered and I applied the fact that UX can work in an iterative fashion and I could plan the work. So I had that level of ownership that let me do this, I'll be very clear. But I could plan the work to give me time to think through the tricky elements and I could just churn out the easy elements without getting bogged down in detail. And then I had a third option which was to ship early a UX element but call it a UX debt. Saying this is not finished, we will finish it later. I'm okay to push it out and we ship it in this rough state right now but there's an absolute UX debt in there and I will call my debt on that or you will see. What I learned in there is that you can still do good UX in agile because that's one of the flows I created for the checkout process. I needed to create that flow. It took me about three weeks to get there. Three weeks of iterations, about a sprint and a half and I delivered early. I remember I'm trying not to keep my stuff and deliver it all on the last day. Just keep going. So three weeks of working on it because I needed to understand how to take that white label which was a bit rough on the ages and give it the polish to give the experience of how to place the modules, how can we play with the modules within the checkout to make it the smoothest, most luxurious experience ever. The dev team just loved me for this because I had cracked down the modules. It was placed in a way they could build it. We had worked it collaboratively. The fact that that schematic is perfectly aligned is because I was groomed to deliver beautiful designs. It did not take me a long time, okay? I use Visio, I align stuff, chop, chop. It's done, align on the grid. That's all it is. It looks a lot more polished but it's very simple. The work that was behind it, the iteration, was the real value and I was able to develop that over time. And there's also something else with UX which is the continuation of my UX career. And in UX, we are hired based on our portfolios. Now in Agile, we value a product that's shipped over documentation. And I'm always the one, if I can do it, if I can explain it to you as a doodle on napkin, I will do that. I'm not interested in spending hours on software doing crisp documentation. I want to get that product out. I want to get it with users. I want it to change the world or sell handbags depending on what we do. However, I got to see that I can implement that in a way that works and I've lost the flow of my thoughts. During the right documentation but I also need that documentation for my own career. I need something tangible of the work I have done to sell myself for the next job. And I think that's the point of, what's one point of tension between UX and Agile is the fact that I need the documentation and I need it to look good because otherwise I look like a slob or I could go and remake my documentation and polish it outside the project. It's a little bit dishonest. It's not really the point of a portfolio. But you can still do good UX. You can have work that withstand the test of time. Now remember, that piece of documentation was also polished that we could reuse it, sprint after sprint after sprint and refer back to the process and its order and view those invisible steps that we could not click through. So the conclusion is, for me, from that first experience from that whole set of work, sorry, is that UX is not naturally easily chunkable or iterative. User experience is designing an experience, is designing emotions, but it's also designing flows. The link between elements, the link between information, it's organizing information as the part that's information architecture. It's involving users and user research and testing with users. And that doesn't naturally call for chunkable or iterative work. The way to make this work is to build bridges. To let the bridges be built and saying, okay, the ideal flow, I would spend enough time with users to understand what they want. I would synthesize my learnings. Once I've got the understanding of the problem, I can understand the solution. I can explore the solution with the technical teams. I can explore the solution with the creative teams and with the client. We can come together to the decision of what is the best solution for the problems or the needs that the users have that align with the business objective, that align with technical capability, that align with the ambition of the brand. But we need to build those bridges. Building bridges takes time and it takes effort, but that's how you make it work. The next thing is agile does allow for great UX. And I spend a lot of time talking to UXers about agile and standing by these words. Yes, you can be thrown into an agile project and you're firefighting and it's ugly, but efficient. But what really makes it work is this common understanding. So agileists understand what user experience is, what the value of the work is, what is the point of the deliverables, how to use those deliverables, that they play in and come in and collaborate in the elaboration of those deliverables. And similarly that the UXers understand the process. They're familiar with the vocabulary. They understand the value of the rituals if you're in scrub. They understand the flow that is behind the Kanban. You can even experiment with pair designing and I've played a lot with that. Not to the full extent of XP, but literally sitting down either next to a visual designer or next to a developer and say, let's just crack it together. I don't need to do it in the back end. We can just point at the screen. You can build the elements. I can feedback as we go. We can agree to the best solution together right now. That creates very efficient products, but it creates even more invisible work. So we're back to that problem of us. How do I explain what I do to get my next job? But to get that capacity for great UX and agile, again, you need to build those bridges and you need to build those bridges towards the different practices within agile. So play with scrum, play with Kanban, play with XP, play with everything that comes around. Find out what works for the need on hand. UX has so many different steps. The moment when you go and test a product is completely different to the moment where you understand the problem space, the moment where you elaborate the information architecture and you need to make sense of the information so that it matches the user's mental models. It's critical. So you need to build bridge and that's an effort from both ways. That's an effort for the UXer to go and involve themselves and learn about the project and the process, sorry, and the practices of agile. But I think there's also something missing in the agile community, which is that bridge back into, hey design, come and play with us. This is how it works for you guys. This is how we involve you in the process. I'm seeing more and more agile come out of the development room, but I still remember that's where it was born. It was born to solve problems in the dev room that were product problems, not project problems. But integrating those design functions and these are not easy functions. UX is not easy. UX has a lot of difficulties explaining what it does because it's so complex and it also encroaches on so many territories. It encroaches on business analysis. It encroaches on visual design. It encroaches even on software design and architecture. So it's gotta play nice and it's gotta find the bridges with everyone. And when I talk about bridges, they don't have to be fancy. They just have to work. They just have to look safe enough and there's a bit of a handrail to catch you but just go and meet halfway. So go and build bridges. And there's one more thing that I learned is you can't build it if it's not ready. And I've seen it just in development where stories get into the hands of developers and they look at it and they say, it's not ready for development. We can't do this. Business, you need to think some more about it. You can't just write, we want single sign on. Yeah, I know it sounds easy because it's a very short sentence but it's not that easy actually. So some stories are not ready for development. Some stories are also not ready for design and they need the collaboration with the business, with the users, with the various actors in the product so that the design can happen and the design can also lead to the development. The design can lead to the execution. So don't build it if it's not ready. Build those bridges. And I meant they're learning bridges, they're communication bridges, they're about making it work. And it's gotta work. I've heard lots of arguments that UX should not be involved in agile. Call it sprint zero, call it big design upfront but we need that space to do our work well. And my argument is, well, agile is not going away any time soon so we've gotta crack it. The UX community has to crack how to work in agile environments. Agile environments as in corporate agile environments if at enterprise level or even just collaborating with the agile development team because if that's their cadence they will be making requests on the design that you have to cope with. They will come back to you with questions every week. They will come back, they will ask you to come in into the demos. They may invite you to the daily stand-ups, whatever the rituals and you have to come and play. You can't just stay out on the other side of the fence and be all fancy that we need the time to think. So that's my bit of a rant but I've left plenty of time for your questions so please fire them up. Yes, yes. So the number of times I've worked in distributed in broken distribution so we had, so that was a design team you said. So that was the weird setup that you very often see in creative agencies. Creative agencies are a weird world, okay? It's not just rock and roll and everything. So the client had decided that UX and build would go to agency one and visual design would go to agency two. That was so wrong on so many levels and it made it very, very hard to work. So if anything, do not break UX and design apart. It doesn't work but we had to deal. As ever, I played with the cards I'm dealt with but that meant that the creative agency thought they had done the work, they had done a lot of design work upfront with no knowledge whatsoever of the platform. They're like, no, these are the designs you adapt them. I'm like, I'm not making calls on that new element we need for the checkout so you're gonna have to rework. So there was a lot of tension because they had to work with the technology team as well. So you wanna set up, you cannot break away the design from the UX and the dev and the more I see, the more agile for me, it's not agile as much as the collaboration between those three entities of UX, visual design and tech need to work together. Otherwise, it will break down. Agilism, yeah. Thank you. Agilism mindset and do you think user experience designers have that mindset because we've been finding it extremely hard to time box. Yes. You say this is creative work and you guys are not gonna tell us that it's going to get over by, I mean, it will be over when it's over, don't tell us. So you're telling build bridges and all that, did you try to link it to the UX community and what did you hear from them? So what I hear from them and what I see from them is that you're absolutely right that Agilism mindset and that flexibility, it's based on a flexibility of the capacity to play with options, but also there's very much a forward thinking capacity of saying, if I do this, is it enabling more work? Am I setting myself up for success in the long terms by stepping on this right early stepping stone? Not every UXer is like this. Remember in UX, you have three main disciplines. You have information architecture, you have interaction design and you have user research. These are the big three blocks. A lot of UXers would be naturally, you see trends that they're naturally more inclined for one of these. They're strong at user research, if they've got that empathy, that research skills, that neutrality. They're very strong at interaction design if they can play with minute options and position them. And there's a sense of perfectionism, which plays quite well with software teams and visual design like you wanna get it right. But the information architecture is the core skill. Information architecture is about making sense of the world. And the people who are very, very strong on this and naturally they view the world as elements that make sense that fit into one another. The people who are very strong on IA may struggle with the parcelization and the iteration process. The people who are very strong naturally on interaction design and have that mindset will struggle with delivering with the iterative process and delivering unfinished, imperfect work. So you've gotta find amongst the designers the ones who have the right mindset. But I would similarly say that agile is not for every developer. So the time constraint in itself is, I think is a healthy constraint. We need those cornerstones to give us a healthy play space. But it's more about understanding enough of the rules of the game to decide if your natural way of understanding the world matches it. Not everyone is right for agile. Agile is not right for everyone. And also agile is not right for every project. So if you have a massive content to organize, you may can ban it, but you can't scram it. You can't time box. Like you have, you need a massive time box of three to six months to review all that content. If there is, if you're looking into, transformational experiences that impact emotions, calm down people, help them deal with grief, or a lot of the medical apps. Like similarly, you can't go too fast. You need to understand enough. So it could be sprint zero. It could be discovery upfront, which can be run separate from development to a certain extent, but you've gotta play with what you have. Does that make sense? Or is Agile the key to relays with a much easier price? Yeah. Two weeks or two weeks? That's a good question. So the cadence that we had, most of the sprints we had, we often operated in a mix of scrum and a bit of everything else. Very often two-week sprints. I have worked on a very separate project at the speed of lightning where we had 45 minutes of sprints. That was rock and roll. Just for two days, it worked very well. But generally two weeks. And by the time I was at re-level, I understood enough, and I had mastered at UX as well. Like I had ramped up my UX skills over the years. I had that knowledge and experience that enabled me to parcel the work to help appeal with prioritization, but also to break down the stories at sprint-sized chunk. And some of the stories I could do independently of development, some of them could go into development. The same sprint, it really depended, it really depended with the product. So you've got to play with options. And as ever I take, for me, agile, it doesn't work on day one. We make it work over time. So the retros were a critical time for understanding if there were tensions between the developers and UX and to figure out how we could solve these tensions. And I had heard in retros, oh, UX is too late, they need to start ahead. So we started being, one sprint ahead didn't work. We started being the same sprint, it didn't work. And I think the secret is to understand the impact of the story to the development, to decide if that story is done as sprint ahead or is done in the same sprint. So it's not this rule that what UX does is built in the next sprint. It's much more subtle than that. Thanks. So testing with users is the trickiest part. What I've always been against is massive tests, massive research with users at the end of the project when you put the final product just before it goes live because it's the best way to pay a lot of money to get very bad news. So one way was for me to go and do ad hoc testing. So in UX we have this term of gorilla testing which is just going out and meeting with users where they are, maybe in a semi-artificial environment like a coffee shop but showing them elements of the product. And I was particularly doing that with very early stages of the UX. I would show them sketches, potentially wire frames but testing the product more often than not was not done the right way. The teams that I know that do it well integrate testing on every sprint and quite often the cadence is to get three users in the building every Friday or every other Friday. The team can watch what's going on. It is a semi-artificial environment that you're taking them away from their usual setup unless you have them to bring their laptop, they fill a bit under observation but you get that rapid validation. Testing with users and integrating this in the development process is the trickiest part because it's the one that's hardest to sell in the early days of product development to a business that's not user centric. They don't understand why the expert doesn't know better. And I'm like, I'm only as good as what works in the end for the users. I need that validation, we need that validation, we need to learn early if it doesn't work. So it requires selling the testing early to the business and it requires running it at a cadence that enables integrations. Another recommendation very much is get at least one or up to three users under observation and immediately take those nuggets and inject them into an expert. And if there's a massive problem, if you uncover a huge problem like you pull the alarm and stop everything and you do a deep dive to understand what is not working with them. And it would be not a feature problem, it would be a product problem that people see the product and say, I don't want this, like I would pull the alarm system and say, deep dive, we stop and think, are we still in business? I answer a lot, it depends because it really depends with the context you're operating in, the team you're operating in, the type of product you're in, but also the skill set on board, the ability of your user experience person to get those nuggets of insights and to analyze them in a way that they can be implemented early and also to make them bypass the business validation process. I need to have the ownership to say, people are not seeing this button, I'm not going to discuss for hours on end with the business to decide whether they should see or not the button. We're gonna tweak the contrast, we're gonna tweak the size, we're gonna tweak the positioning, we're gonna change it so that it performs, it does its job. So I need that ownership. So what we did, and that was another team, we had a product that was built for customers in Brazil who were based in London and New York. So going to Brazil was an expensive trip. We decided, we got actually quite naturally to a point in the product where we realized we needed to know more. We realized we did not know enough about our customers to make those product decisions. So the product that owner, the technical architect and I flew to Brazil and we met with those future users. I spent a lot of time interviewing them to understanding their context. So together those nuggets of insight that would help us drive the product development. And then we showed them the product as it was in early days. It did a couple of flows, that was it. And we had waited way too long to do that. We had been very isolated. And by the time I had finished with the, so I would start the hour with about half an hour interview then I would hand over the tablet and I would explain what the activities I'd like them to do. By the time I handed up the tablet I knew it wouldn't fit their needs. But still we went on with it and we learned all the things. We learned the one thing we did is like we did not involve the user early enough. We built way much more than they needed and we built things. It didn't need to, we created waste. I'm very big on lean. So the more you involve your users, use remote testing, go gorilla. And I always say to UXers, if the environment does not officially allow it or condemn it, like go out and do it on your own. Do it on the slide, but bring those linings. So user, so AV testing, I've only, very often the platform the product was built on did not enable it. The other problem with you with AV testing is that you need enough volume to get a significant difference to get that volume you may need time. So I engage in AV testing with mature products that were out because we had strong arguments within the team. I'm like, okay, we need to put it on AV test. But very often I don't do it and I prefer to get rapid validation on a single element and get confirmation that it works or doesn't work rather than do those big, AV and MVT you need the technical platforms and more often than other platforms. Pen and paper. So when I did this, remember, we're not about documentation, but if I had done this graph and it's pretty complicated, it's got conditions, it's determining, this is a page, that yellow box, these are modules on the page. So you would view module one, depending on your condition, you would view module two with several possible views. So to get that complexity, I needed it to be polished to make sense to the viewer. Yeah, absolutely, I scan. I sit next to the person, I do doled on Google drawings. I will always start fairly low definition. If it works, I will lower the definition even more. If it doesn't work, I'll empty it, but I don't start at that point. That's a waste of my time. I'm aware of time, 11, 18, we were supposed to finish at quarter past? We're three minutes over. I'm gonna be around all day. You've got my details. I'm always happy to chat and help, that never works, does it? Always happy to help teams work well together. I think UX makes better products. I think developers make better products, so we all really need to work together. Thank you very much for your time.