 You see, I, for speaking, had a big timer board right in front of your face down on the floor. It's like, it's nothing like pressure. We'll get started right at 10.30. I think I have more than 45 minutes of stuff, so I want to try to make sure we don't. I don't know what to say. Eat. Okay. I'm already getting asked how I say my name. How's that pronunciation? I'm a principal in Sun Guard Advanced Technology Services, which I'll explain a little bit after you don't want to waste the time in that. I'm also here with Ravi Koth. He's up in the corner here. He's a counterpart in crime with me and that group. I want to talk to you today about experiences that we've had using Lean UX in capital markets projects. We're with Sun Guard Consulting Services. We're consultants. We go out. We have a specific focus, me and Ravi, in Advanced Technology Services with a bunch of different technologies. One of the things we've really been working on for the last couple years is being able to rapidly composite applications to be able to deliver them quickly and do the right thing. We've done that for a few years up until last year. Well, I'll get an insight. Basically, we focused on wealth management solutions for quite a while with the processes we were putting together. And in last year, I had the chance to go out and finally target a capital markets project with the things we did. And honestly, we learned a lot out of that. So this is kind of like a lot of what did we learn? How did we do it? Kind of gauging the crowd. I mean, who here does Lean? Whose experience with Lean UX? Anybody work with it? Wow, almost nobody. Nobody raised a hand, which is good, I guess, because then you get a dose of what I'm going to talk about here. It's actually interesting that Keynote this morning really set this up pretty well because I'm going to talk about a lot of the same things that came up. In the Keynote talk this morning, except how it applied to specifically the project that I worked last year, evolving this out, not any specific project details. First, I got to hide the client and all that stuff. But how we've applied those and the things that we learned with that. So the goals I have here are just really to explain to you the adventure that we had doing this through last year. And it also rolls up all the other stuff we did like in wealth management and experiences. I want to, some insights, hopefully on how to theory of this Lean and Lean UX got applied as we went through it. And key realizations that we've come to over many projects of trying to do this. There are some things we learned last year a lot that helped us solve some problems and they're key things to be taken away. And I think the Keynote touched some of them, but I've got specific examples. I'm not making it specific, but ways of showing how you can really use the Lean UX process to quantify success in a project, at least in capital markets. Anybody here do capital markets work? Okay. One, two, yeah. So that's one of the things we'll get into. I mean, last year I spent most of the time with the major investment bank in Manhattan working on desktop trading systems. And it's the kind of environment where it's, you know, you don't have time to spec things out very well. But the trader wants software done tomorrow or yesterday to help you out with it. And there's definitely goals and accountability that need to be put into place. So unlike even with like a typical Lean project where you may adapt and do it or agile, do it or at least this gets a little bit more, I don't say stressful, but it might be stressful, the word, in being able to deliver quickly. So that's one of the things that we looked at. So the agenda, what I'm going to kind of step through here on is real quick about Sun Guard, some personal history with agile Lean UX. Then real quick, what is some Lean UX? You haven't seen it. I just want to bring up some of the primary concepts in this. UX, go over UX, how we applied it in capital markets and maybe some wealth management. We did it in both. But the capital markets was the most recent stuff. We're still doing the wealth management. The lessons that we've learned over the last two, three years doing this. And things that I'm seeing from the things that I've learned, how I'm going to change, how I do things in the future. Because if you look at this, the Lean UX process is about also learning how to do your Lean UX better. So just quick about SES, we're the largest private company, software company in the world. They're a consulting wing. We do a lot of work in finance, energy, insurance, higher ed, benefits and stuff like that. Like I said, me and Robbie work on our advanced tech line. That has offices specifically in NYC, Houston, London, Bangalore and Pune. So if you want to talk to us about any work getting involved, let me know. But that's the plug. No more plugs for that. We look at a lot of technologies. UX isn't necessarily a technology, but it's a new way of putting the things together. And we give guidance on that. So again, I'm Mike. I've been worth Sun Guard for seven years, building out various different projects for energy, wealth, commodity, trading, you know, capital markets. I've always had an agile experience. I started picking up agile when I was just trying to figure it out a long time ago, in like 2000 before they called agile agile or things like that. So my interest in figuring out how to do this process goes back quite away. Robbie works with my group and we work together a lot on these methodologies that we put together and putting solutions together for customers. We're constantly looking at how we do this stuff better over and over and over again because we want to get better at this. So quick stuff. You know, it's a more specific experience that I think comes into play. I was looking a lot at 2009 to 2010 around composite application frameworks, which I think helped out with the Lean UX stuff a lot. And then we're applying it the wealth management solutions for a while. And then last year we got a good break to go in and work with this in capital markets at a particular customer. So if you haven't seen this book or read it, I would recommend going out and getting it. I picked this up last year, early last year. I don't know when the copyrighted of the published date was, but I first came across me about April of last year after I was a couple of months into trying to start this project. And it's a really great resource in trying to get your thoughts organized around what this Lean UX things ends up being and starts to give you some ways of thinking about the process. Because up to then we were really just doing agile, various different flavors of it, just putting in better backlogs and trying to implement features and map it to sprints. And we ended up actually having some issues with that, which I'll get into near the end here, which just helped us solve. And then we went a little bit further past this. There's a nice picture in the book. I like this because we do this a lot. And this is in the book and there's a quote in there that I like is, Lean UX enabled at GE being able to build clickable versions of their applications in days instead of months. Get things out to the users to validate that things are being done correctly. And getting further buy-in on that. That's actually one of the big things I'm going to focus on here. That's where I think Lean UX really comes into is its own is being able to get out and get buy-in from the users that you're doing the right thing for them. So in that book he has a general process model that he goes through where things like declare assumptions, do feedback and research on the users, run experiments to see if it's a viable idea, and then create an MVP. That came up a lot in the conference morning. I know the lean people probably know what that is, but anybody here not know what an MVP is because I'm going to tell you in a little bit. It's actually kind of the crux of some of this stuff. But another picture I liked in there was, and this is for the case he was doing is, wanting to go out and find a 360 degree view of the customer and what the customer wants in the software to enable their job. We work with traders and investment advisors and things like that. So there's specific things they want to add. If you're going for a consumer market it's going to be different and stuff like that, but just as he talked a lot about how you can get in with the users and do different types of sessions with the users to go through putting together mock UIs and driving out functionality and the real capabilities that you're looking to go through. And then he'll talk about being able to map lean UX sprints, like sprints and themes in an agile process. I think the key point he gets in there with is that you have this green block there called sketching and ideation or however you want to pronounce it. But it just is you're going to be adding in there in every single sprint, a time where you're sitting with the user and doing these sketches, wire frames, simulations, constantly taking the feedback to the users, taking what you're building to the users to show them to see if it's trying to support their business and what they're trying to accomplish in their job. But looking back on this though, my summary on that is kind of well, this takes practice. Reading the book didn't really help you when you got to be on the ground and do that and that's what I want to give some tips on what we did there when we did that. And another thing is I want to say is lean UX isn't just UI. I think there's this common misunderstanding about this, that it's UI work, it's graphic design, it's things like that. It's really, I mean, you could look at this from top to bottom from the UI down to database queries aren't fast enough. User's not having a good experience if the data isn't getting to your pretty UI fast enough, which is one of the problems we've had that we learned that. It's more than just that level. What this really gets to that the process of lean UX is that creating a common understanding between users and those who enable the user. I like to take the team that does the UX, refer them as enablers of the user to get their stuff done, which is very important. And a process by which they go about defining the goals of the business and how it gets implemented by the software is key. So in 2013, one capital markets project that we did is, in summary, I tried, you know, I could write a thousand things about like why capital markets is capital markets for software and why it's difficult and stuff like that. For this purpose, I just demonstrated I wrote down three. One, traders want software tomorrow, if not yesterday, or why didn't you get it done for me last year kind of thing already. And they want incremental improvements regularly delivered. Okay, well that's agile, but you know, they've been working with that too and it hasn't worked too good for them. They can't wait for software to be built because every single second that they don't have the software to do what they're trying to do, someone else has bought that commodity and I've lost money. But unfortunately, they also want to have a long-term strategy. Where are you going with this at some point in time? How do you define that? So I'm going to tell you how we went about, you know, figuring all this out. You know, specifically tying in an example I have is some challenge that we saw that were maybe a little different than like in the wealth area or, you know, more, you know, web-facing customer portals is, you know, the workers, their processes for what they do for their job are known, which, you know, when we look at wealth, it's easy. We have a good understanding of that. It's a pretty standard model across it. But with the capital markets issue ends up, the workers have the processes but their systems that they use don't implement their processes. They have typically five to ten different systems that they use all day long to do different things. And a lot of times they end up actually, I have to enter a trade in six different systems. And then make sure I entered it exactly correctly in all six systems. Otherwise, you should get a notification that you screwed something up, except a lot of times you don't get a notification that you screwed stuff up. So, yes, you end up, you know, they have a lot of scenario where they're continuously monitoring multiple applications. They have high context switching between these things. Especially in this project, we were looking at, like, unifying an interface for all these systems. And actually, technical real goal was one of them was old. Nobody knew how to support it with C++X windows. There's going to be a hard date to get rid of this system. We want you to tell us how you're going to get all the users off of that system by that date in seven months, and build an application that's going to provide all the functionality that they needed out of that system. So, in a sense, that's kind of the business goal. There's some more details to that, but ultimately it got down to that. But that gets into how do you elaborate and figure out what to do and elaborate what that's going to be in that time frame, is what I'm going to be getting into in a little bit. And it gets into a little bit, it's like distributed UX, in my sense, because, you know, all these apps run across different roles in those enterprises, different users, they set it as called desks, which are trading desks could be different parts of the same building, different offices across the world. You know, when someone does something on one desk, people on other desks need to see it. So, and they all need to have an experience that ties up with all this, because we're trying to look at building something that works across, you know, these enterprise type of situations. And need a lot of real-time collaboration, escalation, approvals, collaborations. And another thing I'm going to tell you is a lot of these organizations already have user experience groups. I'm going to talk a little bit about that. They generally have put together, they've realized they need to have user experience, they have a lot of people that do this, but they mostly end up being like Photoshop designers, not people who really can put software together. So, these are some of the things that I wrote down that, you know, as looking back on this, that came up that, you know, or things that came out of beyond like that book I showed, you know, things we've kind of learned. You know, tight specification of business goals. They know exactly what needs to be done. Or they know how to do it, but they don't know how it should be done. Okay? How it could be done. They want roadmaps and timelines. You get limited but voluntary access to users. So, they were greatly willing to work with us as long as we went and showed them stuff weekly. But we can only do it like weekly. We had to go in several groups of years. I mean, these guys are busy all the time. But they take time for us, which was kind of nice with this. And as long as you're showing the business value, they were keen on going through this. So, we hadn't done UX before for CM customers. They hadn't done a project themselves. That's why they looked at us because we were building the skills in it. You know, they want to prove the concept that it would work out. So, in the end, it's like some of the things we learned out of this, UX is more than UI. I already kind of mentioned that. It's more than that. It's really a way of thinking, if you ask me. Business goals and minimum viable products are absolutely key to getting things done. And I'll explain these and how we looked at it. The MVPs and MVFs minimum viable features are the stuff that you need to get done for the users. You build only the MVFs that are needed to solve the business problems. You look at UX patterns. You know, how does the user want to interact with the data and execute business actions upon that information? And you can put those together. And I look at those as, you know, how the minimum viable features get mapped to technology. So, and then you need to work with building multi-generational plans that show what are my features and how I'm going to implement them over time. We tended to like to use this term, multi-generational plan versus phase sprints or themes and stuff like that. But it's kind of like that. One of the biggest things, and it came out in a keynote this morning too, is vision. This was driven home to us actually by the client, and we got to really like it. And it's something we didn't do before. But the vision is, you know, how do we create a common understanding of the plan of what we're going to do? This is a fuzzy thing. I worked on it a lot. I've got some things in here to tell you how I kind of figure out putting together a vision for what a project like this should be. And the MVFs, importantly, provide a traceability of code implementation of business goals. So a lot of times, I'm sure you have all probably seen it. We've done it ourselves because we're human too. But in the end, you delivered an application which was built off of features but didn't solve business goals. Everything's there, but it doesn't help anybody do anything better. So it's okay. So the MVP, the MVFs are, you know, working in a model such that you're thinking that you're going to deliver what is minimal to, but exactly what's needed. I like this. It's on the next slide. There's a nice picture I like. But you put these together through interaction sections with the users, understanding what they do for a job, and finding out exactly what are the tasks that they need to complete to get their job done. Okay. Like it says here, your user needs to validate user feedback. And it's really, it's actually the smallest item that can be used to build testing of assumptions of the project. I mean, eventually after you shake these things out, it's what you're looking at. This is what we're going to build. And MVPs don't have to be code. As a matter of fact, I would say a lot of times they're not. I like looking at MVPs and MVFs as the features, and then you worry about how you get it implemented or coded at another time. Like I said, they're used to learning about the experience of the user. So, I like this picture. It's like, I started first talking MVP, minimal viable products around Sun Garden stuff. I had a lot of people freaking out that, you know, don't mention that to clients because it's going to give them a connotation. You're going to put the least amount of effort into, you know, deliveriness and not really care about the job that you're doing. My client did not think that at all. Once I started mentioning this, they understood immediately what I was talking about with minimal viable products because they've all been burnt by the software integration company that comes in and builds way too much, and then it doesn't do anything. So once we started talking about this, it became almost like a daily thing we talked about, the MVP and the MVF. Here's the strategic focus on how we get the product done. And then I talked about too much with patterns, but, you know, and the UX pattern gets into, like I said, how the user interacts with the data and information, but I really consider them a means is once you have like an MVF, it's how am I going to go implement stuff. So if I want to, you know, a pattern could be like display most recent trades in real time in a grid or something like that. When clicked, go to a screen where you can edit it and do some other actions. But then from that pattern, you can then say, well, I'm trying to put it on a desktop or a mobile device. You may actually have different ways of putting the user interface together, different ways of getting the data to the screen. So you built what you understand as the feature. You have the pattern on how the user wants to interact with the information, and then you can take those and figure out how you're going to implement on a particular platform. And from that, shake out your actual backlog for development and things like that. So our process, these are really, you know, trying to condense this into one slide was interesting because there's a lot you want to say about this, but this is what we ended up kind of doing is as a process, and this is an iterative thing, repeat over and over and over again, daily, weekly, different stages, but one is understand the business, which is basically getting into the head of the user and understand what they need to get done. Define the business problems that they're having. I have a list of some problems and I'll list of some goals later and show how I tie them up and figure it out. What are the problems that they're having? You can't define the problems if you don't understand the business, right? The goals. You found a problem. What is the goal to fix the problem? Then start defining your MVP. Some people use MVP as the whole thing or individual items, but the MVP, the MVFs that are going to meet the goals. Based upon working iteratively, constantly with users, what are all the features, the things that we want to, try to stay away from the feature word, the things that we want to implement in the application to get a mapping from the problem to the goal and having it solved. Then that little box down here called create the software. In Lean UX, it comes out to be a very small part of the process. It's obviously an important one, but you're using all this to drive that last bottom box there. What is it we exactly need to do? One of our mantras when we went through this is that maybe on here is that we're going to build exactly the right thing. Nothing more, nothing less is the credo on this. That's where we get with this vision. When you go through this process, it was explicitly put together to drive a vision. In pieces has the problem statement, what's the business having a problem with, the goals statement, your list of MVFs that you want to implement, prioritization of those MVFs into the multi-generational plan. Then the vision, we actually built an explicit vision document that was probably about 30 pages long or something like that. PowerPoint, not words. We don't write words, we don't write documents. This is still all the MVPs, MVFs, the list that M plus the software, that's a documentation. This required for the stakeholders to really get this together. I'm going to show you what we did with this. But that vision then shows how the MVFs, you're going to implement transition to business from the problem to the goal and in what time frames via the multi-generational plan that you put together. The team we use. This is generally how I look at it. Three-person team. I generally don't like larger than three-person teams on client and console engagements. Obviously maybe not a shrink wrap thing where you need to build something with more features and stuff, but the roles that came down in this were the UX slash information architect. That's come up as a big word in the last year, the information architect. I've got some slides on each of these I feel need to do in a project to be successful. The subject matter expert, which may be someone who's expert at the domain, the trading, or specifically like in that case, all that particular company works to do trading. They're all different. It trades a trade, but all these companies do it differently and specifically this person may also be one who knows how all the spaghetti that they have existing in the infrastructure already works so they know how to map this stuff into what the client already has in existence. Okay. The developer. I like this Venn diagram because that's coming up here is these overlap and I really truly feel that in a perfect world these collapse down to one circle with complete overlap of completely skills between them, but it's definitely in my opinion that each one of these person in these roles can have some type of common communications bond with the other two persons. Be able to do some of their work and be able to communicate that and on all that, right in that little wedge in the middle, you know, be on the same page of you know, putting the solution together. So the domain specialist, I broke it down into these are the important things I see with them is, you know, they understand kind of the existing process maps for users. You know, in particular, our domain specialist there knew that, you know, the trader, I'm going to give a particular scenario, but, you know, the trader does this, but he's got to do it in six different systems. Okay. Well, that's a process we're going to try to fix. So he knows that stuff. He knows the business we put together, the business problem goals definition. You know, everybody works on it. At no point in time did we ever go to a user or anything not together as three people. So it's very important, I think, to have them all together all the time working on all these things. Eventually at some point you get down and you do your work for the day that you're part, you got to get done, but you're always, whenever you're facing a customer or something, you're always all together because you all have viable knowledge for when the user is sitting there talking about how they are frustrated by what they use all day. You all understand a difference perspective on how to try and fix that. They work to drive out some of the initial MVP and MVF definitions. But like I said, what is exactly that we need to build? And we'll work with getting the multi-generational plans together because I bring up multi-generational plans a lot. It's getting in the capital markets of, you know, I need some software tomorrow. I need some software the week after, the week after, the week after. So please tell me once you've figured out all these things, one I'm going to get them when I can start using them. The UX designer and I tried to really differentiate here between the UX designer is not a graphic designer. They are an information architect as it's called these days. But they have some tasks that, you know, we're very important on a project which were, you know, what's a running UX sessions with the users. So being the key person that schedules and manages and gets people into meeting rooms where we go in and sit with them and we can do interviews of the user about what they're trying to do. He catalogs that, puts together, say, persona definitions. If you get in and you actually will see stuff about personas, but like what is the mentality of that type of person in that role, working in that company so you can understand the user and works with graphic designers to help put stuff together. You know, we started out with paper prototypes. You just throw out list boxes, arrange them on a table. Does this seem to work for you? Okay, yeah, that seems to actually look like you're there. That'll solve the problem right there, right? Well, okay. We'll write that down, make a note, and we'll come back in a few months, in a few months. Oh, next week, we'll try to maybe we're going to bring at some point, we're going to bring in a wireframe. See how you feel about that. So that's the next step. Wireframes and storyboards and putting stuff together. You know, constantly visualizing what we're trying to solve, validate and revising the experience that we've trying to put together for the users. And then building simulations. So you know, like high fidelity mockups or actually functional front ends. You know, and this is where that person can work a lot with the graphic designer on the team and putting some, you know, good look into the stuff. Honestly, we built all our wireframes in PowerPoint and then went directly to like, well, WPF at the time, but you know, layouts based upon that from the wireframes and stuff like that. The developers do their coding. They need to know how to code for all the platforms you're putting it on. This was just a WPF you know, desktop. But in general, if you're looking at this, you know, this person needs to know whatever you're going to target as a device, be it mobile, Android, desktop, web, you know, how am I going to get these wireframes or the patterns implemented onto those devices. The visual design, I put, I actually put visual designers in with developers in my mindset. I believe they're part of that team. Okay. You know, there's guys that just do Photoshop and things. Okay. I like to have guys that have those skills but then, you know, can also create good HTML5 with good CSS3. Can do some XAML and actually put some style into it, you know, in a WPF app or stuff like that. So, but at some point I like it when they can actually push out some code like that. So that's where they got the overlap with the developer and then the developer can work with them and take those things and build real things. Fold up the data we've been mocking in the real system, bolted into that at some point. But I was there. I know exactly how that designer worked to put that wireframe together and we're going to go implement it. And then I think this is important. He's responsible for adaptability through reuse. This isn't necessarily we want to reuse the code from this application in another application. It's as we move from stage to stage and building this and changing the user experience that the code that has been written in the app to this point is able to be restructured easily to represent a different like usage pattern. This actually didn't work out. We need to change it a little bit. So have they built the system right where this new layout came in, you know, the UXIA can come and say this change, we can just turn it around real quick in the display. So and they know the environment. The little picture there, it's a bunch of cables wired together because no, there are no green fields in this environment. You're not building a standalone application. You're going to be plugging into so many things you can't imagine sometimes and knowing the intricacies of this. So the vision part talked about, you know, some of the roles of the people and stuff. So how did we go out defining what we're going to do? Well, the elements of the vision to me are, you know, problem statements, the business goals definition, the set of MVFs, you know, the MVP as a whole, and the multi-generational plan. So I put this in, I'm not going to read every item on here, but this is like we had a number of slides like this we put together for a customer. The big boxes represent like high-level, you know, groups of problems. The bullet items give a list of some more detailed items inside of that. So like in the case, and the one I have here highlighted is the scenario I'm going to show here is users can't multitask. Well, they do multitask. They're just in five different computers. So they can't multitask efficiently. Okay. See, that's why I'm saying they can't see what's going on in multiple in different systems. So that was a problem that we were going to solve. So I go to a business goals definition. So how are we going to change that? Well, we're going to have a main driver of having user effectiveness. It's user experience. So you're trying to hopefully doing user effectiveness, but this is a specific case. It's like some examples here. Eliminate that need to enter redundant data. So we don't make errors in different systems. The one I have highlighted, I'm going to talk about, is reduced context switching. That tied into the problem on the previous page. You know, they can't see what's going, well, they do see what's in different systems. They just have to change screens and waste a lot of time with that. So we're going to reduce that context switching capability for those users. So I just threw down a few generic what I call the minimum viable features that were an example that we had. We had a big list of these that we built over a year, but the desk monitor sees and acknowledges trade amendments posted by traders within a specified period. So if a trader enters something, they need to have actually verified system-wise that the person seeing downstream trades enter from the trader, see them within a certain number of minutes or seconds or whatever the criteria is and can invent those out. Okay. Amendments to trades needing approval are prioritized in views by duration to until they expire. So we're going to when we display one of the displays we put together is here's all the amendments to trades that have happened and we prioritize them by how close they are to needing to be reconciled. And if things percolate up too many things get too close your desk supervisor has another version of our app who sees that someone's not clearing enough stuff out of the queue by the end of the day. We've got a risk problem. So we've got to get this done. A desk monitors, well that's what I'm just saying the whole next time, a desk supervisors are giving views of the other users. And where they're at in their job. And let's say I just made this amendments exposed in all five internal systems will be surfaced at desk monitors in a single view. Getting back to the trader on this desk uses system X the other guy uses system Y anybody uses system A B and C also depending on what type of trade it is. That all these things get brought up to one place for them to see without having to check a lot of things. So if we take these as like the MVFs of the project we did some process here where we went through and we just take them all out and lay them out there. And this will be an iterative process. We define some up front and as the project went on we define more as we want in this conceptually take this take a look at all of them and rank them from lowest to highest priority. You know what is it that you want it need to implement first. I think this came out in the keynote too. What's the important thing to get kind of going and get done first. So just purely going and ranking these like this upon priority then from that break it down in a multi generational plan a sequence of minimal viable releases which the guy this morning uses. So instead of I want to say these aren't necessarily sprints these are when I'm going to release things to the user. We may run multiple sprints inside of one of these to implement these. So you can see here I have like release one has multiple features. We may take a sprint just for a feature. It's not that scenario we really did but conceptually that's what you can do. And then so you break out the releases you know we knew that you know we had to get 20% of the users of that one system on to doing something. You know so we could get those off. So we gave them basic functionality to get that percentage of those users off of that system in like that first phase. Then we knew okay given that what are we going to do with the next phase in the next phase. So that gave us the plan and then I mentioned it when I entered here that you know we had issues before where we delivered software and it wasn't exactly what was solving a problem. So what I like about this model is it lets you explicitly go and say hey the problem was here the goal was here. I've implemented this MVF to solve this problem and implement this goal. So in the end I can look at user interface that's implemented or subsystems of the application and go this was directly implemented because it was a goal driven by this problem and solved by defining an MVF with the user to get this done. Everything we had in there was able to go back and be traced like this so that we made sure. And then so I just kind of mentioned these here but the scenario gave the problem was user can't see what's going on in different systems. The feature is amendments exposed in all five systems should be surfaced to a desk monitor in a single view, a blotter. That's specific for viewing into that stuff and the goal was to reduce context switching. This is exactly capable of having ROI assigned to it because we've taken X number of users and made them have 30 more minutes of work they can get done in a day. So we figured out what your value is as putting the system together which is actually very liberating in the end. Because and this getting down to the last couple slides here but this is like how we went and took it to like the champions inside of the organization. If we look at the top like business process this is explained as we had this is our vision deck. This is one set of one of the slides out of that where we said hey here's what's going on now. The business process requires trade amendments. One problem we found which produces operational risk because they may not do the amendment. May validate them incorrectly but you got operational risk. It's aggregated into monthly reports that are normalized and deficiencies in the process are identified mistakes on a monthly basis. Great. The market's moved on and I've got all these mistakes I gotta make and be accountable to the SEC. Wonderful. So we take another slide after that with the MVFs we had we would say then here's like a different view of this. The business process requires trade amendments. Now produces calculated operational risk on the fly. I have immediate visibility because of the MVP we put in versus the other scenario. To generate approval workflows which escalate these things to the appropriate people immediately that are analyzed as observed deficiencies but the key thing in the middle versus taking time. Again so I think a little more difficult to put a thing in here but more ROI very explicitly can be brought out of this and you know CTOs, chief architects they like to see this kind of stuff. So a couple of sites here to wrap this you know what are called a postmortem doesn't mean you did a bad project on this but you know what are some of the things we got out is the clients said things like processes of breath of fresh air we've never seen anybody do it like this before you've delivered so much more than we expected now we delivered exactly what you wanted but we delivered more than you expect because everyone else never delivered things to expectation so you know the last thing on there someone actually said amazing once in a meeting this is absolutely amazing what you're doing I said in 30 years of building software I've never heard that you know coming at me so things that went well in this time doing UX and replace of analysis was just absolutely a joy customers knew what they were getting it's all progress weekly scope creep never happened because we defined those business goals that's kind of an important how do you stop scope creep define goals that everybody agrees on so delivered exactly and only what was needed there's some stuff about code and technical implementation but things I'd like to do better well I still think it was a long cycle time you know as much as I'd like to be doing two weeks of inference and pushing out nobody's ready for that we spend a lot more time in this project up front just doing pure UX wire framing understanding the process I wanted to go to code quicker but you know they don't want code because they want to see that we can prove that we can code it but I'm like I know I can code it what we're putting together so still a lot of coding and dealing with bugs bugs and frameworks and all this kind of stuff that's still a hassle wire frames done in powerpoint just hate it I think there should be a tool that just cranks out code for you UI UX is not just UI's performance and stuff so the future what we're kind of looking for in like in 2014 is really within ourselves build up a UX body and knowledge you know what are the patterns and stuff we see with our customers so that we can really come in and put together other solutions really quickly we can take a lot of that analysis we've done take it to users and say we proactively have something that we think helps you out create some software factories for cranking the stuff out click of a button kind of thing a real introduction to a whole other conference you know software product lines and stuff one thing I want to say I like the MVF stuff because if you look at like software product lines and you find like these MVFs MV is part of a common feature set and then you start doing variability in other applications so you can split those out and have that really kind of well defined applied in all of the kinds of domains and stuff and then you know Michael I'd like to like some of the simulations we do for things like this is just a picture from the book show actual client pictures but you know when we wire frame this I just want to say click it's out and your it's out it's deployed your users are using it right now you know as an end goal for these kind of things so I want to say thanks here's some contact I'm assuming some slides or PDF will be available somewhere but if you want I hit the 45 exactly on the nose I'll stick around for from Q&A or me and Ravi you'll be around all day it's been great to present this stuff to you it's stuff I've worked hard on it's valuable for people to know and I said if you want to talk to us more come get some cards or get the stuff and you know it's a community we're all in this together trying to make this better that's why we're here today okay thanks questions does the customer get involved or is it your in our case yes the customer it can be the one case our prioritization is like the first one these particular users off of that system in two months so we looked at what we do with that system that we need to go implement in that time frame there's our prioritization for what we do then as we're doing more analysis we're building those up and then working with them to find out what the phasing is it's kind of nice because it's a little bit of a time box process so we know what we got to do we're not just doing market research to go out and then find what this we got to get systems the plugs turned off the people working more efficiently by specific dates and it's part of the category of marketing we also spoke about longer cycle time what's your typical cycle time if you were to call this a sprints we did we did two week development sprints which also sprints but that involved development plus UX and you know building spiking point spikes whatever calls for doing data integration we did two week cycles sometimes we dropped down to one I think one time we went to a three week one I think when I say the cycle is too long I personally think we took too long to push the whole thing I thought the whole thing could be less but when I was getting hangs with customers they're not ready for you start producing stuff that fast when you get good at it because you have to still go and train stuff I didn't talk about is like we've got to release common UX guy we work with the users to validate mostly to train but more validation did we do it right pretty 99% sure we did it right by that time it was great because then it's training not revalidation but do you have some sense in the cycle time to wake up on what was the time for the postpartum which is getting up to the wireframe simulation was the recording personally I was frustrated by that because I felt we could be wireframing through day one in the end this looked exactly like every other application that people use it's just it gave the information correctly to the users in the right time so that's kind of like we could go to getting wireframes it's not going to change what if it is how much of the domain do you want to use do you have a good process map how much of the process map is the client area it might not always be totally familiar with what are the others doing in the market so once you start discussing with them and get to the US they're able to we help them understand that there's a better way of you doing your business and then they say this was my priority but now given what you've given me you understand the domain better this is how I'm actually going to all of it together makes a solution there's an advantage in doing that because the more you are able to not spend time recording and making sure that you get users to understand what they're going to get you want to get a minimum product out to them so they can see the product in the actual they kind of leave out what is the minimum product so did you end up coding more or was coding effort more or less according to what approach you did what do you mean was coding more or less because what we did we reduced the code I don't have the code but maybe for how we could repurpose stuff in there so if we did do something that we coded we generally knew it wasn't going to get thrown away it may be the way it's interacting with but in that sense I want to say it was less coding but having built these I kind of had a good feel how much coding so to me it was kind of the same but I think we were we didn't waste while doing it so I think there didn't come out any experience beyond the changes that came in the project later which could have impact on the earlier years I'm sorry changes that come in later which could have impact on well that's probably part of why we did a lot of analysis the UX stuff up front so we had a very good understanding about 80% of what was going to happen by the time we got to doing it so we didn't have things come back at the end I'm not saying that I think that's maybe actually any tip on a lot of cases but we did a good job of knowing what it was we needed to do which is kind of the purpose but you can't come at any point in time to reprioritize minimum viable features and stuff like that and hopefully you didn't waste they just need to be used somewhere else in something else can you comment on the performance of the presentation I think we're going to kick this out we'll be around to talk thanks