 Good afternoon. My name is Sheryl, and I work as a UX consultant in ThoughtWorks. I started designing a website when I was 17 years old, and that experience has shaped me as a person who could design a web product for users who would love to use it. That's a bit about myself. My name is Krishna, but I generally go with an MKK. So it's one KK replacing the other on the stage right now. So my journey into IT started 11 years ago. Nine years ago, I joined a startup, and we were very agile, even though we didn't know what agile really was back then. And that's how my journey into agile started. For the past six years, I've been working with ThoughtWorks in multiple roles, primarily joined as a QA, but I also worked as a consultant coach, business analyst, and on the latest project I'm working as a project manager with Sheryl I have a deep friendship with UX because I'd like to use products that have really good user experience. So that's about it. And outside of work, I like to bike. That's my picture of a bike. Cool. So what are we going to talk about today? We are sharing our experience on how we achieved building incremental UX user experience in one of the agile projects that we're working on. So traditionally, if you see UX, it wasn't given that much importance or value. So the user experience, our designers would always be siloed. That has changed radically in the last few years. However, if you think about the agile practices itself, they do address most of the core development issues or testing issues or analysis issues. But even now, if you see, they seldom address the user experience. So how do you really think about building user experience in an incremental fashion in an agile project? And we have faced some problems in the earlier projects, which we failed to address. But then when we just started this project, we thought, OK, there are some lessons to learn for us. And we should make the most out of it. There's some challenges that we faced. And we wanted to basically tackle those up front. So that was the prime motive. And that was the prime goal when we actually started working on this project. So with that, let me set a little bit of context before I discuss what are the techniques that we used to solve or to basically mitigate some of the risks with not doing user experience designing incrementally. So about the context, this was a client who was a neutral child. And he wanted to launch a product. And the product was going to be a digital wallet. And he wanted to explore a market which neither he nor us had a lot of experience with. And this product was going to be used across multiple age groups, right from students to housewives to regular employees to senior citizens. So again, usability and the user experience mattered a lot to us. And it had to be put right from day one. This wallet was going to be supported on multiple devices, multiple screen sizes. So again, from an implementation point of view, we had to take care of that. Plus, the market that we talked about in terms of the geographical area already had similar competing products. So staying ahead of the game was another important challenge. So we wanted to release as soon as we can, as well as two quarter incremental releases as frequently as possible. So Agile as a solution worked really for that problem statement. But again, like coming back to how do you really get your incremental user experience in sync with that? So with that context, one of the things, so coming to the solution part, one of the things that helped us, the first step is to plan for UX in an incremental fashion. And one thing that we needed to do here in this space was to educate the clients. Basically, what I mean by that is you have learned your experiences on how it is difficult to imagine full and complete designs when you really don't have them. For example, in an agile project, you take and build chunk by chunk. Basically, you pick a story. It's not full story. It's just half the story. So how do you really set the expectations with the client on saying, hey, this is the story. But the user experience for this is not going to be full or fuller. It's just going to be half late. So setting that expectation becomes really important. And especially with clients for new to agile and who have completely different experience on building products. One thing, so this is at a higher level, but what did we actually do to educate? So we created something called as a design vision document. Sheryl will give you more insights on what this contains and how we get this. Yep. So traditionally, if you look at any software development and we want to create a product, the first thing that happens before the actual development of the product is that designers create a bunch of Photoshop files which will have the pages and different modules and the look and feel of the entire product itself. So it's going to take a longer time for the designers to brainstorm with the clients and come up with these designs and ideas and put across to the development team itself. So what is going to happen is that the developers are on one fine day, they get a bunch of PSDs and bunch of amazing screens and cool stuff to do it. But in agile, we believe that we want to break the larger chunks of work into smaller works so that we could get feedback quickly and also we could course correct the entire problems that we face during the design process itself. So what we decided was we will create, we decided to create a design vision document. This document basically has a higher level understanding of the design itself which means when we design this project, when we finish this project, the design is going to shape up in a particular way rather than getting into the elements of the designs, getting into each and every components of the design and understanding in deeper level which is going to take a longer time rather than spending more time on that, we wanted to break the design process itself and incrementally design the project. So this design vision document contains elements such as typeface palette, color palette and some of the sample designs that how our product is going to look like. So again, what is so different about the traditional brand guidelines and our vision document is that we didn't want to get deeper into the design and spend lots and lots of time on analysis of the elements itself. What we wanted to show is that, hey, when we finish a product, our product is going to look something like this. So for example, this is a screenshot from our document which shows that our product, our marketing site of a product is going to turn up something like this. But when we created this, we did not get into a deep level of analysis of individual components. What we decided was over a period of time this design is going to evolve. This elements in the design is going to shape up really well and we wanted to do it incrementally. And one more screenshot which we shared with the client was, hey, when our product has been developed completely, our product is going to shape up something like this. It's going to look responsive in an iPhone this particular way. And also we also wanted to establish some of the basic principles that our design of the product is going to be. For example, we created a tabular components. We created a design for forms and buttons and the common elements which is across all the products. We wanted to establish some of the fundamental guidelines for the design itself. So we were able to finish this particular document in about one iteration where we were able to present this to the clients and we were able to build the trust that, hey, our product is going to shape up this particular way in this direction in terms of design and we want to create an amazingly better user experience for the user itself. And one of the things that we wanted to do was how well we can implement or design this incremental UX throughout our product development. So some of the benefits that we will get out of this incremental UX is that we will get quicker feedback from the users and also the clients and we will also be able to have a faster UI development and also we will not be compromising on the UX itself. So one of the things that how we were able to get the faster feedback from the client was with the help of paper prototyping. So if you look at paper prototyping, paper prototyping is a technique where we will sketch out our ideas on a paper, we will share it with the client and also we will do some amount of user testing and get feedback from the users and the clients very quickly. So if you look at the traditional way of design, what typically happens is that they create some PSDs which is so beautiful where you spend lots and lots of time on creating the PSD itself. Now the client says that, hey, this design will not work in the market. It's going to take a lot of time to correct the design itself. So we implemented this technique for each and every stories in our project. So let me run through one of the stories that which we worked on. So this is a story where we had a dashboard and we wanted to display some amount of statistical data on the dashboard itself. So we quickly marked up a paper prototype for this story and we did a few iterations for this paper prototype and we got some feedback from the clients and once we felt that, hey, this is kind of requirements we could take and we could think about the visual aspect of it and we can convert that into the actual code itself, we went about and looking at, we went about and thought deeper into the visual aspects of this prototype itself. So for example, if you look at this story, some of the elements which is present in this story was not there in the vision document itself. So we thought, hey, we need to implement the visual aspect of these components which is present in this paper prototype. So hence, we picked up those components which was not there in the vision document and we created those components and we shared that with the client again and we were able to get the feedback from the client before the actual development itself and once this is done, the story is actually ready for the developers to pick up and work on. So when I say the story is ready for the developers to pick on, even during that stage, the UX or the UI developers will be highly collaborative with the developers to work on these visual aspects of the product itself. For example, what I meant was, yes, we did a couple of things. One is that we shared this with the stakeholders, that is the clients as well as the project team itself and got their feedback. So what I meant about the project team is that sometimes the designer will have amazing ideas but then when it has to be implemented in the actual code, maybe there will be a performance issue or maybe there is something that is blocking to bring that exact experience what the designer is thinking about. That is something which we got with the paper prototype itself and to answer your question, some part of it, yes, we did with the actual users itself and some part of it we did not do user testing. We only did with the clients and got the feedback. So one thing there that helped us was, so only very few times you could find people outside the company to get feedback but in general, if you find people outside of your project who don't have a lot of context on the project, they will give almost like real feedback on how they would use the system and that helped us again. So it was not just your peers in the project but also people who are not on that, were not working on that product but outside. So that kind of helped us design this better and get better feedback. Right, so traditionally if you look at some of the things that an UI developer or a developer will have is that, hey, we want the design for the entire page to start the development because we need to architecture the CSS framework or the JavaScript framework and this is basically a mind shift or a thought process which the UI developers have in their mind saying that, hey, we cannot start with the CSS framework until and unless we see the entire design altogether. So that's something we thought radically and we decided that we will design the UI components on a story level basis and not as a whole saying that, hey, let's finish the UI development and then the actual development starts after that. We did not do that. So something we did was a living style guide. So what living style guide is basically, the style guide will have a live documentation of your CSS components itself. So for example, let's say there is a story to create a login for the user and the user should be able to see their front screen. So what we need to do in terms of the CSS is that we need a form to login and we need to see the logged in information on the front page. So we were trying to abstract these components. So to say abstraction means one of the things is that there is a form element to it, right? So we started writing the code for the form itself. We put that form in something called a living style guide. So whenever we will have to work around with the similar components, the developers or the UI developers or any other player in the team will go to the living style guide and see, hey, this is the form which we already have in our application. Let's see how to reuse this form or in other words, is there any other way that we could improvise this form itself? So we were able to abstract the components on a story level and were able to build the UX in an incremental fashion rather than traditionally how they do saying that, hey, let's finish the UI development and then let's start the development. So I'll showcase some of the screenshots from the living style guide itself. So this is the component which you would have noticed in the paper prototype. So when we did that story, we identified that this is a component which we might be using more often in our product or in that particular story itself, right? So we abstracted this component and we created the CSS and HTML marker for this component. And there was some bit of JavaScript on this component and we also added the JavaScript for this component. And if you look at this component, again, there is abstraction in this component itself. So for example, if you look at this bar there, it's a component by itself. So whenever there is a bar in your product, you could go ahead and you could reuse this code. So this was one of our approach which really helped us to do UI development in a faster way. And over a period of time, developers started picking up UI stories. That way all the UI related work is not attached with or dependent on one particular person or the UI development team itself. And also one more thing that which we cautiously did was UI developers and developers don't work in silos. Whenever we designed or developed this component, they pair together to see, hey, what is the semantic way of writing this component? What is the best way to put across the JavaScript which is quite flexible and robust with our product? And these are some of the examples of our components. Yeah, yeah. So just before we end, right? Collaboration of the design. So the different style guide that Cheryl was talking about, it was basically in abstraction or a running document. And whenever you decide new components, there were newer components, we made sure that we maintain this documentation or we maintain this live style guide for others to pick up. So during the course of our project, we had other remote team that started working with us. And it was just amazing to see how they could wrap up so quickly just by looking at that style guide and wrap up at least on the UI aspects of it and maintain such a consistent design and consistent UI across the site. So that was one good benefit that we got out of the living style guide. The other thing about collaboration to remember is what Cheryl shared about having the developers and the QAs and the BS also keep in the loop about the design decision. So whenever we had to deal with or come up with new designs or make any design decisions, it helped to keep developers and BS in loop. And so this serves two purposes. One is like it validates the feasibility of the technical implementation from a UI perspective, as well as doesn't compromise on or keeps a balance between the usability and the utility of the product. So those are a couple of things that we solved by collaboration. So to conclude, something that we did differently different from the other projects that we had we used this on building the incremental user experience was one to set the right expectations to the client so that the clients have better idea on how the UI is going to shape up over the period of time. The second is in the implementation phase itself used couple of techniques like paper phototyping and abstraction to make sure that we get faster feedback and our delivery is faster itself. And this helps us to continue delivery on the product. The other thing is make sure that like we collaborate in the other sections of that but make sure that we, like even when we're doing design we take care of this and we include all the stakeholders. And that's about it. Thanks. Questions? Other person? Yeah. Or maybe you're reaching out to the client. What are the challenges which you face and how you try to overcome them? Because it's not closer to the end user's feedback. Sure, agreed. Agreed. So one thing, one challenge is availability. Simply availability because you don't find people from that region that easily. However, luckily for us since we are a global company we had our own office in the geographical region that we're talking about. So there is a thought of that office and we contacted people from that office to make sure that they test our application. And also not just the user experiences and also in terms of implementation and also in terms of, you know, deployments, right? So it gets better like if you get people from that region. So in terms of user experience at least like we were lucky enough to get people from there. So that's how we address one challenge. Yeah. But I understand your point that it can get difficult in terms of getting people from different age groups. But that basically can be solved by when you release your beta version and you get feedback from the real users. The point is necessarily, we need not be through the client which may reach to the other world. Oh yeah, absolutely. That's the point. We need to find ways out to reach out to the different strata of customers. Yeah, absolutely. The thing is most often it wouldn't be the clients who would actually, you know, facilitate the user testing. If you're responsible for creating a good user experience, it's your responsibility to go find that user base or at least design something that you think is appropriate for that particular user base. So part of your responsibility is also to make sure that you kind of get some feedback from that user base and design a product accordingly. So you cannot design something today and say, hey, is this going to work? Just to the clients, because they might, again, be not in a position to, you know, do proper user testing. So we assume that responsibility partly. Thank you. All right. Thanks guys. He has a question. Yes, go ahead. Sorry. You mentioned about the leading style guide. You have a function for the bar graph. You have a typical code, which has been similar and you can reuse across different areas. Yeah. But I'm looking at a general perspective when you are developing a story, which has a function part and a UI part. You mentioned that the CSS part, if you have to think of a developer, take a long time and you have to deliver that and then the development team starts working fine. But even doing this bar graph, I have to have an interface. I have to have a whole page and there the bar graph comes in. Sure. These are like reusable parts of components, like bar graph, or fader bar. Whichever you have. There's a library and the team needs to use that. Yeah. Isn't it? Or it's like you design a new UI in a paper, put a dive or whatever and give it to the customer then they have to use. You can't just give smaller components and now the development team is over from here. I didn't get how it works in a story level. You do this small chunk and it gets realized and realized. Okay, so your question is like there's a page which has a lot of components, but how do you actually pick up one, abstract one components and do on a story level? So like I said, that's where the vision document helped us a lot, right? So let's take an example, say a dashboard. A dashboard has different components in itself, right? But when you are working on a story, you work on only one particular component, right? So the project team as well as the clients is aware that once the dashboard is completely designed, it's going to look something like that. But for now, we are only focusing on the bars that has to be done. Yes, we use Photoshop for the designs. I mean, in terms of libraries. For prototyping, it's paper, pen. That's it. Yeah, most of the times. And sometimes we use balsamic. Thanks.