 Okay, I'm talking today about change and what you can do to drive the change, manage it and make the change happen in a way that you want, in a direction that you also want. A bit of a background of myself, kind of to give you context on where I'm coming from and what kind of, I don't know, experience I've used coming to this point. I'd say that Nokia plays a huge role in my career and my expertise. So I come from Finland and in Finland it's almost like a national service to serve a couple of years at Nokia or actually at least it used to be like that. It doesn't happen anymore because you know the story. Quite quickly after my graduation I joined Nokia doing youth experience. My first job around UX was defining how youth experience is measured within the company when they were doing internal beta testing. That was a really good introduction to how a big cooperation works and how they make sure that the quality is in place before they launch the product. After a while I wanted to try consulting and I joined a smallish agency. After two or three weeks they sent me to a client project and the client was Nokia. So it became quite obvious to me that Nokia was my destiny. Luckily I was put to a really interesting project and we were looking into a completely new area which was open source product. So we didn't have any limitations in terms of what is the old Nokia legacy but we could really start thinking out of the box. I followed the project from the concepting to the very end which was the product launch and shipping. After half a year or so the team leader asked me to join the company instead of being a consultant. And since it was quite clear that I was destined to be with Nokia I would rather be an employee than consultant. After the product which was later called N9 shipped I decided to leave the company because they were going to Microsoft things and I didn't really believe that. So I set up my own business which was a lot of fun. It taught me a lot about what is that really matters in business and how do you need to make sure that you have the basics right and you get money in and that's in the end all that matters. But 2012 a bit more than five years ago we got the opportunity to move to Singapore and that's when I closed the business and moved here with my family. Really good decision. I've interned my time really, really much. For the first four years I was running a small UX agency but last spring I left the company and joined BHP which if you don't know is a mining company. So very traditional industry. They knew nothing about UX. Well they do now because for the past year or so they had their own UX team. But the thing here is that the company has been working on a certain way for decades. And this whole thing that is called user centricity is really new to them. It's not really about customer experience because you know nobody buys I don't know. For them it's all about employee experience which is pretty cool. So for a company that has no background and history in user experience what they start to do is think about the employee experience and how can they make things better for the people that are really doing the work. And that's really where a lot of my learnings come from because seeing how a huge cooperation transforms from something without any UX to something where they are trying to integrate user experience to everything they do has been highly interesting and also rewarding. Because with small changes you actually see really big results. So what is change? Really simple way. It's a transition from something very familiar to something new. And when we talk about something familiar, something that people are comfortable with. It's something that they want to stay. That is the status quo and for most people that's how they want to continue. Through the change they are learning something new which for most people is something a bit intimidating and even scary. And that's really something human. So the human nature is change resistant. Obviously there are a lot of people who want to make the change happen. But you need to understand that there will be always a lot of people who are not ready for that change. And you need to support those people in going through that change and making them understand that the change is for the good. Before you start the change or you start driving for the change, you need to understand what it is that you are really changing. Is it maybe the organization? Is it the company culture? That's a really, really big change or even huge like Donald Trump would say. Are you changing the strategy, the direction where the company or the team is going? Still a big thing. You need to consider a lot of different things and how things are linked to each other. Or maybe just a product or a feature. Smallest change but still you need to go through the transition and support the people who are involved in the change. And in all of these, you need to understand who are affected by the change and make sure that those people are comfortable with that change. When you talk about change, it's something that happens all the time. It's inevitable. You can't really stop it. It's always there. And to be honest, you don't even want to stop it. Because change is what keeps the wheels of the life rolling. That's what makes us evolve. That's what makes all the services and products evolve. But what you want to do is you want to manage it. You want to make sure that the change is going to a direction that you want. Because in the end, when you talk about user experience, you want what is best for the end users, whoever they are. And sometimes people might have a bit different views on what is really important and beneficial for the end users. So that's what you want to be involved in that change to make sure that whatever happens supports that goal that you hopefully have. When you start driving for the change, you need to make sure that your foundation are properly built. If you are new to the organization or the team that you are working for, the first thing you need to do is to gain credibility and trust. If you are a new employee to the company, nobody knows you. So why would they listen to you? You are just one of the others. You are the new thing with new ideas, maybe some new scary ideas, so you are the person that don't grutter. But if you make sure that you have some important message to give, that you know what you are doing, they will start trusting you. They will start listening to you. If you've been with the company for a longer time and they know you, it will be easier. But if you are changing what you do to something else, people might be very suspicious on like, what's that dude doing? Like, we've been doing this really well this far, so why do we have to change? So again, you need to make sure that whatever you are doing is really creating trust within the people around you, because you will need those people. And that's the second thing, you need to understand the people you work with. You can't do the change by yourself. You need the team, you need to engage the people that will do the change with you. So first thing you need to do is to identify who are the key people who will help you reach your goal. Are they the decision makers? Are they the influencers of the organization? Who are the ones that will help the others go through that change? If we talk about the product, it might be the product manager who defines or decides what are the changes that will be done. So you need to make sure that that person is behind you and understands where you're coming from and understands why you are doing this, whatever you're doing. The second thing is that you need to understand what can goals these people have. I mentioned earlier how change is always a personal transformation. So this is the key thing. For each and every individual, they will have something personal they want to gain with that change. If you can align your activities with their goals, they will support you. It's always about winning. And if you can help them become better, if you can help them to be more successful in what they are doing, they will want to work with you. And it's not that you're giving something away from yourself because you're just giving something for the person and in exchange you will get their support. You need to also understand the environment. When we talk about companies, we talk about business, it's all about business benefit. In the end, usually it's all about money. And although there might be some higher goals in making things more pleasant or more satisfactory or save the world, in the end the organization needs to get some benefit from that. And the earlier you understand this, the earlier you will succeed as well. When you start planning your activities, you need to understand how that whatever you're doing will contribute to the bigger goal or the bigger business benefit. And if you can do that, you will get the support for your activities. And how you do that? Metrics. These are by the way my cats, really gorgeous little creatures. Metrics is your tool to show that business benefit. I think more and more companies are asking for ROI of user experience. And there's no solution or, I don't know, golden rule on what is the ROI of user experience. What you can do is put metrics in everything that you do. With metrics, you can show the effect of the change that you are proposing. And when you get the numbers in place, you can bring in the money. You start multiplying actions with, I don't know, cost savings, increase in sales, customer retention, whatever that is, you need those numbers because otherwise you can't really prove yourself right. There are very few companies who have the luxury of doing anything and everything they want. Most of them are in constant negotiation over what they can do and what they will do. And that means that you will be competing with other people and other teams in terms of what will be done. And I can assure you that those others will have their numbers in place and they will show the leadership how their idea will benefit the company in short term or long term. And if you don't have your numbers, you will lose the game. So that's why this is, if there's two things that you remember from this one is that you need to remember the business benefit and the metrics because those are your safeguards that make sure that you get to do what you want to do. So how do you make that happen? Probably by the topic of my talk you guessed that my solution is user research. And why I'm all for user research is because user research gives you behavior instead of opinions. You might be really respectable and really experienced designer or product manager and people might listen to you. But unless you have no facts to back up your opinions, it's just opinion against someone else's opinion. But if you can show behavior related to your or that backs up whatever you are proposing it gives you the power of all those people that you've been researching. That's a big difference. So when you start planning your research, you need to understand the direction where the company is going. So what are the KPIs that they have on higher level? Is the company trying to cut costs? Are they trying to expand in the market? Are they trying to reach out to new consumer segment? Are they trying to increase productivity? You need to understand that. Because your research and the data that you bring from your research that needs to support those company goals. This is again the same thing as I was telling you before. You need the support from the others so that they will let you do your work and let you do that change that you believe in. So align your use strategy with the company strategy. If you haven't created or depending on what kind of position you are in, if your team doesn't have a UX strategy, I really recommend to start working on that. What is it that you want to do? What is the direction where you're going? And how you will reach those goals eventually? And make sure that that strategy is aligned with the company strategy because if it's not, you won't get the buy-in from the leadership. The next thing is when you do your research, you need to understand what is it that drives the behavioral change. People of us, they will do something and they will say something. But that doesn't mean that they will continue doing things in a longer run. I was recently involved in one project where the company heavily using SAP wanted to introduce Fiori for the employees. So Fiori is the simplified interface of SAP. So what the team did was they designed the Fiori applications based on the research that they did and they launched it two years fast forward. They realized that the adoption rate was somewhere around 4%. So they had this really nice new tool that nobody was using. So I was asked to find out what was wrong, what is the reason for the low adoption rate and what they could do to change that. It turned out that when SAP, a long time ago, was introduced, they did this huge, big, big roll-out process. They did the roadshow, they visited all the different sites. They helped people to get started with SAP, set up the systems and so on. With Fiori, they just threw it over the fence and said, okay, there you go. Have fun. I don't know how many of you have ever used SAP, but it's not something that you want to use. It's something that you have to use to support leadership. So although Fiori might have been able to ease up certain things, when nobody was there to help them to go through that change, they didn't do that. They didn't have time for that. They were really under pressure all the time, and when the solution didn't do everything that they were expecting, they rather stayed with SAP because they knew what it was, how it worked, and they knew that they could complete their work using that. So they did two big mistakes. First of all, they didn't find out what are the key things for people to use the system, and they didn't help them start using it. Now we are in the process of trying to make that change happen again, and hopefully sometime next year we will get that adoption rate up again. The key thing here is that you need to understand why people behave the way they do. So it's not just what people do but why. Because if you're going to try to change the behavior, you will need to understand where they are going. You need to prove yourself right, especially when you're doing something completely new. If you want other teams to take help from you, employ you, you need to first make sure that they know what you're doing helps them. A good way to do that is to start somewhere doing something small, letting them see those small incremental changes and what is the effect of the work, and then once you get that buying, you can start growing big. In my current work, although the attitude towards user experience and the work that we do is positive, we are still in constant process of proving ourselves right and making sure that we get to exist in the organization. So if we want people to engage us, we need to make sure that they understand the benefit that they are getting. That might mean that you have to do something on your own time, voluntarily without having someone to ask you to do things. As one example, I had identified through my conversations with the different employees, I had identified a pain point in travel system. I created a small mock-up. It was just a really, really small thing, so changing one field to another one. I did a small mock-up, I did guerrilla testing, so just gave the mock-up to a person randomly met in the cafeteria, asked people to do that task using that mock-up, and I took time. Then I asked from the travel team to give me the records of how many transactions we are doing on monthly basis using this. With that one change in one field, we talk about a system with 34 different fields and it's a complicated system, changing that one field, we calculated that even carefully estimated the company would make savings of 25,000 US dollars every year, just one field. I showed this to the team lead who is responsible for the travel system. What she wanted to do is to know what else can we do, so she wanted us to find out what are the other pain points, because if we can, with this really teeny tiny change, get this saving, which is not much, but she already knew that we could do much more, because that was not the biggest problem that she has. So it's all about finding something that they recognize and they see the benefit, and then working from there to bigger things. My last point is on choosing what you do. We don't always get to choose what kind of projects we engage with, or who do we collaborate with. But even within those projects that you might get involved in, you can choose where do you concentrate more. And if you want to gain good results, you want to concentrate in those parts that are all about volume. So it might be that we talk about something that everybody in the company does every day. So you get to multiply with the amount of employees and the days. Or it might be something that a small team does all the time, and because of those constant repetitions, you get those volumes. I was doing one project earlier this year, and my role in that project was questioned by the leadership, just because of the cost, because the company is going through cost-cutting. So they wanted me to prove that I'm worth it, that the investment in my salary is worth it. So within that project, I chose one use case. This was one of tens of different use cases, but since I was working a lot of things that were more difficult to put metrics on, I identified one that would show the power of the work. So I identified one pain point in the process where a small team would actually spend most of their time working as a middleman, just passing over emails between different parties, and we calculated that this team of a bit less than 20 people, they spent almost 75% of their work time in responding and forwarding emails about travel updates, processing changes, and just by giving access to these different parties to the same travel system that the team was using as viewers or just giving people opportunity to edit their travel plans themselves. We estimated that the yearly savings would be almost US$800,000 per year. And you know, I'm not that well-paid that my cost would be more than that. So when we showed these numbers, the leadership, they were quiet, so they haven't really questioned our work after that. Obviously the reality is not always this, these are all theoretical calculations, but in the end, if you can put metrics on what you're doing, you can at least put some numbers behind it, and then you can put the cost or the benefit or the revenue increase. And with those numbers, you can prove yourself right, and you can really show that the direction where you want the company to go is the right one. So to summarize, first you need to build the foundation. You need to understand what you need to have in place first before you can start driving the change and doing your research. You need the trust, you need the credibility. You need to understand the key players, those who will do the change together with you. You need to understand the environment. Where is the company going? What is the business benefit? How do you prove yourself right? How do you put numbers on your work and then you just make it happen? My solution is user research, but obviously there are other ways of making the change happen. Users for me is the key thing, because in the end, users are the only thing that matters. If the users are not comfortable, you have nothing. If you don't have your customer support, you don't have anything. You need to align your work with the higher core goals. You need to understand what is it that makes people to change their behavior. If the UX practice is new, start small, find that small thing that proves you right, and then expand to bigger activities, bigger projects. And remember the volumes, those that make you really powerful, really beneficial and really important. If you can bring those volumes, everybody wants to keep you in the team and they will ask you to tell where the company should be going. Thank you very much. Any questions? Hello. Hey, thanks for sharing. I really get inspired a lot from your speech. My question is, during our research cycle, we're always facing a lot of problem statements and user needs. So sometimes when we're doing research, we're facing three-hand, you're even more user needs and problems. And for your theory, start small and grow big, but how do you pick the key problems and how do you define the problems that really have the business impact before you're doing that? Very good question. There's no easy answer to that. I suppose it all starts from the high goals that the competent team wants to gain. And then you need to go to understand what are the biggest pain points for the end user. So what is the one that creates frustration? Are there some things that prevent them from using the product? Are there some like blockers that cut the usage flow? So the most impactful problems are the ones that you need to consider first. Usually when I have my findings, I try to rate them according to the significance or the impact. So having like major, moderate and minor findings. So the major ones are those that will block user from doing something. And those are the ones that you need to fix. Then the second one is the more like moderate ones that will impact the experience, but doesn't necessarily prevent. And then the minor ones which are more like nice to have things. Once you have these categories, you need to work together with the development team or whoever that will do the change. And together with them understand how easy those changes are to do. And with your UX significance and development teams work estimate, you get some kind of roadmap on what is feasible and when. You can start creating roadmaps. But the main thing is that you start doing things as quickly as possible so that you see the change, you see the impact that will prove you right and then you can continue working on stuff. So I suppose working in agile mode and trying to concentrate in the biggest pain point first would be the starting point. Thanks for a very interesting presentation. My question I think is revolving around metrics. I guess at what point do you feel the change cycle be considered too long? What is the period at what point you need to be able to measure something? Well it depends completely on like how the company operates. What I try to do is I try to introduce metrics that I can prove already before the implementation starts. So on something that you can prototype easily and then do usable testing. So kind of like measure the solution before it's being implemented so that if there's anything that you need to change more, change it again and again. So doing it in iteration. But the change cycle, I suppose there's no one answer to that. I used to work in one team where we did two week sprints and we were testing during that two weeks. So the team would introduce something on week one, we would test it on week two and they were preparing the next one on week three and we were then presenting during that time the results from the first one and then we're testing the next one on the week four. So it was like taking turns in the week. But it really depends on how the team works. There are still some wonderful companies and with them you need to do bigger things in shorter period because you need to have everything ready before the implementation starts. In Agile you have more freedom because you can interpret your testing and your metrics to the work and the development process easily. Thank you. Will there be any more questions for Anna? If not, UX would like to present a token of appreciation to Anna for her time and Marcus will present the gifts to her. Thank you. Thank you everyone.