 you mis-designer, give me a bunch of new icons by tomorrow. And you, Mr. designer, I need this new legal, the new design for the legal page next week, latest. This is perfect. This is how it perfectly doesn't work. This is how the perfect design process does not work. I was thinking a lot, what can I teach? What can I teach you? What can I teach a group of super experts in this user experience area? What can I tell you what you don't know? But then I realized there might be something that could be interesting for you. And these are what I've learned throughout the last seven or eight years, teaching people live a new user-centric culture. And to show you how to overcome the obstacles you will be facing. I've worked with so many great teams, like with hundreds of perfect teams. But I've also worked with three teams which really made me feel like I should stop it. For example, one guy was with Link the whole hours in our workshop. He didn't participate. The most important person in the room just didn't want to participate. And in the end of the workshop he told me, I knew you will fail. I knew this approach doesn't work. Or another guy just hit me with paper on my head. People behaving like kids because I wanted to show him how to change things. How to improve the way we collaborate with the customer. People behaving like kids, don't be frustrated. Don't give up. This is something I want to give you as advice. You will face things like these. You will be frustrated. People won't be willing to change their culture quickly. This is something I want to give you as advice. I will give you a list of three little things you can change to gradually change the culture of your company. I don't want you to be like suppliers of icons and new designs. This is not a meaningful work just to be the afterthought. By giving you these three things I will try to show you how you can make the life of every involved stakeholder more meaningful. They will only accept changes if the changes give value to their life. I will give you these three small things. If you change them you will gradually change the culture. Expecting an important call. Let's start. The first thing I want to teach you. There are some great quotes. Use whatever you experience in your everyday life. Have all your learnings and use these quotes. I love to use every now and then to show people how we want to live the process of user centricity. The first one I really find most convincing is tell people around you. For the customer the UI is the product. This will make them think. All the developers think the code is the best. The code is what makes our product. For the customer the UI is the product. If the UI is the product how can we hand this task to just one person? If we want to sell this product to thousands of people how can we give this task to just one person? And it sounds like a declaration of war against all of you. Design is too important to be left to designers. It needs to be put into the hands of everyone. This is a quote by Tim Brown, the CEO at Ideal. The company who invented the design thinking approach. So don't give the design to the designer. Hand it to the whole team. Don't do their work for the team. Do it with the team. And this is exactly my first advice to you. Grab everyone who wants you to create a design and ask him to provide his thoughts. You won't be showing any weakness by doing this. It's telling the person I respect your knowledge. I want you to give me your idea. Grab anyone around. Let them just put some ideas on paper. And you will immediately get much more feedback about how the design should look like. This is a small example from a small task we did in Darmstadt. Three people just sketched quickly something. And the person who was responsible for the design immediately learned that his idea was bad. So grab whoever you can reach. Start with small collaborative sessions. Don't do the design for the team. Do it with the team. So my first point is be collaborative as often as possible. Grab people around you and show them it's all about collaboration. This is the usual design the process left at most companies. Someone gives you a feature to a team. Then it will be developed at some point. You will be asked to give me a design for it. I have one, beautify it. Or provide some icon. So they treat you as a supplier for, like give me two bags of usability. This, so you can lift this part collaboratively. But it often will lead to a solution, to a perfect solution for a non-existing problem. Design is problem solving, as you all know. That's why we should start this collaboration much earlier. Our job is to improve, is not to improve the product, it's to improve the people's life. And that's what we want to teach the stakeholders around you. This is what we want to make them believe. We don't want to have a great product. We just want to improve the lives of people we are serving. This is our goal. And you cannot solve what you don't understand. You cannot solve what you don't understand. This is why if you try to change the product, in this case, you probably all know this picture. It's this famous picture sent in every user experience group. If we try to improve the product, we will put some benches and more light on our product. We want to improve their lives. They want to reach this point quickly. So if we create a perfect solution, it will be a perfect solution for a non-existing problem. So improving this product won't help you. That's why we just need to spend much more time on understanding the problem. You cannot solve what you don't understand. Spend as much time as possible in this understanding area. Try everyone around you to understand the problem we will be solving. And this leads from this development process to one where we will be starting in a phase where everyone around us will be trying to understand every aspect of the problem area. And only then, if we really understand everything, we will try to find the easiest solution for just this problem, not nothing more. So instead of working with features, try to tell your product manager we give us a problem to solve, don't give us a feature to build. Do you see the difference? If you start working with problems, pain points, you will be more empathetic. If you tell the team to build a feature, they will create a technical product. If you tell them to solve the problem, they will want to understand the problem. And this all happens before one line of code is implemented. So the second tip I want to give you, the second advice is whenever someone asks you to provide a design, well, yeah, do it collaboratively with them. And then, like a side note, ask them what exactly is the pain we are solving. Describe the pain only with this information I can. We can create the perfect solution. Ask them, like it wasn't important, tell me the pain. They often will be able to tell you the pain, but I really, really, really often see teams not knowing the pain. They cannot describe what they are solving. They know the feature. They know the list of acceptance criteria. They know all the technical aspects, use Java, whatever, they know everything about the technical aspect, but they cannot describe the pain. This is like a door opener into user centricity. Ask the stakeholder to perfectly describe the pain. So promise to solve problems, not build feature. And when they cannot describe the problem, then they will understand that it's necessary to find out what the user problem is. They will understand that we need some contact to the customer. So the contact to the customer at this point will be like the solution for the non-existing pain point, or people not knowing about the pain point. And the idea here is to make everyone understand the customer's life. Put them, put people around you into the customer's perspective. You want to see them behaving like this. So watch your customer play with your product. If you see them behaving like these kids, you know you have created a great product. You want to see if they are frustrated or not. You let everyone around experience how the user feels. What is your everyday life? What are daunting repetitive tasks? And search for a pain point. A pain point is not a small problem they will be telling you. A real pain point is something where you feel the frustration and where you see that the customer is willing to do something about this problem. And only then, if you find something like this, only then try to fix it. And don't fix anything else. Do less better. Find out a real pain point and then dig deeper. There is the perfect method of digging deeper called pipe wise. So if you find a problem, just ask why as long as possible. Until you know what the human problem behind it is. Ask people why I frustrated. Sorry. Important call. Sorry I have taked this. Hello. Hello. Hi Adams. Important customer. What's your problem? Yeah, Adams please don't ask me how am I today. I have one feature improvement which will make my life very good. So you know this monitoring tool? Yeah. It has a status button and it always gets lost. So there are so many tool items, tool items, menu items and it just gets lost there. I just need that button to be bigger. That will really make my life good. Please don't ask me how am I today. This is going to screen my life everyday. Sorry about that. I feel your frustration. Sorry about that. He's frustrated. He's losing time. Pain point. But why do you always search for this button? I mean the product just crashes two to three times every day. I need to know what's the status of my monitoring tool. It just crashes every time. Why does the product crash so often? Why? I mean it could be the log files. Most of the time I find that the log files just get building up and I need to delete them manually and then restart my server. So if I don't know what my current status is, I just lose time there. So it will be very, very helpful if that button is just, it stands out with other button. I get that point. Thank you. Do you see the difference? The first pain point where he stated his frustration. He told me I'll lose so much time on finding this button. You could just improve the button. Increase the size, make it like such big to make him see the product crashing every now and then. But it's not the problem you want to solve. You want to solve this issue with log files running while filling your disk space. Ask why as long as possible. If you see frustration, if you see this puzzled face, try to find out the real reason why he's searching for further information. Try to find out what is the reason. Try to find the real pain point. So all you start up companies fix a real pain point in people's life and you will create a successful product. So there are some methods. You could use here, but the point is whenever people ask you to provide something, ask for the pain point. Don't think about methods. These are the small steps how you can change the behavior. Don't try to change the world in one day. It won't be possible. They will always keep telling you we, but we don't have access to customer. So keep asking what is the pain point? At some point they will realize we need access to customer. So don't think you can change the world in one day. And then at this point, they will be sometimes able to describe the pain point. This one team in Darmstadt asked me to improve the quality of this design. So I could have told them, well, I don't understand this icon. I don't, well, the usual usability feedback. But I asked them to describe the pain. And they told me we want to, the customer wants to get rid of waste in his eclipse environment. So why don't you just create a solution like this? After 30 minutes they realized the solution they created is like a huge overkill. We reduce the amount of work in 30 minutes by 90%. It was just one button in the right mouse menu after that. Fix the pain point and nothing more. Don't try to build a complex solution for non-existing pain points. And if you have a complex problem, work with this beautiful method, brain writing. Don't ever brainstorm. Then brainstorming. Brainstorming is bad. You don't want to lose many ideas people have in their heads. So whenever you talk, it will influence his thoughts. The quiet ones won't tell anything. There will be two people speaking 80% of the time. So you will like lose 80% of the information by doing this. So write down whatever you now pass this piece of paper to the person next to you. And steal ideas. This is the magic behind brain writing. In the end, you will end up with a wall full of information. And this is what you want to have. Don't make important decisions with incomplete information. What's on the back of this cube? What's here? You all know Rubik's cube. Which color? Orange. It might be red, it might be white. You just don't know. Don't ever assumption anything. Assumptions will kill your product. You will want to know everything about your product. With every assumption, even an obvious one. So everyone in this audience thinks it must be white or whatever. But it isn't. Your assumption will destroy your product. So you want to have a complete list of information. This is the key here. And only then start to collaboratively find the perfect solution for this one pain point. And this is again the power of collaboration. It's not about the genius, the one who finds the perfect solution. It doesn't work like that. If you want to have a good solution, have many solutions. You can search for a genius who has many solutions and many ideas in his head. But it's much easier to rely on the ideas of everyone around. Why don't you ask people around you? They all now know the problem. They all know how they would fix it. Let's ask them. Just quickly put every idea on paper. Immediately, whenever people start talking about solutions, ask them to grab a piece of paper and sketch the solution, as I showed you. They will immediately realize, I like this solution. Oh yeah, this part of this solution is great. And this won't work. In just five minutes you will find out, yeah, this is great, this is great. So these three great ideas you will find in this first iteration, they will all survive until the real prototype will be created. This is the power of collaboration. And show your stakeholder how it feels like. You involve everyone around and they will be part of the whole process. Everyone feels better in this process. It's way more meaningful. This is a management meeting with directors and vice presidents. They all work with these methods now because they are fun. See them sketching solutions for their problems was fun. And then you have some, well, prototype. And at this point you want to validate if you created the right solution for the right problem. You know you have the right pain point and now you want to validate the solution. And do this step, this prototyping step in front of the whole team. Let them feel the pain the customer has with your product. Or let them feel the joy he has with your product. They will want to fix what's broken. You don't have to create user stories for what's broken. They will want to create a solution for this problem. And use whatever people can use. Like POP prototype on paper where you just take pictures of your paper prototype and connect them. You can use PowerPoint. People use it very often at software AG because they know how to use it. Everyone's contributing to the prototype. Not only the designer. And this was a workshop in Washington this year. This guy is a person who will be using the product. He's testing POP part of the product was on POP and on paper. He wanted to have the product, the solution immediately. And people around him were all clapping, applauding. They feel more engaged in the whole process. These small steps change everything. And this is a quote by me. People at software AG know perfectly I'm the guy who doesn't allow demos. Don't ever demo your product. You lose the first impression of important stakeholders. People keep demonstrating their product to product management. And product management is like I don't like this. I don't like this color. If you let them play with the product, they will either fail or not. They will either be able to go through the task or not. This is what you should think of. The small steps, the small tweaks. So watch your user. Grab your whole team and let them watch the user every six weeks. You will improve the quality of your products in just a few months. It's incredible. There are teams at software AG working like this and I love it. It's great how your team works. And this is key. Just invite everyone to the test session. These small things are important. And this is the third point I wanted to give you. Watch your users. So whenever people tell you I want to teach my team design thinking and I want to have more designers in my team. This won't make your company design first company. You have to change the heads slowly. And the reactions, they react very positively. They really feel that this is the right way to go. They feel the difference. And what I find most important for you, designers, it adds a new dimension to the work of a UI developer. This is what I want to give you. Please, I want to make you more important in the whole process. So these three things will change the quality of the life, the quality of the product, the satisfaction of the user. And it will give more meaningful, it will make your life more meaningful at work. And this is my advice to you.