 So hi, my name is Maria and I am an interaction designer and my talk is called designer developer collaboration test practices. So I have a quick agenda for you guys. We have just like 25 minutes to go through the whole thing. So I'll touch a little bit on the graphic design and then on UI UX design mentioned several unit agile practices, processes that we have, processes we want, some tools that designers work with like I mentioned, I'm a designer and I'm here basically at developer conference. So I will want to give you some insight on how designers work, how it's done with distributed teams, different sized projects, and maybe also mention briefly some open source design practices and communities. So why am I doing this talk basically? As far as I can remember, as long as I've been working with open source with Fedora and Thread Hat, there's always been some issue collaborating with developers, first of all, because developers have different processes. Oftentimes the teams are set up so they are agile, so they're working in sprints and developers have their own tasks and they have their own statuses for these tasks and they do not always match whatever designers are doing. And also I've been a long time contributor for Fedora and as you know Fedora is in many ways working, distributed all over the world. So the people who contribute to Fedora can live in Australia, in the US anywhere, Europe, India, you name it. And it's also always been a challenge collaborating online and now in COVID times obviously many teams are online and it poses much more challenges that way on how to, for everybody to collaborate even if you know developers and designers work in different ways now there's an added challenge of doing it remotely. And from my point of view, better understanding between the two, I don't want to call them teams, but the two different professions will lead to better collaboration and greater results to be out for you, for yourself and for your users in the end. Okay, so hopefully you will get some insight into designer work, what's UIX, graphic design and for the dimensional ready tools, processes and tasks. Okay so let me talk a little bit more about who I am. So at the moment I'm working as an interaction designer, I've been a tractor for six and a half years and I mostly focus on products that are working inside of Red House, so some internal tools. But also I've been a long time contributed to Fedora and I started as a Fedora design intern, so working on a Fedora design team for I think seven years now and I will start at that because I started as a graphic designer then slowly transitioning to be a user experience designer or an interaction designer if you will. So I will start a little bit about talking a little bit about the graphic design process. So in Fedora design team we use a ticketing system and it's on beggar and we have a specific place set up for it so it's beggar design issues and the issues come in here. So if you want to request anything from Fedora design team, so something Fedora related maybe you want a logo, maybe you want some swag, maybe you want a banner, anything that's you know graphic that would go in there. So the ticket comes in, it's triage, so somebody looks at it, it's assigned to a designer, designer works on that issue so they create some design for you. Then there's a feedback from other designers, we do hold design meetings I think once every two weeks at this moment and then we also like to get some feedback from the requester obviously because if you requested the design you know what you need and we would like to hear from you once the design is created because normally the designer when they work they do not just create this one design well I shouldn't say normal but sometimes they would create one design that they think you requested, one design maybe that they like, maybe something else comes to their mind they want to you know as a professional to offer that to you and we would like to hear from you to basically get some feedback. Then based on the feedback they would iterate and once the design is approved you're done. So graphic design process is pretty linear so you get a ticket, you work on it, you're finished and you're done because you get something tangible in the end. You get a logo, you get an icon or a set of icons, you get a wallpaper for that matter like Fedora wallpaper for example is something we work on. Once it's done it's you know done. Alright so the tools that we use and on the left here I mentioned the tools that Fedora uses for their designs and on the right I also mentioned some paid tools if we are not talking specifically about open source projects but rather any sort of graphic design. Here I want to point out specifically a figure that we start ticketing Inkscape that's a great vector tool to work with vector images and vector graphics. If you're editing some photos you would want to use GIMP. If you're working on something more complicated maybe some interface or website you could possibly use panpod and that's something that we started to use recently and the all the talking right now chatting happens on matrix or element and also is mailing this and at some points GitHub is used to store some graphic work. Okay so some of the challenges that are here that we face working with developers is sometimes people ask us for the wrong thing so something that's not in the capacity of the design team for that matter maybe it should go to marketing or some other field or sometimes incomplete information at the ticket because for example if you're requesting a logo you cannot just say okay I need a lot of logo for my team or my project we would want to know something else like who you are what your project does do you have any idea what it should look like maybe you also would be welcome to leave a lot of feedback because it sometimes happens that the designer would create something and then the original requester would never come back to the ticket and they would not leave anything what they like what they don't like or anything like that sometimes they would do with feedback but it can be outputting so be mindful about what you write some of the contributors can be very new a lot of people like to try out their design skills in the design team so you should be more guiding not outputting when you're writing something in the ticket so you should be mindful that those people are volunteer workers that they could maybe you would not be able to handle all of your requests or maybe they don't you know they only do it in their free time and so they won't have they would want able to be I'm sorry they won't be able to do it very quickly anyway some of the advice and just generally working with the global team of designers and ticketing system is to have well-defined well-documented tasks and maybe some you know resources available but that's mostly for us not for the developers for the developers that would be you know know how to submit requests and here I'm saying developers I generally think everybody who needs something design created right so be mindful what types of tasks you're considering for the design team think about what info you might need from you or be there to answer questions should we need more and like I mentioned so you know so the time frames can be longer because people are distributed people do it in their free time they might have there you know the main job and they will just you know do some Fedora design after hours and the most important part is to my feedbacks always remember to be there to answer questions to provide feedback and also maybe hard but sometimes it's needful to trust the experts or trust the designers that are working on your project probably they have a good perspective on what they're doing okay so going on from there that was a little bit of an intro into Fedora design team I'm gonna go on and talk a little bit about he acts so he's experienced design and he is an attraction sign so he acts is more of a broad term that sort of incorporates UI in it because he acts is something that we're talking about when we talk about experiences and so if we talk about he acts design it's a lot of things in one so it's testing it's writing user stories it's creating personas doing research writing scenarios creating wireframes creating prototypes whilst UI is mostly concerned with interfaces right so it's mostly about how that looks not how it feels so all sorts of layouts colors typography and it's important to remember that these two need to work together because as you can see in this picture somebody designed this road to go this way right so somebody designed this park I think but then the user experience is completely different so they didn't you know look at the user behavior prior to designing this and this is it in my head the main difference and something you need to always consider that you should design based on whatever people tell you anyway there's a quick representation of what I was talking about so this is yes and this is UI right here okay um going on to the whole collaboration I'm still leading into that um I want to touch briefly on how UI and he acts design is different from graphic design process so as you saw the graphic design is very linear so you get a task you work on it as a designer and then it's done and you you are done the main thing here is that you never really done and then you should also collaborate throughout the process not as a request comes in you do it and you ship it off you know ideally a good UI UX designer depending on what they do will be involved from the start so they will be involved in the strategy in this search they're working with developers from the very start working with product owners with QI with everybody and they should be sure they're solving the right problem so the user has also to be involved from the very start and the good UX designer would advocate for the needs of the user from the very start some of the tools that are used here and I want to mention the tools because it's very important that not only designers try and understand how developers in the end put their designs into life so it's good for a designer for example know some code to know maybe some html by 6css at least when they are working at the book cups to ensure that they can be done or at least work with the developer from the very start to you know ensure that the mock-ups are visible that they would not have to change their design drastically or that they've not designed something totally crazy that can not be done in the end I have to redesign it okay so the tools are so some designers start with pen and paper some can use a graphic tablet to draw their stuff very basic at first then they can use inkscape or sketch which is a commercial product that you have to pay for to put the wireframes together here's an example of a very basic design so it's very you know low fidelity mid-fidelity wireframe this is more detailed wireframe and from there you can test already at this point with your user or it's with someone on your team maybe one or two people you can show them get their feedback see if you go in the right direction specifically the developer needs to be involved at this point already so they can see okay so this can be done this makes sense maybe that doesn't make sense maybe that interaction won't work in the end rate and then you could use other tools like sketch for example or gun pot which I mentioned already or figma or anything else there is a lot of them to put your detailed prototypes together and the important part here is that they would be interactive so you can assign specific parts of your prototype to be clickable like this button if you click this button it does this because oftentimes you cannot just hand over and finish design like you put in graphic design so okay here's the picture and you're done no you have to design the whole experience throughout so when the user does this this happens this this screen appears when the user does this that screen appears that kind of thing some of the challenges here are pretty much the same as we mentioned before but also sometimes when there's no clear understanding what the goals are or who the user is or there's no clear direction then the team can steer off in a little bit of you know wrong path and start designing that way so you need to always check back are you solving the right problem get to the bottom of it get to the user ask them is this right is this right for you um again here I mentioned sufficient feedback so a design does not happen in a vacuum you always need someone to bounce your ideas off of to make to make sure it makes sense maybe if you're designing interface somebody has some example that you could use maybe to have a better idea than you that you could put together and that's totally fine one of the most important things is to design a handoff and specifically I want to mention this because sometimes it so happens that the person design something they will design an interface they would give it to the developer and think okay that's it ideally no because when the developer starts putting it together many things can happen they can put it together a bit differently maybe they don't understand what the interaction is it's not easy to document interactions and it's not easy in the distributed team that matter to explain something I always say that it's easier to show once you know to explain in in two pages of text how the design works so you would want to you know design something and then work with the developer show them explain to them hopefully if you can talk to them if you can video chat them at least to do that and also it can be difficult because people speak different languages so designers have their own jargon developers have their own jargon and it's going to be challenging to understand each other so some of the solutions listed here also I want to mention this third bullet here maintain contact with team members throughout and that means that the distributed team would don't often see each other maybe in some team meetings or maybe not even ever and it's hard to understand how the person you're working with likes to work how do they like to get the work to them for example some people would like it if you would talk to them a lot if you would call them from time to time or maybe if you would other people would like it if they you write the messages or if you email them everybody's very different everybody's process is a different some people would like to check in with you all the time some people would ever do that and one more advice would be to just maybe set up a video call if possible with a team member who you're working with and I don't know how many developers are in the audience or there are any designers or maybe some other specialists so I would like to know that at some point but yeah it's very important to just check in with the person maybe nothing even work related maybe just set up a video call and chat about life so you get to know this person better because everybody works differently and to maintain this kind of human contact is very important and another thing I want to mention is the design systems and there was a talk earlier today about design system which I thought was great and I want to mention that I want to mention two more I want to mention pattern fly that is used wisely widely for products and also I want to mention yaksotradhat.com so it's just a site that contains a lot of components that can be used and reused in different interfaces which might be helpful because sometimes for developer if they get a picture they need to know how what's the size of the elements is basically what's the color because the designers can put a lot of thought into that but it's not easy to read from the picture and so just to think this through how you want to hand off the designs how the person who would put them together who maybe a friend and developer how they would work with it some of the tools that I mentioned online they offer an option to inspect the designs so you could see what the size of the element is and how you could put it in code or maybe you could directly copy code from there and that's much easier for everybody I want to also mention briefly here the open design framework this link works but anyway so that's something that the whole team agrees on so that's the tools that's the processes that's how these design tickets are incorporated into developer tickets and their processes and also how maybe the personas are set up for your process let me speed up a little bit because I don't have much time left all right and so I also want to mention all the uniax which is a sort of it's a process that's been incorporated a couple years back and so that allows you to focus on the outcome so not to build the whole product from start to end with a lot of bells and whistles and features but rather build something that's an MVP so the minimum viable product it's core concept of uniax so you build something that's it wants functional reliable usable introduce maybe some emotional design is focused on users tested throughout but it works and and maybe it's minimal but that can be built upon rather than it's just functional and does that okay so what else can be done you also can hold design thinking workshops and here I'm going to do a quick plug-in tomorrow Marie Norden and I are holding a design thinking workshop in the afternoon and you're welcome to come we're going to do some design thinking exercises and don't be put off by the word design it's more of a way of thinking not of designing stuff one more thing is design reviews it's something I like to do on the teams that I work on so I would invite everybody who's on the team and who can come so we can look at designs we can talk together we can see if we agree on what needs to happen and just you know agree on further steps and always people have a lot of great ideas that we could incorporate in the designs later here I wanted to mention that there are a lot of processes that exist like design thinking lead agile anything and unfortunately it's impossible to solve the whole design developer collaboration problem with the process it really really depends on how the team is set up on how the developers work and maybe it can be different for every single process and let me just get briefly to hear a project right because different projects are different sized and so they have different stages something may be shorter something may be longer but you know you have to be mindful of that and as a designer working with a developer you have to be mindful of that too let me go back on second I also want to mention briefly as a closing maybe almost know the ten usability heuristics I will so my slides are posted on uh shed.org so you can download them or you can hop in I don't know so I will be sharing my slides after the talk and I want everybody to be mindful of these heuristics they are very useful I add them printed out so we'll think about them all the time and I think for developers too it should be very useful to think about this too just to you know to give you a user in mind to keep their behavior in mind and help them out when you're building something um also these are some process diagrams that exist and this is ideally what would happen when you're working on a project but it's not always what would happen and here you could see um what and maybe even who is involved at each stage and ideally all the team or developers and designers for that matter would be involved from start to end so they talk together constantly so they can reiterate so they understand so they're on the same page and they talk to each other not forgetting about the user okay so I guess with this I'll close and we'll have a short Q&A maybe you could give me some advice on how to work with developers better because I would love to see who's in the audience today and if you have any questions and let me stop sharing my screen okay oh thanks Maria unfortunately I don't think we have enough time for Q&A we're kind of at the end here so if uh if they want to reach out to you with the questions I'm going to copy the questions from the Q&A but if anyone wants to reach out to you how can they contact you how can they contact me um let's see well I'll be here I mean I've gone in the event so maybe they could message me in chat right on and and you did say there's a workshop coming up where you're going to be there too yes it's going to be tomorrow cool that's right well thanks a lot Maria that was a great presentation