 Yeah, hi everybody. Thank you very much for being here This is our second talk here. So I had already a talk about QML bus practices Those who have already seen my first talk They will probably notice that this time this time these slides were created with help of a designer Yeah, let me please introduce my colleague. This is Samuel Knoch. He's use experience designer Just have to do the pre-centre doesn't work. Okay. Yeah, so this is Samuel Knoch. He's experience designer My name is Fridemar Metzger. I'm software engineer and we are working at ArgoSign We are one of the leading user experience companies here in Germany. So we provide user experience design and UI development So somehow the batteries might Sorry guys Oh, that's funny. Okay. We'll do like this So we are doing user experience design and user interface development and we're doing that from many fields that is consumer Industry and also medical solutions. So what we are doing the whole day is creating user interfaces and We are doing that with The user centered design process Samuel, maybe you can explain that a bit better than me Yeah, sure. So there's a deep process basically means for those of you who don't know That's basically means that users in the center of all design decisions and all concepts And we really try to make sure that we don't design for our clients or for for the manager So we really try to focus for the user and in the process we have different steps and So at the beginning of each project We actually go out to the user interview them asked for what they actually need and try to find out how they work And then we obviously do the design Both conceptual design visual design and after that we go back to the user and try to make sure that What we have done is good for the user and we give them some prototypes let them try out stuff and gather some feedback So that's basically the part what I do and after that after the user is happy with our designs We hand it over to the development and that's where freedom and comes into the game Okay, let's give you a short introduction about the problem. So once upon a time there was a designer who created a beautiful user interface and Then this design was however develop was however to deliver to to the development maybe with some kind of style guide or some other design specification and Yeah, the development start working and sometime later. We have a final application which maybe looked something like that well Yeah, maybe in the first moment that looks pretty good But if you compare these both versions you will notice that Yeah, the the usual design look very much better than the final result and if we have a look in more detail So what finally went wrong? So we have the wrong icon. We have a wrong font color here the shadows are missed and here is some kind of decoration missing and Yeah, know the discussion about who to blame for said starts Maybe from a designer perspective for these stupid developers. They always destroys my beautiful craft design and From our developers perspective, we say all the lazy designers there. There's always missing something in the design specification and Yeah, then the product manager comes into the game. So at the end there's usually also a deadline and the product has to be shipped somehow and So at the end there's probably not a much and not enough time left to get the product right and so Hey So at the end The underlying reasons for what happened in the project might be very different and there are loads of reason and at the design The problem might be maybe I just didn't understand the user's goals when I had the analysis phase Maybe the budget was very tight. Maybe my Specifications were not really complete There are tons of reasons what might happy or my concepts are not good enough or Maybe I just don't have enough experience and knowledge about the technology for the development Yeah, and from the developers perspective, maybe they don't have any experience with UI development because user interface development So a software developer isn't necessarily the same as a user interface developer. There are a lot of additional skills needed There the development can misunderstand the requirements, for example imagine an HMI context We have buttons which have to represent every time the state of the machine instead of representing instead of displaying just its own state or They maybe have no knowledge about design principle, for example, if we deliver some kind of Discontrolls and the customer is responsible to build their own Views with the controls they need to know how to do that correctly that it behaves good and that it looks well And yeah, finally the most important thing If the development has no idea about the intention behind the design, then it's very very complicated to to Develop the controls like they should behave Well, we have seen we have seen that there is a yeah They're the way from the ID to the final product is very hard and sometimes sometimes also dangerous the ID through design land to develop country and then finally to the to the Application and in the next hour we want to talk about options how to improve this journey and what we can do to Make this way a bit easier So there are a couple of things we might have to consider and And we are going now in the next half an hour from design land to develop country and the first step at the beginning is So is how different are the people that are involved and it's really important you probably know that designers and developers can be slightly different sometimes and I really like that slide film and found it a couple of days ago and It shows it really nicely because in the first moment developers and designers look quite similar And they are hacking some stuff into their laptops But if you look closely the way they think and the way they work is very different And so if designers and developers look at the same thing They might have different perceptions of what they see and it's not about right or wrong It's just different perspectives. They have so we have a little example that shows exactly that and That's actually something that happens in a lot of cases and in a lot of projects so one of our designers created a little flyout menu and specified it and Gave it to the development and it looked quite similar to that one So there was a button and the flyout menu and some menu items in there and the designer added some examples About how many ads how many items can be in there and how they look So the developer also thought hey, that's clear. I'm gonna do it But then he finally came to a question what to do when there are three menu items and there are basically two possibilities and At the end the designer had a different idea than the developer Yeah, and from a development perspective with what it was pretty clear because there was no Specification for this cell here. So the developer didn't know how to style and how this this yeah This way to display should it should be implemented So again, that's nothing about who to blame or whose fault it is It's just misunderstandings that happen a lot when designers and developers work together So it's not only about different perspective. It's all also about different knowledge designers and developers are different people they have different jobs to do and That's also the reason because they are a designer or a developer and so We have to find a way to get the knowledge somehow together and form one union with our knowledge Yeah, and it's also very important that both need to love what they do. So what I mean with that is We need to have an intrinsic motivation to To develop a good product. This is very important that it doesn't make sense of the developer doesn't care about any design decisions So we need to have fun While implementing some controls or yeah Work around this pixel stuff. Yeah So at the end and we Can maybe learn that designers and developers are very differently and they work very different differently but at the end both of them are equally important in the project and No one neither the developer or the designers more important They are both next necessary to get a good result. So we have to appreciate our different knowledge and our different perspectives the next step is To get somehow an understanding so we have these different knowledges and these different perspectives and these Misunderstandings are cure so we have to find out how we can reduce these misunderstandings and that's basically by understanding each other in a better way Yeah, from a developer's perspective, it's good when we tell our designer how we work So they can take care of that so we need also to tell them about the framework characteristics We use for example if we are doing a QML project It's very important that they know that it's very easy to work with animations For example that it's very easy to add some kind of effects or transitions and all these things and if they know that they can respect that later in the design and From the other side is also very important to tell them about Restrictions for example. Yeah, and in Qwitted It was pretty difficult to work with shadows on the things and if they know that they can take care of it Yeah, so basically at the end it comes down to share your knowledge and if freedom one tells me about the stuff He does and I can develop some interest in it Then I can respect that in my design decisions and also make sure that what I'm doing is what you need and on the other hand It's also good if the developer knows something about my stuff about the design process About the user goals and about all these design decisions. I made in the beginning of the project Yeah, and it's it's very important to know the boundaries For example if if the design the designer of Samuel insists on something then I need to trust him it has a reason why this should be implemented like this and I need to trust that it will be important for the user experience and In that case we need to do or our best to to yeah to to make the visions real finally and Also if something is too time-consuming because well, maybe the deadline Isn't far away or the budget is low then we need to explain it and we need to discuss Maybe some alternative solution and in the best case we we will find a compromise Yeah, that means also that It's very important to have a good relationship between designers and developers So sometimes it's very important to talk about problems to talk and to be honest and for that It's a good idea to Especially in longer projects to sometimes go out and drink a beer together Just do it to to to have a better relationship in this case. Yeah so make sure that you really share your knowledge and I know as a designer that you know a whole lot of cool stuff in the development and I also know something a little bit cool about the design So it's really good if you can share these the snowlets with each other Now we've crossed these little stones But the next step is a very important one and that's the handover So in our project as I said before we first have the design then we hand it over to the development And then it's actually implemented And so for the handover it's really important that this Happens all right if the handover is bad the end project result will probably also be bad But if the handover is good you can at the end save a lot of time Yeah, so they're different kind of specification documents the designer can provide us for example Yeah, the control specification itself. They can prepare Animations there can prepare Yeah breakpoint scaling we have behavior all the things can be documented But the most important thing is to understand the overall vision of the designer. So we need to take care How we get these this information and the best way is to do this kind of hand over face to face so if we if he gives me a design specification for example we usually sit together in a meeting room and he explains me step by step what to do and this is very important and At this moment I can tell him what I need to implement the design specification For example, if I need additional informations like yeah Maybe an interactive prototype or something which would help me to to understand better What what the intention was then I can ask him to do this for me? So it's very important to to understand the behavior instead of yeah, just starting the controls anywhere So This is some kind of interactive prototype prototype which Samuel prepared for me And if you have as a developer something like this is it's much more easier to to understand how all these things should work together and Yeah, if you have something like this, then you don't need to read Hundreds of pages documentation for example because it's I can directly see how how this how it should behave And I don't have to write specification. Yeah, it's much more fun to do to a prototype than writing PDFs Okay. Um, well, I already explained most of the things here on the slide so but Not bad to repeat it again. So Sometimes and some projects we developers are the first non designer who had to really think in To to think very deep into the into the design and into the user interface and At this point, we will notice maybe some problems with first-time use or especially edge cases or in between cases or we will notice said that something is missing with a scaling behavior or Yeah, we have the questions Okay And what happens with the user clicks here and all these things we can directly or we should directly Discuss with with the designer Yeah, all these things with first-time use and edge cases as something we have the design Actually don't think about too much. So in the design we think about what happens if The user needs this or needs that and we we think about the 80% solution for the user to make sure we We have all concepts and all our scenarios Implemented and we have the functionality the user needs but something like you see on the image. It's basically a Message box which shows warnings and errors and of course we care in the design about what happens if the list is too long And what happens if the user clicks on it? But actually the first time you stayed or like the state when it's empty We don't focus too much in the design and that's a reason why me we might forget something And so be patient with us and just ask us and we will not be angry if you ask us On the other hand, it's if you ask us it shows me that you are really interested in and trying to get the knowledge So To sum up the third chapter get the designer's vision and do a handover face-to-face and ask everything everything you need So the fourth step is about collaboration Also after the handover you have to communicate a lot and collaborate a lot and We also have some some tips for that Because otherwise it ends like this and that's actually Happens a lot of time the designer might be slightly annoyed when you asked so many questions and Give some answers that don't help you like just implement the standard behavior Which of course is hard for you because there usually is no standard behavior or I just say there's obvious and It might be obvious in my mind But not in yours and on the other hand the developer feels that the designers is not Trying very hard and so he's also not trying a hard very hard and maybe just doesn't ask and just does it like he wants to be Or he propends it nothing. It's not possible, but it actually at the end would be possible So what can you do to prevent that? First it's very important that you communicate early in the project not just at the handover and maybe a little bit after Try to be involved in the project already when I'm doing the designs It's not something That I feel bad about if the developer sits in the meeting and tries to tell me what I have to do No, it's really helps. So I really appreciate it when when in a project and where we're making design decisions there's also a developer at the table and Maybe tells me something about the technology or the framework or what's what's possible to do and what's hard to do And on the other hand you will get the right image and you will get the vision and you will understand Why I make certain design decisions? You also have to communicate longer in the project Not just the handover and then it's done Try to have the designer Working with you through all the development project So when we are having projects We have the good situation that it's actually part of our process And so I have about 10% of the whole development time allocated for me as a designer And that's actually really good and we usually need that time because there will be questions And there will be missing states or missing controls or our customer might just have new requirements and I have to to design something else and If you don't have that time you will probably as a developer end up alone And just have to think about all that stuff yourself. That is actually part of the designers job Communicate very frequently We have some little chat bubbles here We try to communicate every day in the project and it usually Starts like a freedom has a question about a control or I forgot a state and so freedom and ask me Hey, what does the press state look like and usually these things are sorted out within two or three minutes so it's not a lot of time and If it gets more complicated we switch to the phone or make a screen showing but it's really important that you keep in contact during the development Yeah, this is an example we just had a few weeks ago Samuel wanted no, I needed to style a Q3 view with cursor style sheets and he wanted to have The space for this small triangle within width of 60 pixels But he also want that the offset for the hierarchy levels very 40 pixel But this isn't actually really possible to do this with cursor style sheets because you can only set one Indent and this indent is also used for this triangle into the space So what I finally did is I asked Samuel I talked to him via phone and I explained him okay, so there are few possibilities the the easiest one would be to well just Adjust the indent a bit or yeah I had to touch some c++ code to to make this possible and yeah We found a easy solution. We just took we just said okay Let's take 50 pixels the difference negligible and yeah, it will save a lot of time in the development later Yeah, and This is also something very important. It's definitely definitely not the best case scenario, but in some projects There will be something change on the design while we have already started implementing the controls and especially in this case, it's very important to to communicate a lot and Every time I start I would like to start with the with the development of a new control I will directly ask him. Hey Samuel Do you think that some something will change or is this control already finished for 100% and then he can give me the Green light and I will start to develop the control So to make sure that the quality of your work in a design way is what I have What I wanted to have Similar it's good to her make with design reviews and Really often it's like this you have a design and then you have a development and like one day before shipping the designer Looks at it again, and there might be some some differences and then there's not enough time to correct it and So try to make design reviews frequently For me as a designer design reviews are always a little bit hard because I have to criticize you guys You guys For you what you are doing, and I have to say hey, that's wrong and that's wrong And this doesn't look right and I don't really feel good when when I have to do that with your work because I know that You tried really hard So just keeping in mind it's part of my job to to make design reviews And it's part of part of my job to focus on all these little details Another method you can use as Retrospectives after the project So there are a million different different Ways to do retrospectives The key of a retrospective is to get feedback of your your teammates And to get honest feedback not just really maybe a male just talk to talk about the project face to face And the way we usually do it is like this We literally have these blocks on a whiteboard or a flip chart and then everyone collects some Post-its and writes down what he's what he has thought about the project and so there might be negative points There might be questions. There might be points to discuss Also, you shouldn't forget the positive stuff But the key of all of this is to get feedback and to make sure if there were problems You can do it better in the next project So at the end both of you are in one team and both of you want to create a good product And you have the same goals and so you also should collaborate and communicate as a team So we are finally in developed country and the last chapter is about cute So This little prototype It shows you have seen it already I know but it shows like a lock screen For an industrial machine. It's a very large food processing machine And basically you would slide up the lock screen if you want to see the interface and then you can log in and After the look in you see the actual interface and on the other hand you already of course can slide down again and That's the thing which I was really surprised. It was great fun to design such a thing but If it were made in other technologies It would probably have been not possible in that way. So I'm not I'm not a developer I don't know exactly but usually when I'm when I'm making broad projects that are not in cute that developer would say oh, that's really complicated or scaling behavior Responsive is not possible and animations are very very hard with the performance and That's actually a cute a cute thing about cute So freedom I'm actually encouraged me to add some animations and to think about transitions and all that stuff and in this case we Actually ended up doing all that stuff together. So I made a design draft and I made this this prototype And headed it over to freedom on and then obviously he wrote the code because I know nothing about development but We did all the transition fine-tuning and the animation fine-tuning together and we really set side by side and Thought about easing types and animation duration and tried to to get out the last few percent out of the product Yes, yeah, it was one time. It was pretty funny because then we had to gather a look in the code And he just said oh, can we make this a bit slower? Maybe I was looking to my code and there I think it should be adjusted here. Oh, oh cool So I'm not used to to to to see that designers Understand something in my code and yeah, we're QML is very lightweight. It's very easy to understand It's declarative and yeah, so also designers can understand something that's necessary Actually, if you know a bit of CSS, it's not too hard to understand the QML code I could not write it, but if I look at it, I I have an idea what will happen So, of course, we have our tools and I start with scribbling and then I'm doing the designs and I like doing these prototypes and Antitype or other persons might use sketch or illustrator and of course the developer has different tools But at the end our work can be a little bit closer together So we can close the gap between design development a little bit Yeah, so we already started to use QML and cute as already in the design and all the ready in the protot So especially in the prototyping phase of such a project and It's pretty cool because you can very quickly try out animations and all these things then finally we're able to reuse Some code snippets in the later development project and this is why Yeah, why it's very good thing to do development. So user interface development projects with cute So at the end you can release a safe time with with cute and by doing it together now we have finally arrived at developed country and If you happen to work together with designers Maybe just try this a little bit and try to appreciate that you are different and Share your knowledge and try to do a really good face-to-face and over and really communicate together as a team Because designers and developers might look different a little bit and behave different and have a different way to think But both of them are really cool people and we are having a lot of fun in our projects Thank you Yes, so we have a few minutes left. Are there any questions here? Yeah, you use Adobe Illustrator During this design process. What is your usual step from coming from Illustrator or PDF or whatever the output is of Illustrator to a QML design basically Usually we don't use Illustrator So it's one tool we use dependent on what the project is like, but usually we use a tool called enter type I don't know if you have heard about it. It's actually developed by our company and In anti-type we can do The conceptual design with wireframes and also the visual design and there we also can can do these dynamic prototypes and so at the end that's the base for our Specifications and we also give this enter type file to our developers So they can have a look at it and they click on an element and directly see the size and the color and on the dimensions So actually we don't just illustrate it too much if it's possible to work with enter type Any other questions? I'm a little bit curious about the topic testing because The design concept has to be tested somehow and how can you integrate? The testing people into that process. What's your idea of that? We usually try to do the testing at an early stage in the project, so If it's possible, we do the validation even before the visual design so we Make some wireframe frames and we make sure we don't spend too much time and refining all the details and Already then we go out to the end users and test it so So we try to do the validation very early and just after the concepts are finished we hand it over to the development Was that your question or? Yeah, the testing on the development Yes, sometimes it depends on the customer so Often the customers they have its own tools which they want to use Yeah, it depends. There are different tools on the market. So which we're doing here for for automatic you your eye testing I have two questions One is how can we get? Like these graphical thinking design people into thinking about things like Accessibility and more like information flow, which is like how we think and we kind of sometimes complain that the designers They so graphical and how do we get them there? That's one question and the other question is that the Tool you mentioned is developed in your country a company any chance to have it as free software This would this is just missing so much. So this standard if it's good Yeah Well, I think the first question was for you maybe Yeah, how The question was how can we get the design thinking into the development kind of thinking Yeah, yeah, it's absolutely absolutely true and And the design we Sometimes we maybe we should think about it, but usually we don't think too much about it and I think it's At that point it's really important to to be together very early So if you if you are actually in the meeting when we are doing the The main layouts and the basic the basic design decisions Maybe if you if you trigger us and ask about that even then at the early stage, maybe we we can do it So that would be my tip Yeah, and I don't really know what to answer to your second question, but I think This software will not be open Because it's it's also written. It's also it's only available for Mac. So it's Mac only to and I That's a free trial though Okay, any other questions so yeah, thank you very much