 Hello, everyone. I'm Archita from India. I'm a design graduate, and I've been working with QED 42 for the last one and a half years. Today, in this 30-minute session, I'll be condensing all my learnings from the last various projects, though it is difficult to do it one year long and putting it down in, like, 25 minutes, but I'll try my best. Out of the various design services that we offer in QED, UI UX is one of the major one, and I get to interact with the clients and dev team a lot when I work on the UX projects with the company. So this is my first time here. I'm really excited. Let's start. So my journey towards designing for Drupal has been really exciting, but at the same time, it has been quite challenging for me as the industry was new. So back at the college, we have been trained to design with no boundaries. But when I came to the industry, I realized that, yes, there are boundaries, and there are limitations that you have to look at. So this is what I'm going to talk about here, and I have learned in these various projects how to mold creative solutions to effective solutions. Not that a digital strategy or a design strategy cannot be applied in Drupal or cannot be, is not possible in Drupal, but there are real-life constraints according to the budget and the time given on a specific project. Who do I interact with? Clients who are very particular, they have their priorities straight. Developers who are generally saying no to things, they are very concerned about technical feasibility all the time. So there are times when I have to bridge the gap between the two also at times. Let's see what the developers have to say about designers. The audio is not playing. Just give me a minute, I'm sorry. Can you check the audio, please? Yeah, he's a friend and developer. That's what he said. Okay, I'll check my desktop if the video I have works from there. It's not working here as well. Okay, moving further, maybe we can come back to listen to Morton later. So the major challenges that I have faced while working with different teams is that communication challenges. The first communication challenges come when you cannot interact with someone. It could be due to various reasons. Someone is not available or there are times when you work on multiple projects and it depends on how big your firm is and how accessible people are to you. The second one is optimizing value, the time and cost. So generally we try to deliver the most creative solution to people, to our clients. But we have to consider the time and the cost that they are setting up, that the client really needs. So we have to deliver exactly what is needed for the business and nothing less, nothing more. The third is the feasibility constraints. Now feasibility is not always about what can be done or cannot be done. It is about is it really needed for the business? So according to me, the solution is communication. It is as simple as communication, but when and at what stages of the project. Coming to the roadmap where the first section is discovery, where we empathize with the user and the client. We try to understand the user behavior and get all the grab all the things that the client wants from the project. Second, we define all the findings, all the unstructured findings that we found in the empathy stage. We define them to a concrete problem that we have to solve. And as you see, in the first step we are interacting with the user and the client. The second one is where we are interacting with the client as well as the dev team here. Because the earlier we let the dev team know the why behind the design decisions, the better judgment will they be able to make at later stages of the project. So it is very important for them to know about each design decision we make. Discovering the project, it is very important to understand the business and what it exactly wants to achieve right in the beginning of the project. So the questionnaire that we ask our clients have to be very direct and not abstract. We have to ask them direct questions that are exactly related to the design brand or the UX. So this is a link to the questionnaire that we use back at QED. You can download it from here. It has both UX and brand questions that you can ask your clients in the projects. This is an example of a project which had multiple pages to be designed. So I had interacted with the client already, but since this was one of the initial projects I was working on, I listed down all the pages that I had to design, but I did not set priority to what was important and what was really needed for the business. This is a profile page. This is just an example, which took me a day to design because I was trying to be very intricate with it. I did not know this was really not important for the launch of the website. And this took one day for me and probably two days for the dev team to get this up. And this in total got us three days down. This wasn't important for the phase one, but if you see that one page is costing us three days and a number of pages would cost us two weeks and two weeks of loss is a big thing. So business alignment comes with discovering the project that which is very important. So you need to know what is absolutely important to build first and what next, the priority basically. The need of understanding budget, which is very important. So when I design a project, a website, say a homepage, I go with what the brand wants or what the brand looks like, the philosophy, the characteristics of the brand. Here, this was a designer profile website that I was making. I put in all the parallax effects and animations, but I did not know that the client did not have that much of a budget to launch the website. I definitely spent more than a week on this, but this wasn't executed. So this was a waste of my time. The second phase is prototyping and testing. Wireframing, right. So even the developers need to come in here as when I'm wireframing, maybe I'm just paper prototyping and everything is just in a rough stage. But I still have my feature set ready and tangible enough to show to the dev team. So the feature set shown to the dev team can bring in some suggestions or critique from their end. That the structure of the app, wireframing, prototyping and usability testing needs high involvement from the dev team as well. This is another example of a project. This was, it is for a medical institution. As you see the cross-marked in here, when I designed the two pages, I thought it was obvious for the dev team to understand that the transition is going to be horizontal. It's going to be a horizontal scroll. But, and it was very later in the project delivered to them that it had to be a horizontal scroll and not a vertical scroll, which costed us a lot more extra time than it would have if I told them right in the beginning, the animations right in the prototyping stage of the roadmap that I explained. Right, so yeah, it was random. And this is another project where you see the green, the tags there and the option one that I made, could, if I X out the tag, it gets deleted from there. And the second option, 2.1, is the one I can click on edit on the right and then this 2.2 pops up and I can either edit it or delete it. So option one and two are two different ways of doing it, UI, user interface options, but, and it doesn't, both are quite similar in the user experience as well. But these two options did save a lot of dev time required to build it, build this. And that's why UI considerations are important because at places where the UX is not getting affected by the UI, it is important to pick up that UI option which does not let, you know, make my dev team work more than what is required, what is actually required for the project. This is another example where I didn't back up. So here, this was the first option of the design that I made. You see the red button which shows real-time property count. And this is a filter page. So it's a search flow where I select this filters and the red button shows me real-time count of the properties. This was definitely going to take a lot of time for my dev team to get this going. We had a discussion and the client wanted this. This was definitely a better usability for the user. So we went ahead with this option. Because we did not, why don't we change the UI here? Because sometimes we have to go with what the client wants or what is actually a better UX. Now if we removed this real-time button, a property count showing button, it would change the UX a lot. It would get it down by a lot of points. So we went ahead and spent more time on dev here and executed this. The last stage is production. When the designs are going into production, it is still important for us to be involved with the front-end developers here because we can't leave it on them. In the user interface design, when the visual design that are actually coming to life, it is important for us to be there and deliver the style guides and the font types and images perfectly. The font types, right? So it is, I have learned in the last few projects that I've worked on that using multiple fonts on a webpage is not a good thing. So this again contrasts to my learnings from my college, from my university, where we used to use the fanciest of the fonts and the numerous fonts and different font weights and sizes to use typography. But again, as Morton, we couldn't watch Morton's video, but he said that we have to understand, it's not a movie, it's not flash, web is web. So that has to be considered here. Using minimum font types will improve performance of the website, which is the functionality improves the better the webpage is. Yes. So have you plugged in your audio or Sagas? Right here is your audio. Okay, thank you. Okay, I can also play it at the end. We can just write. So these are the materials which we need to deliver to the dev team right on time for them to be able to execute this perfectly and bring our designs to life. So the roadmap I just explained will definitely not be successful without a kickoff meeting. And the kickoff meeting should not just be a 30 minutes block of reviewing documentation or timelines, it should be very collaborative. We can have interactive exercises or get everyone thinking, the entire team, the design, the dev sides, everyone thinking on the same lines about technical feasibility and design priorities. So the designer developer collaboration has gone quite ahead. You should definitely check out patternlab.io where you see designs coming to patterns and I'm going to talk about component-specific design here. These are examples from different websites. The ones in the red are blocks, similar components, which have been reused, even this one. And these three are three different kinds of website. The first one on the left is a linear website. As you see, the one in the center is a content-heavy website, very informational. The one on the right is a design-intensive website. But all have similar components and this is what I want to talk about. I believe that if you have an in-house team of designers and developers, you can come up with a set of components that can be reused in various projects in the future. So it's like a one-time investment or strategizing where you build a set of components and you can work on them and use them later, reuse them in the later projects. These are quick benefits of atomic design. I point out the fifth one. So because of the atomic design, like we built the components earlier and we can reuse them, so the grid is defined. You do not have to pay much attention to the pixel-perfect execution of it. So cutting down time on the UI, we can invest that time more on the UX. So as a designer, if my time is, if I do not have to reinvest the time on the UI, I can use that time and look at the UX required for a variety of projects that I'm working in the future. This is the session you can attend after this. He will be talking about Drupal Component Design. It's today in straws five to eight, five to six. I'm summarizing here now. This is the conclusion slide for my session today. It is my take on a project plan. It could be subjective, it could be worked upon later. It could be refined in the future. But as of now, I want to put this down here. This is the roadmap from the left to the right. The dotted red lines that you see is the involvement of the dev team that I feel should be there on every project. And after every stage, I've put it down. The longer the line, the more involvement of the developers needed. So that is how I've represented it. As the fidelity of the design increases from the left to the right, you see the involvement of the developers and their feedback coming in on the project also increases. I believe this is the way it should be taken forward. Yes. You can tell me what you felt about the session. There's a link for this survey. And any questions? Oh, I'll play the video. My name is Morton DK. I've been working at Drupal for many, many years. As part of front-end development, also as a designer, but so my primary experience about working with the designers has actually been the hardest part of them to understand what we're trying to achieve by building a website. And that can be a hard thing to get if you're not used to or not as involved into digital media as you are, as you work as a female, or understand HTML and CSS. So my biggest concern, I would say, by working with the designers is their lack of understanding what HTML and CSS can do. And having ideas that it's a movie, or it's a flash thing, or it's a newspaper, is like they cannot forget that the web is the web. And that's like the biggest issue. The best thing about working with the designers is that they're creative people and they can help you push so much more of what we're gonna do. The worst thing is if they don't understand the MVP perspective of the project, but they can help you push the boundaries, make stuff prettier, make it easier to self-organize, and it can also go the other way. So I would hope the designers got better to learn the media, really to learn how to, what you can create just by building a website and not doing like a movie, or a flash thingy, or whatever. I really like working with designers. I come from a designery background myself. I focus on front end, so I have a really good time sitting down with designers and figuring out the best way to do all the triple A things that we can do. I really like it, and I think there should be more collaboration between designers and developers in the community. So as a young designer, what has been your more, your painful, your more painful part? So what has been the hard part for you? Redesigning, redoing my work all the time. So I think, but that has helped me learn, and that has been exciting. That is exactly what has been fascinating about redoing work and learning myself, working with developers who are actually, from a different world altogether. Thank you.