In the world of Digital Products, there are 3 questions that are always valid: 1. What is UX, 2. How do we best integrate work teams? and, 3. No, seriously, what is UX?.
For the first and third questions, there are many approaches, but for the second, the universal answer is always: closing the gap. That is, to approximate the roles in such a way that the crossing between areas does not feel like jumping between islands, but rather as a continuous route.
My gap-filler between design and development has always been to advise the design team to understand the programming logic. But, of course, being on the other side this time, in a development blog, I can't repeat that advice; and even if I wanted to, I can't ask them to follow the design logic either...
1. Ask for explanations of the decisions that are made
On the big road of launching new features in a digital product, those who program are usually towards the end of the process. Before the ball is centered on them, stakeholders and product leaders have already made their foosball moves, including passes to the goalie.
This makes that generally the work received is not questioned, assuming that "everything has already been thought about in previous meetings". However, in these meetings, there are always scenarios, extreme cases or important concepts that have not been considered and for which it is good to raise your hand and ask for clarity.
It is not a question of confrontation, but of alignment. If a decision doesn't make sense to you or doesn't make sense at all, raise your hand and ask for what is causing a stir in you. In the best-case scenario, you get a satisfactory explanation, which will help you do a better job. But if not, at least you will have generated a reasonable amount of doubt, which, once resolved, will allow you to have a more solid product. For all cases, the result is positive.
One of the best projects that I participated in, started with a developer showing me a library that he had researched. "It's very cool and I'd love to use it," he said. I took a look at it and it was indeed very cool, so we took it.
The result was a project with very fast delivery. Not only because this developer was able to start implementing this library from the beginning, but also because he was motivated to use something he knew and that generated interest. In addition, I also had a great starting point: I didn't have to create the interaction from scratch but could use the components of this library as a base.
3. Make your work visible
I mean it in the most literal way: show the render of your code to the person designing it, so they can see how what they built is looking like. I don't know how to explain it, but we designers are excited to see our designs become "real" (printed, published, interactive...).
Not only are you giving that gift to the designer, but you are also generating the opportunity to do Visual QA, receive feedback, or even give it when you see that an element is not working well, or building it could take too long.
You don't need to have a review app or display a test URL, you actually get more or less the same effect by sending screenshots, gifs, or calling the person to come to your screen and see what you built.
We all want to create incredible products, that make us feel that we are changing the world while looking good in our portfolio. But the only way to do that is by getting involved with the development of those products, and being willing to give and receive a lot of feedback.
The conclusion is a cliché, but the kind that works: talk to your team, don't be afraid to say what you think, and open up your work so that others also have a say in what you do.
*******
Nicolás Lozada is a Product Designer at Get on Board. He teaches a UI course in Medu and loves talking about design (and he occasionally drops a few good memes) on Medium and Instagram.
Latest on Blog
