 My name is Pradeep. I work at MacWorks as a senior UX specialist. Prior to that, I've been working at startups and product companies as a UX specialist. I work at Atelco as a customer experience manager and I started my career at UX Conservancy as a designer. Now, the insights that I'm sharing in this talk are primarily from my experience working with product companies and startups where I was at the first UX designer I ever to build up a team or the only UX designer or a team of one working on these products. Now, traditionally, there were businesses and customers and the UX team was the glue in between who brought the customer's insights back to the companies and that's how we work and in a way, UX designer's role at that point was like that of a great people to keep the bad design charts of service from the customers. But Jeff Gotel, one of the leaders in the UX says that a company has to believe that user experience is part of a broader recipe for success and what that means is and we've started seeing a lot of companies where the divide between the businesses and the customers is coming down and you have UX as a glue still as a glue in between but there are other departments like your marketing, your customer service, of course they are and product managers, everyone talking to users and where our role from a great people is now changing to that of somebody who supports the orchestration of resources to build better products. Now, this is not something new. This is John Norman based on his experience working at Apple in kind 95 he said that's what the UX team does where he says the role of user experience architect software which works across the divisions helping to harmonize the human interface and industrial design processes across divisions of Apple and ATG. Now, it's important that everybody in your company understands and knows the UX design or the importance of it and how to apply it in the products and services they're building. Now, when you think of it, most often when I work, case in example when I was working at telco there were 40 product managers and 6 UX designers we could definitely not support every single one of them but you know how do you work across that so that's something that I could talk about. In a key takeaway, all I want to say is responsibility of delivering a delightful experience cannot be with a single person or a team. Now, this are survey results from UX, a career survey from an N group in 2013 but these are the top 10 UX activities done by UX designers. Now, look at the number two over there, persuade others. This is not persuasion for your customers or the users but this is persuading your managers and your developers to build what you're trying to service or stopping them from doing bad design. Now, to do this, I have two questions. What new skills as UX designers do we have to develop to work to persuade our developers and managers and what new processes allow us to do our work more efficiently. Let me start with the first. I call it inward empathy. We UX designers are great at doing research. We talk to our customers, we talk to users, we do in context inquiries, we do usability tests and we do that to build empathy. A short note, how we see people necessarily is not how they see themselves. So we need to figure out, we need to feel the pain that the customers are experiencing using our products and services and we can do this back to whatever was. Now, why don't we apply that back in our workplace? We are good at understanding pain points. We are good at understanding other structure. Why don't we start using this skill of building empathy towards our teams that we're working with? Here are a few things that you could do with your teams, things that work for me. Knowing the team's mission and objectives, knowing what they're trying to do helps you to integrate better with as a UX designer in the project team. Understanding the goals, the task force, the pain points. The task force here are not the task force of the application, but they are also doing the task. They're building code, they're deploying code to a server. What are the problems that they're facing? How can you help? And there may be few tricks that you could help solve their pains by gaining their trust while you're working with them. Practice active listening with colleagues and trans-function teams. When people feel heard what they're saying, the more chances are that they're going to hear when you speak to them. Right? And then know when to push or pull back. No matter what you say, the product is going to shift. And especially if you're in a product company which has tight deadlines, whether they have design is just only a part of it. There's the business viability, feasibility and a lot of other things. And they're going to shift the product, whatever you say. You can keep shouting, but the train has passed. So you need to know when to push, when to pull back. And as for the second part, what the processes allow us to do are jobs more efficiently. Now let me put that in two big buckets, the research and testing phases and the designing phases. I'm sure we all record our usability sessions. We generate huge reports of what we're doing. And then your managers, product managers or your team managers are like, oh, you're going to record, right? I'm going to see it tomorrow or send the report. I'll, you know, read that later, but that never happens. You do your research, you get your insight, you're trying to talk to your team and they're like, no, this is how we're going to do. But you would be like, hey, did you see that video? The users really struggle to do that particular task, but they're like, what we do, right? So they're never going to look at that. So in a way, when we record these videos and send them to that, we're actually, you know, enforcing them not to look at it and we waste a lot of time afterwards convincing them that we need to do. And a few things that work for me involving my project team and the research and testing phases and especially when we get buy-ins for research, we get not just for the budgets, but also the project team's resource time so that they can participate actively in the research or as observers in usability tests so that they're right there seeing what's happening with the particular product being used by the users. And at MapWorks, we highly discourage UXers to do video recording of the UX test unless you need it for your personal use. This is not a report that you want to share with them. A case study from Gramminkphone, this was the telco I was working with. So this was the case where there were 40 product managers and six U.S. designers. So we kind of like help train the product managers and few developers to do motivation, to do collect insights from the actual feed. And where these guys were doing the data collection, we were once in a while checking what insights are coming in, how are these insights being channeling into the products and services. The benefit it really drastically reduced the time to from idea to execution. And if anyone of you worked at a telco, usually from idea to execution is two weeks. And as simple as, you know, five rupees, 500 sms is a product for them. And they're going to act fast on it. Again, at MapWorks, we only do usability tests when we have at least one project team member sitting in the observation room observing it. Advantages, no more long hours of report generation, which is a side effect. But the main effect is they have the ahub moments right there while the usability tests are happening. And no more trying to go and convince them what to do and what not to do. Now as for the design part, who owns the design? So I've heard various different things from people in the last couple of days where sometimes it's the product managers who own the design, sometimes it's the US designers. But let me take the case where US designers own the designs. I've had this case even for a tool like Balsamic with very low entry barrier. You even after you share, you know, we use my Balsamic, it's shared with everyone, everyone can go and make edits, but they'll come to you and say hey, can you make the small edit that we discussed so that the design is all okay? You can do that as well. But you know, these tools have an entry barrier nobody is going to put in effort to learn them. So in a way, what worked for me again is moving the ownership to the team of the design and only keeping the responsibility between us as a US designer. Let the team create the design artifacts, create prototypes, whatever and we only use Azure or Balsamic only to document these designs digitally but not necessarily to share it with the team because the team is part of designing activity, they know what to do already. And your design tools play a major part in this. You have to think about are you using the low fidelity prototyping tools or high fidelity prototyping tools. I personally like the low fidelity ones like paper and whiteboards because everyone can jump in in a workshop to start creating your prototypes and talk about them. And another thing that helped us in our previous product startup that I was working with, as part of the requirements gathering, we had the UI developer sit with us, start iterating building in the browser itself, designing in the browser. That kind of drastically reduced the time to understand or going back and forth on the requirements because we could show them, this is what we understood, is this okay for you? And then this was like a spike for us, we either threw the code away or we started building again but there was no misunderstanding in terms of what worked or misunderstanding in the requirements basically. So I'll take a case study of engagement H2 Mobile. This was a company I was working with prior to MathWorks. They are a SaaS based web product for governments to deploy websites to engage with local communities. They are very popular in New Zealand and Australia. They had the web presence, they wanted a mobile presence, I've just joined them. I had a hard deadline of 30 days to get out a demo because we were at industry conference and we wanted to get some feedback at that point. And this is a journey of how we went from day one ideation demo in day 26 and before three months we had the final launch. So on day one we had, I'm sorry, the fonts but basically we had a workshop on day one which included the product manager, a couple of patent developers, couple of front-end developers, CTO and myself where we went through brainstorming, ethnicizations, storyboarding and paper prototypes. It was a long day being in a start up. We could afford to have all of these people come and work at a day long workshop like how Google Ventures talks about it as a studio for the team. That's what we did. And at the end of the workshop we had this problem and the pain points clearly defined. We had a draft of the project plan with priorities in terms of what we are building and how we are going with it and everybody could see eye to eye in terms of what we are trying to achieve. And then we got to work and yeah, I didn't know any why frames for this after the paper prototypes. They were the oracle or the truth by which we were building it. But we did need a visual design. Again we did a hack over here. We knew there were going to be banners, thumbnails, a few types of text and text boxes. Of course there are the radio buttons and things like that but these are the most prominent ones. We went to see how things fit together, we fixed the language and within a design language we kind of saw what works for us. Of course this changed by the time the final product came. But it was a good start. It gave enough inputs for the developers to go and start working, not waiting for the actual components to come to actually build it. So the way we built the demo, we fixed on a couple of features that we want to have the experience on the mobile. All the rest of the things like say for example if you click on the issues over there, it would load up a desktop page but that was okay for testing and as a demo experience. But some of the big features were all prototype, they were all built into this demo. And in fact we had a couple of beta testing customers deploying it to their live sites to see how mobile works and that gave us a lot of insights in terms of what worked, what didn't work, what design elements worked and we went ahead and by the time we had on day 86 the final launch we totally refined the visual language, we refined the interactions and it was a huge success and we were out in the market in three months less than three months. So again when you're trying to teach your convey some parts of your skill sets and knowledge to your team members there's always this dilemma that what is my role if I start teaching my developers how to design. And this is not this as I've heard multiple times this coming up in the workshops and talks over here and this was also asked by a colleague of Jared's school three weeks back he blogged about it saying you know some user experience skills are always better than no user experience skills. With no U.S. skills on the team there's a good chance that whatever the team produces will have poor U.S. probably close to 100%. Any designs that aren't a poor U.S. are just accidents that work out in the user's favor. So I urge you to start involving your team in designing kind of running workshops designing wireframes, prototypes so that they already know what's coming up on the same page and you're able to reduce time and condensing your developers what to do but take the journey on to build world-class products. And I think I have time for one question and I'll answer with no it depends. Sure. So one comment, one question about the influencing I think you're exactly right on through those points. That's if there's one thing I've learned about years in this field, it's that influencing interim teams is really important. Question, you can talk about an internal kind of participatory design and exercise and everything. Yes, that's great. Do you guys ever do that with customers as well and the mix users? So it depends. So I'll say it depends over here. For the reason because while it's a startup it was easy to get the customers to talk about it. Currently there's a lot of networks, there's a whole lot of India stuff going on so we can disclose what's coming up but we do involve customers when we kind of do workshops to identify the current workflow. But for future workflows we use surveys who are internal engineers who know the workflows of the customers and that's how we work around. And if you have a moment, how do you find the differences between the internal and the codes and what you've got with the customers? Do you get to a better result where the users are present? Actual end users always better but I think we are a little fortunate in case of match works because our customer facing engineers most of the time spend time in the customer location. So they kind of like invite, they know the culture, they know the workflows. So it helps, sort of helps many days working with the customers has provided much better results.