 First thing I'm going to do is say hello to Bangalore. I've been to India this is my eighth time. Most of my time spent in the north. It was really exciting to come here to the south. I think this is considered south India. All right, yeah, I'm sure if anyone from Chennai or Tamil Nadu, Kerala, I don't want to step on your toes because I know that's really south. But anyway, and I love the train system here. So I just want to start with that real quick. So I want to ask everyone a question and do you work with co-located teams? Like how many works with teams that are either in your same country, same state, or around the world? And how many of you have worked where your design team is spread out around the world? All right, so hopefully you'll have a better kind of experience than I have because what I want to talk about today is not necessarily a love story. It's more like some of the problems and things that can go wrong than some of the things that can go right. So a little bit background on me. Use a researcher, a product strategist. I live in Seattle, Washington. Spent time in these places significantly. I'm currently, I have this title of T-Mobile, which is a telecom company, but I'm actually a researcher. And they don't have this title yet. So anyway, not really a designer. And I love these things. This is the greatest invention in the world, Globe Jaman. So yeah, if anyone has Globe Jaman, please. I'll do a dance for you. So I got into my other background before technology. I was a chef. And I worked in a couple of restaurants in New York. And one of them was near a restaurant that Anthony Bourdain worked at. So we didn't have the same friends, nor the same cocaine habit. But at least I was a chef. But anyway, I wanted to technology because a friend turned me on to the show. Did we know the show where these guys are from? They're called Cybermen. Anyway, it was the idea of AI, machine learning, and just technology in general. And that scares some Jesus out of me. I don't like technology. I'm sorry for all you guys. It probably do. But I want to learn how to master it. And so one of the things I got into was if I gotten to be a designer or a researcher, maybe I can help control the machines. And so why does that matter? Well, for me, machine learning, and some of the case that I'm going to talk about today, has to do with the fact that we have a lot of opportunities and a lot of designers to create experiences with a lot of what would be considered science. And some of that can be in environmental science, and some can be in machine learning, and algorithms, and data scientists. So what we sent out to do in this project, this thing is kind of weird, was to create a predictive analysis application using BigDead and AI to help petroleum engineers better understand how to manage field health. So one of the things that we worked with, along with the predictive analysis patterns that they would use, was we started working with predictive UX. Let me know what the predictive UX is. OK, so that's basically the definition, but it's kind of this. I mean, this is a perfect example of Google, predictive UX. And so one of the things we were looking at with our product was to help the user through, obviously, machine learning algorithms and data science, but then also surface UI that would allow them to make better choices. So because a lot of our end users were not technical at all. So everybody knows this guy. So the other second part of my talk a bit will be Agile Lean. And Agile, this is the first thing I think of when I hear Agiles, well, I know I'm messy. Or Serena Williams, a famous tennis player. And this Agile UX is kind of a new thing, probably not so much anymore, but the idea of how to design in an Agile environment or team. And a couple of people I've talked to so far, since I've been at this conference, has talked a bit about Agile UX, but then also Lean UX. And so how many people feel that they effectively do this in their practice, particularly this last one? So this is a quote about the plan. And that's what we're going to talk about today in the case study is, come in with a plan, eventually, Mike Tyson, right? So with that being said, this is Agile versus Lean. So a lot of people probably, at least for me, my bosses, my product managers, PMs, they're always talking about Agile. And then we come along as designers in your research and say, well, no, Lean. We want to focus on people. We want to focus on measuring experiences and our methods and creating an MVP versus a lot of this other stuff that Scrum is either rugby or it's Agile. There's no, to most people, it doesn't matter, right? So onto the problem. So I like to call this or what we call this was a 17,000 feet problem. Gain at proven reserves of oil is really expensive. Gain at unproven reserves and new reserves is even more expensive. And all the oil fields in the world are dwindling. Now, when they'll run out, I know, but I'm not going to start any rumors, just work in the oil and gas field. Don't worry. We'll all be driving lots of cars for a while. And the biggest problem with oil and gas and maintaining wells is when they become shuttered or they stop working. And that can be a really expensive problem as well. And so what we started working with a few Gulf oil companies was to work with petroleum engineers and hardware creating all these sensors. And of course, we're all heard of internet things by now. And any given well, they can be almost several hundred sensors. And they're constantly sending data about everything through the upstream oil process. And so what we wanted to do was we wanted to create visual tools to help the well engineers in business make the best decisions for both profit and then worker safety. Unfortunately, we set about with our client to make a one-size-fits-all application because they wanted to build it. They were using one Gulf company as an example. And then they were going to sell it to all the rest. So how do we fit Lean UX into our process? We started out with a really cool co-located team around the world. And I'm totally frozen. That dude rocks. And I was like, Iceman on speed. But we had three problems we were trying to solve. We needed to get the requirements. And we needed to understand what the customer needed or wanted while they were still trying to figure that out. We had geographical issues giving our SMEs that were spread all over the place. And we had a very short deadline, like six weeks to come up with the design idea. We estimated, based on our previous experiences of just being designers, it's probably going to take about three times that. So what we ended up doing was we split our design team. So we split it regionally between Chennai, Houston, and Dubai to hit different SMEs and get the users faster and develop faster. Because we need to rapidly design. We need a rapid prototype. We need to iterate fast. And we wanted to do around the clock, which sounds great for business. That was one of our selling points. But for designers and humanists and people of empathy, we realized that our designers in these different locations had different experiences, different life goals. They could bring different diversity to the table. And we figured that would make it stronger. And so we had the team make up. Just there were about three designers in each location. Our biggest thing was to figure out who was going to do what and how we were going to do this point. And we had also concerns around cost and logistics, traveling, visas, things like that. And so we figured out who was the fastest person that could get into a particular theater the fastest and then work through the iterations. Sounded pretty good, right? I mean, it's like we got a rapid, cool team. Like Incredibles, we're doing all this stuff. We got this process and all that great stuff. Well, the problem was, is that in this whole idea, we actually forgot to tell people what they're supposed to do. And so we handled the research part OK. But when we got to the actual design part, we started wasting. People just kind of went crazy. So everybody was working on the same thing. And we didn't really coordinate that. And so we were kind of wasting a lot of time. And part of our also problem was that the features with the MVPs were being added and subtracted daily. So we're trying to work on that. So what we ended up doing was we had this problem. Like if everyone's seen this movie, Jeff Goldblum has the perfect plan. Save the kids. Plan goes too well. And well, he's running and screaming, as he says. So that's what we need to do. We need to get under control. So we just called the time out. Designers went on strike. And we said, we're not going to do any more work until we work the SMEs and the product owners and figure out what exactly you want. That didn't go over so well, as you can imagine. But our first problem to worry about was they wanted to design this application for all multi-platform, omnichannel experience. And that just doesn't work, especially in six weeks. So we ended up choosing the web. And how we solved the problem of this design of randomness is we put some people into a room. And we started to think about this. So is everybody familiar with the release train map? Like eviteration of design? Obviously, that's where you're trying to get to, but it doesn't always work that way. So the one thing that was going really well for us was user research. So we decided that, OK, we can actually go out and find the things that people need or want, maybe faster than the business can. And so we took that risk and that gamble. And the most part, it paid off. We understood what the heuristics and what people were doing. And the one thing that we got to really quickly was all these oil platforms around the world in disparate conditions. So some are in the North Sea. Some are in the Gulf, obviously hot, cold. There's day and night shifts. So there are a lot of things to think about in terms of our application that way. We had rig workers with gloves on. And we ended up coming with technology that we'd sewn to the gloves. So they wouldn't have to take their gloves off to use the application. That's just some of the research stuff. So we adopted this model of participatory design from Leo Fishberg. And we decided we'd just start iterating and sketching ideas as fast as possible and just get them in front of users. This worked out in a way where we set a core team to make the framework of the application. And then we got our other people to iterate on these internal points, the graphs, the data visualization elements, things like that. So we did a lot of prototyping. We did paper prototyping. We did Oxford prototyping, a little bit of envision, pretty much every tool out there. But the one thing that we did that worked out really, really well was this idea of just quickly white boring ideas in front of business owners, SMEs. And so those are some of our sketches of just quickly doing this. Now, the downside of this was we had the upside of rapid prototyping again to the point. The downside was if you have a diverse team spread across the country, not everybody in the world, not everybody can see us at the same time. So now we solved that just by using envision. We just copied those out, photographed them, put them in envision, and just kind of caught everybody up. And then once we had built the framework, then we were able to sort of seamlessly divide up some of the well diagrams, mapping, things like the internal stuff. So we got into a cadence and about four weeks in, out of six weeks. And, you know, we started to get into the features and we started designing.