How to Train Your Designer?

Hello, this is how to train your designer. I am Dora Moxie, and I'm a UX designer. I started my career in a car navigation software company as a UI developer.

We developed and designed different size PDA resolution software solutions, which meant a lot of components. So without even noticing it, I was creating my very first design system way before it was cool. I was also dealing with design operations, which is somewhat similar to what developers have with DevOps. I also tried out myself as a manager, but now I'm back at design. And I realized that this sort of knowledge mix might interest people.

So I started to teach people, started to educate and share articles and speak about this sort of collaboration between developers and designers. Currently, I'm happily employed at Element Logic, which is a warehouse automation software development company. So let us see what we'll speak about today. We will have some sort of initiation. We'll look inside the designer's head. We will check out what is happening with the manager. I will highlight how the designers perceive the developers. We will find out how to build bridges if it's needed. And there will be some key takeaways. Why would anyone want to train a designer? Let us assume that we are selfish.

So people want to train their designer for themselves. Because if a designer understands what and how to deliver, then the whole delivery, the whole development will be smooth. When it comes to evolution in nature, species tries to adapt to every single change. Because if they adapt, they won't be extinct. If they don't adapt, well, I have bad news for them. What happens in an engineering led company? If engineers want to involve a designer, it will come with changes, and the organization have to adapt. At first, it will be slowing down everything, because everybody, every single participant will try to adapt to the changes. And then this way, they won't be able to focus on their daily routines. But this is an investment. Because during the second stage, which is integration, this will be already a longer process. There will be improving results. Everybody will try to find their new places.

They will adapt to changes. And they will be able to stabilize the whole system, their routines. And finally, the delivery phase will come with very well-oiled routines, so that the team will have time to innovate.

What is happening in the designer's mind? Meet the designer. The dragon is the designer. Dragons, I don't know if you knew, but specifically in the How to Train Your Dragon movie, they have very, very distinct point of view. They are curious, just as designers, and they listen a lot, just as designers, and they thought a lot, just as designers. When we listen, we try to process what we hear, and we try to already connect the dots, and we find new ways to solve different problems. Therefore, for that, we need data. We love data. Once we analyze data, we are able to prioritize the problems, and to be able to point out the feasibility perspective, we like to discuss this with engineers. We love to involve engineers, QA engineers, because we have to test out every single solution that we work through.

There is a use case that I wanted to share with you. A few years back, I was new to a company, and there was no such culture of communication between designers and developers. Once I felt I'm ready with my design files, I reached out to the Head of Development and asked him to comment on my design file regarding feasibility. This came with the huge benefit that once we arrived to the phase of handing over the design documentation, the whole front-end team was already aware of what to deliver and how, and they could reach out to me whenever they had a question. Successful design consists of a structured approach. The easier the understanding, the faster the delivery. If you, as a designer, document your work properly, transparently, and clearly, the developers will have less and less questions, because they can find their ways in the Figma file, and they will be confident to deliver everything. The other important part here is how to be effective. If you communicate with each other smoothly, then the project will be a success. If there are a lot of misunderstandings that are not cleared up, the project will be a mess. Simple as that. For example, another example from an actual developer. He was working with a designer, and the designer handed over the Figma file. And the developers, let alone my friend, they didn't ask back anything. And this should have been suspicious to the designer. If a developer doesn't have a question, it means that they not listen. So, designers, be suspicious when you don't have any questions from the developers.

Right. What is the design process? First, the designers empathize with the customer, the problem, the business requirement, with everything. They want to understand everything. This is the phase of data analysis. Second, based on their learnings, they will define the priorities, and they will draft workflows, user flows, sympathy maps, everything that will help to understand and analyze the priorities together with the product stakeholders. The third phase is when the designer creates low-fidelity wireframes and prototypes. This is the stage of failing fast. Whatever the designer delivers, it must be tested out. And this is the point when the developers can point out feasibility issues. It is also advised to involve support people, marketing people, and QA engineers to this phase, because they will bring their different perspectives. And the sooner the designer has all the different perspectives, the better.

Prototype. Designers create high-fidelity mockups and prototypes, so it will look like the real thing, and this is the point when they can actually figure out the potential dead ends that won't work at all. And everything they create, they must test in all senses. Right. In the movie, How to Train Your Dragon, Hiccup figures that Toothless couldn't fly because he missed a fin. So, he understood the problem and he started his own research. How can he help to the dragon? He created low-fidelity wireframes, and then he tried on the low-fidelity solutions to Toothless's tail. Once he was done with the low-fidelity prototype, he created the high-fidelity mockups and they tried out the real prototype. Once it was ready, there was a documentation and handover, and Toothless was finally able to fly.

What is happening in the manager's head? This is the manager. Managers deal with the three T. Tools, team, tech. If anything is problematic from these three, then the team has a problem. The manager's responsibility is to figure out what the problem is, but it is not the manager's responsibility to solve the problem. The problem solved is between the problematic parties. And we always have to raise the question, what can we learn from this? Because if we approach a problem with a what can we learn from this attitude, then we are already evolving and adapting to the changes. My previous manager, Jonathan Gahl, said, listen to folks, shut your mouth, don't try to solve the problem. People have to talk it through. Simple as that.

While I was delivering different design files, aiming for 100% developer experience, one of my favorite ex-colleagues told me, David Kroll, told me that I shouldn't try to solve all the problems for the developers. Developers cannot improve as a professional if I provide everything to them. He basically encouraged me to challenge the developers to find their own ways. Designers shouldn't adopt engineers' biases. Early feasibility concerns from engineers can negatively impact the solution. Which means that, yes, it's important to gain feedback from developers regarding feasibility, but it's not necessarily a task to solve every feasibility issue. Because if developers can solve that issue, they are already improved as professionals.

And now, finally, the designer's perspective, how we perceive you as engineers. We must establish the grounds for the design critiques. We must involve the developers to our world so that they can have the opportunity to give feedback. Developers should involve us vice versa when it comes to the design review. Once you started to develop the product, the feature, you should involve the designers to have design reviews. Because if a designer can point out a potential problem or a bug or something is not fitting to the initial figma file, then you already saved a lot of time and debate with the QA engineer. So involve each other to testing sessions.

At ElementLogic, we utilize the so-called product trio. The product management is responsible for the value and viability. The engineering is responsible for the feasibility. UX and design is responsible for the usability. And together, these three as equal partners, they bring the business value. It's very important that design is not under engineering or under product management. We are all equal. In the movie, Hiccup and Toothless identify the points of collaboration. And this is exactly what the developers and the designers must do.

The engineering is responsible for the feasibility. UX and design is responsible for the usability. And together, these three as equal partners, they bring the business value. It's very important that design is not under engineering or under product management. We are all equal.

In the movie, Hiccup and Toothless identify the points of collaboration. And this is exactly what the developers and the designers must do. Once they did it, they can work together. They can give opportunities to contribution. And they can have joint effort with so much patience, especially in the beginning. Once you know your designer in your team, it's already easier. But once you think that, oh, this designer will want to tell me what to do and how. It's a bit different. And you will feel the difference. If you cannot participate in the design work, at least do not block it. Because the design process actually works. It will deliver a lot of value to the organization and the team. But if you cannot bring any value, at least just don't block it, please. The benefits will come.

Iterative design comes with the benefit of learning together, growing together, understanding each other better. You will become equal partners with the designer, which is so cool when it comes to development. What are the key takeaways? In summary, diversity leads to stronger solutions. Participation in the design process pays off. You will get to know new aspects. And you will grow professionally, because you will be challenged. You will be facing so many new solutions that you haven't heard of, that you will have the chance to actually try out, experiment even. And you will become a better professional. But this can happen only if bottoms-up and top-down support is there. Challenge biases and respect disciplines. Believe me, designers want to understand you, but they learned a lot.

They are smart people, as well as you are. So, if you have any biases, just try to focus on different perspectives and understand why the designer suggests something in a different way. Share the knowledge and involve others. Be kind. Find your new partner in crime.

But wait, we missed something. This is the user. We have to ask the user. We have to involve the user. And we have to understand what is happening with the user. If we understand their pain points, we will solve the real problems. And once we involve the user, they will get more engaged. And they will be more satisfied, which will end up in much higher income to the company, which means a stable salary for you.

In the movie, Hiccup says there is nothing a dragon won't do for you when you've earned its loyalty. To be honest, it's completely true for the designer as well. So, I suggest you do train your designer. It will pay off. Thank you very much. You can find me on LinkedIn. Reach out to me. Let's have a nice discussion. And if you have any question or feedback, just don't hesitate. Contact me. See you!