 All right. Thank you for hanging in, everybody. Next up, we have OpenSourceify, your design process by Laura Wright and over to you, Laura. Great. Thank you. Hi, everyone. My name is Laura Wright. I'm an interaction designer on the Red Hat UXD team here. I work on predominantly OpenShift, but I've been at Red Hat for about three and a half years now and I've worked on a couple different products. So this talk will kind of cover mostly my experience with working on Rev as an interaction designer and also interacting with the overt community. So we can get started, I guess, right when the clock hits 2.30. Okay, great. So hi, everyone. Welcome to the OpenSourceify, your design process talk. Today, we'll be talking about how you can apply an open source approach to the design process, whether you're new to the design process or a seasoned veteran. The goal is to provide you with resources and different methods for applying an open source method to your design process or open source methodologies to your design process. So for the agenda of this talk, we'll first cover exactly what OpenSources and what the design process is just a level set. And then we'll dive into the different stages of the design process and how you can apply open source methodologies to those different stages. We'll also cover the topic of contributing design work, some pros and cons of an open source design process, and then we'll wrap up with a conclusion. So first, what is open source? The term open source, according to this opensource.com definition is a term that refers to something that people can modify and share because of its design, because its design is publicly accessible. So when we talk about open source, we usually talk about it in terms of software or code, but it applies to design as well. The definition above directly references the word design, so why not take more of an open source approach when it comes to the design process as well? What is the design process? The design process is the process that is used to come up with solutions to a problem. In a nutshell, the design process usually involves some sort of discovery, design and testing phases. So open source involves principles like transparency, collaboration, release early and often meritocracy and community, and each of these different principles can easily be applied to any of these different stages of the design process. And when it comes to the design process, there's the concept of user-centered design principles, and they hold many of the core values that open source principles has. It seems that open source principles and user-centered design principles are more or less one in the same when it comes down to the root of it. So first we'll start off with the discovery stage of the design process. At this stage in the design process, your goal as the designer is to learn as much as you can about the user and the problem space. You can talk to users, the community, and subject matter experts at this stage. During this discovery phase, your main job is to do as much listening, absorbing of as much information as you can, and building empathy and understanding to the users that you're designing for and with the community that you're working with. To open-sourceify this step, you could utilize social media channels, mailing lists, subreddits, forums, or any other direct place where the community is having conversations. If the community already has established communication channels, I would highly recommend using those instead of starting new ones. There's really no need to reinvent the wheel when it comes to communicating with the community, since you really want to meet them where they are. So in my own personal work with working with the overt community, I actually used the subreddit, so it felt kind of funny using Reddit as a means of communication for work-related things, but it proved to be a really great communication channel to work with the overt community, since that community was pretty active and willing to respond and have conversations via the subreddit. So using the subreddit, I was able to set up user interviews, post surveys, and I also got input from just posting or asking questions of the overt subreddit community, so it proved to be a very useful place to connect and talk to folks. So with using any of these different communication channels, it always kind of depends on what the community, what their history is with either talking to design folks or what level of engagement they kind of have. Because as a designer, you're kind of coming in as an outsider, so you don't want to feel like you're going to rock the boat or anyway, so I always kind of play it a little bit just open and conversational at first. And then the more you get to know the community, that's when you can maybe start asking more hard-hitting questions or start to dig deeper with that conversation. So just as a general disclaimer, these are just a couple of the different methods that I've used in my own experience. I think when it comes to doing open source discovery, it's pretty freeform, so if some methods work for you and some do not, that's totally cool. So another way that you can open sourceify this step is, depending on how those previous conversations with the community go and the amount of interest and response that you get, you can set up direct either interviews or send out surveys to the community to get even more detailed input from them. If the community doesn't respond at first, that's okay. It might take a couple tries to get that conversation going. From my experience with working with the overt community, there were folks in the community that were willing and always signed up for surveys or user interviews, but on occasion you will get folks who will be no shows. So when you're either planning, especially user interviews, since those can take a bit more time than just sending out a survey and require a good amount of effort on the participant side. So they might not show up, so just keep that in mind when you're starting to plan out any sort of research study or user interview schedule. So for even more transparency at this stage, you can share out a link to your personal calendar so folks can schedule a time to meet with you. So in this case, I was setting up user interviews with participants in the overt community for a usability study that I was doing. So I actually opened up my personal Google calendar and set up appointment slides or slots so people could access it and set up a time that worked for both them and my schedule. So this method can feel a little intrusive, but I think it all just depends on your level of comfort and the amount of transparency you want to have. And I think if you don't want to have that amount of openness, that's totally fine. I think if you still want to have that sort of connection and trust in the community, you could create a project specific calendar or email. So you still have some level of anonymity, but you're still opening yourself up for scheduling and being flexible with the community. So next comes the design stage. At this stage in the design process, your goal is to start designing solutions based off of the information you gathered from the discovery stage. This stage is all about idea generation. Feedback and iteration are essential and constant parts of this part of the design process. So if you were to source up by this step, you could use open source tools like GIMP, Blender, Inkscape, and other similar tools to create your designs. If you're more comfortable using proprietary tools to create your designs, that's totally cool too. Personally, I use proprietary tools like Sketch and Adobe products to create my designs, but I share my workout in open and accessible formats with the community. Next comes to sharing out your designs. I think it's the most important part is the sharing out part, even if you are using proprietary software. The sharing out part is the most important part of an open source design process rather than the tools that you use. Instead of just sharing like the kind of like maybe a final PDF or something of your design, you could also share out maybe the artifacts with the community. So it's even more accessible to the community if they want to like play around with your file or update it or modify it. I think that that sort of approach really embraces a full open source approach. Another way to open source by this design step is you could hold office hours with the community. I think there's interest in a more interactive way to engage with the design work and maybe ask questions or like do kind of on the fly designing. So after you've generated and sketched out some ideas, the next step is to get feedback on them. So to open source by the active giving and receiving feedback, you could share out your designs with the same community that you engaged with earlier on in the design process just starts start to get initial feedback. I think getting feedback from the community earlier on or getting feedback from the community earlier on in the design process really helps to build a better outcome and helps to build a relationship of trust between you and the community. So to keep track of some of the feedback that you receive, you could write it down in a document or spreadsheet for extra shareability. I think it's really important to follow up with the community on design updates you make. So everyone is informed and up to date on the latest changes that have been done to the design that you're working on. It's also important to remember to say thank you for the feedback that you receive, since people are giving you feedback they're taking time to look at the design work that you've done and contribute and help to make it better. Make sure you show your appreciation to the different community members or folks who are taking time to share feedback with you. This is just kind of this applies to any stage of the design process, but I think taking a more open approach to process of getting feedback is extremely helpful because it's an extremely collaborative point of the design process. And the design process is all about idea generation and pushing an idea forward. So I think the more perspectives and ideas that are presented, the better. When it comes to this step in the design process, it's all about rinsing and repeating so repeat the design and feedback cycle as much as necessary until you reach a final solution. Another important part of an open source design process is opening up the contribution process. It's not just about the design process itself. So, similar to setting up code contribution guidelines, setting up design contribution guidelines is a good practice to follow if you want to open up the design process to the larger community. The design process should be open and available to anyone regardless of their skill or experience level. You can it's always good to call out first time issues so newcomers have a smoother start to their contribution journey could be something as small as like maybe updating like a formatting thing or designing an icon if that person is more of a visual designer. I think any small bit that contributes to the process. It's a great way to get involved with the community. So here at red hat pattern fly is the open source design system that we use. It features a really great set of design contribution guidelines so if you're looking to learn more about how you contribute to a design. An online or an open source design process. I think it's really great starting point to learn more about an open contribution process. When it comes to the sort of design contributions you can make as a contributor to pattern fly. You can contribute new features and enhancement to an existing design pattern, or create design guidelines and also contribute documentation or content support or research. Any of that is included within that open design contribution process. This is a rough life cycle of a pattern fly design contribution kind of goes like this. So, first, an issue is created on and from the pattern fly GitHub, you can access that issue whether it's created by another community member, someone on like the core pattern fly team, and that issue might be for a new feature or a comment on an existing enhancement. So from that issue, you would create a design proposal that includes wireframes and mockups that explain the intent and the behavior of the design. And then once you've kind of maybe gone through a couple of rough feedback cycles, then you can submit your design to the pattern fly team and the community, and they will give you feedback and help you to finish up that design contribution so then it can be absorbed into the full pattern fly system. So, the next stage we'll cover, and this is kind of the last couple steps of the design process is prototyping and testing. At this stage in the design process, your goal is to start to prototype and test out a final solution. So, iteration and feedback are still major parts of the stage to open source if I, the step of prototyping and testing, you could create a HTML and CSS prototype and share out the prototype with the community. So they could kind of do some quick prototype testing. Personally, I use tools like Marvel or Envision to do prototyping, but I like to share those prototype links out with the community so that they can freely and openly access those prototypes and take them for a test drive. Similar to sharing out design work, I think sharing out the prototype is more important than the tools that you're actually using to build it. Similar to the design stage and the design process, during the prototyping stage, feedback is still a crucial part of going through this part of the design process and still something that you should take into consideration at this point in the design process. When it comes to testing out a prototype, I think it's important to get a variety of different users and try to get users who are not involved in the initial design process earlier on. To test out the prototype, so you try and get less bias feedback. So once you've kind of ran through a couple different tests of testing out the prototype, you should try to share out the results with the community that you got from that round of testing. I think it's also important to communicate any drastic design decisions that were made at this stage or openly express like what changes were made or just kind of give the community and the open just to increase the open is just kind of explain your your reasoning and give an explanation of why some decisions were made and why some designs happened or were refined in a way that they were. With any sort of design process you follow, there are some pros and cons. Some pros of an open source design process include, I think you can really involve way more folks in the design process when you're using open methodologies. You can pull from a wider set to come up or wider set of perspectives to come up with more innovative solutions. You can get users involved in the design process earlier on, and it also makes the design process more accessible. Some cons of an open source design process include the process can feel a little bit less straight straightforward and chaotic since it doesn't involve more people. At times it can kind of feel like there are too many cooks in the kitchen, and it can be kind of hard to maybe filter feedback since you, you're getting kind of inundated with feedback at times. And then the last con in my opinion is the lattice voice is not always the most right or informed voice. Since again, you are working with a really large party of people so you can obviously piece all of them but you have to try and come up with the best solution to the problem that you're solving for. So, in conclusion, these are just a couple points that I hope you all can remember and take away from this talk. When it comes to open source, it shouldn't just refer to code, it refers to design as well. I think it's really important to connect and collaborate with the community as soon as possible. Keeping communication and feedback loops open is an essential part of an open source design process. Also being transparent with your decision making. When it comes to the tools that you use, it's not really, that's not really a huge importance. I think sharing out the design work is the most important part. And then opening up the design process to community contributions since opening up the contribution process is a really big hallmark of an open source design process and open source development process. More perspectives are better than just one. When it comes to giving and receiving feedback, listen and take note and say thank you. And then iterate, iterate, iterate. Thank you. And we also included a couple of resources at the end of this slide. So, if anyone is interested in learning more about open source contribution guidelines, the pattern by link is there. I also linked to GIMP, Inkscape and Blender just as kind of open source design tools that people can use and learn and kind of get comfortable with. So let's stop sharing and open up the chat to see if anyone has any questions. There was an amazing talk Laura. Thank you so much. Audience, please feel free to pop your questions in the chat, since we have a good amount of time remaining, I guess before our next talk. Feel free to start a conversation while Laura is here. Yeah, it's looking kind of quite probably everybody has grasped pretty much of what you said then. If anybody in the audience wants to share, take this time to share any of their views around open sourcing their design process or any other topic related to UX design, please feel free to let me know. Yeah, everyone has like any best practices or suggestions for anyone else on the call. Feel free to share. And if not, I just put out a link to the breakout room. If you want to hang out there after this talk or catch Laura for any future questions, please feel free to do so. All right, I guess people have no questions. So thank you so much Laura and maybe we can hang out and take the conversation to the breakout room. It sounds good. Thank you everyone. Thank you.