Designers and developers: solving friction to build better products

Vinta brought me into the team with the goal of combining design and development for our clients' digital products. I already talked a bit about the experience of bringing new steps into the development workflow, which is an ever-changing process and is teaching me a lot.

This post is more about the things I've been learning while working alongside developers on a daily basis. One very particular aspect of my experience is that, instead of being allocated full-time in a product team, I work on demand in various projects. That may be chaotic sometimes, but it's great for cross-pollinating knowledge between teams with different problems.

I hope these takeaways are useful for designers who just started a job in the digital market, people who are changing career paths and learning to navigate new waters, and peers who might be having a hard time communicating with devs. I was once like that, I used to think they were the enemy. Well, they're not. Repeat with me, developers are not the enemy.

Why is it so hard to get along?

I've read too many think pieces that pitted designers and devs against each other. Some paint the designer as the user-centered empathetic visionary who wants to build a better world, and the developer as the killjoy who deems every UX improvement as extra work, too complicated to be worth the effort.

Others say that designers have their head on the moon and propose ludicrous changes to a product that is working fine, just for the sake of style and portfolio-vanity, while devs are the ones concerned about shipping the product so real people can actually use it and give valuable feedback. I've seen all of these stereotypes come to life, and a while ago I also hated handing-off my beautiful – and completely impractical – UIs for programmers to turn them into some frankenstein that was nothing like I had envisioned, aesthetically or functionally. Back then, design often felt like a beauty filter that you applied to the product after it was done, and we weren't even close to discover the wonders of a design sprint.

Specs were a nightmare to create, and many details were lost in translation. We've come a long way. But even today, with all the guidelines, processes and tools we have, it's still hard for many hybrid teams to work well together.  Maybe the root of the problem has something to do with the different ways designers and developers understand the world, and therefore the products we build. We have a more holistic view of the system. We think about the user experience as one big thing. Every aspect of that experience has to be smooth and functional and well-connected to the others. Because of that, we tend to hold our products to impossibly high standards of perfection.

Developers, on the other hand, see that big thing and immediately break it down into smaller parts in order to understand it. They go at it pragmatically, prioritizing issues and solving one problem at a time. They might even leave some parts of it broken, undone or inconsistent along the way, if it didn't feel like part of the core functionality that  had to be delivered.

The thing is, we should be able to work amazingly together because of these world-view differences, not despite them. But how do we bridge that gap? Product designers need to understand the way agile development works: delivering pieces of software one at a time, iterating fast and improving on top of that. Not everything will be perfect, and features have to be shipped to the real world even if there's still some work to do (which is always the case). Developers need to step back and look at the product as a whole. If part of it works but other parts are broken, if components or behaviors are inconsistent across the interface, the users will suffer, and eventually choose another product that feels better.

So, we all need to understand where the other is coming from, and use our different ways of thinking about software to make it better. Easier said than done, right? Well, I'm about to explain how I'm learning to communicate better and be smart about the things I care about -- delivering a good experience, UI consistency and correct font spacing. So without further ado, here it is.

1. Communication is key

During a sprint for a new feature that involves UI or UX design, I spend about a third of my time discussing things with developers. The project manager is always present in the earlier feature discussions with the client, so she understands the motivations and business needs behind it. The team and I go through user flows together, discussing  the best way to integrate something into the existing system. I ask them for feedback whenever I'm working on a new flow, component or page layout, always trying to propose the design with the best effort/impact ratio.

There are also informal weekly syncs with the tech lead on each project, where we prioritize design issues, striking a balance between client needs, sprint planning and real UX improvements to be shipped.  Having a good relationship with the team is crucial for things to go smoothly. Like Dave Feldman said:

"If every pixel has to be perfect in order to achieve the right in-product result, focus on your relationship with developers rather than your deliverable".

2. Don't be a design snob

Share your design knowledge with your team whenever you can. Explain the reasons behind your choices. It's fascinating to see people finally understanding, for example, why every online magazine layout has roughly the same line-width, and why that's so comfortable on our eyes. I care a lot about typography, and I want my team (especially the front-end devs) to care as well. When I'm reviewing a page and realize that the lines of text are longer than I specified, I don't just point it out. I talk about reading comfort, search in the back of my mind for some solid graphic design principles that didn't get old, and do my best to show the reasons why it's important that the block of text has the right width and line-height.

Programmers love to understand things. Understanding design principles makes them excited about what we do, curious for more and willing to help us make a better product.  We recently took this to the next level with a full-day UX workshop for Vinta product teams. It was fascinating to see developers doing interviews, designing user journeys and getting feedback on their paper prototypes. They learned a bit about how designers work, and I as well, in the process of tailoring the activities for people with different backgrounds. It was a great moment of knowledge-sharing between teams.

3. Be curious about development

Obviously, it goes both ways. Developers love when designers want to learn more about their way of doing things, in the same way we feel great when they take an interest on design.

One of my coolest experiences at Vinta was attending a Python conference, seeing talks presented by my colleagues and participating on a Django Girls workshop, in which we built the back-end structure of a blog with Python and Django. I'm not switching careers anytime soon, but having a deeper understanding about the powers and the limitations of the tools and languages used to implement my designs helps me think about what I propose in terms of effort vs impact.

Frank Chimero builds a great analogy between designing with code and working with wood:

"All materials, whether wood or pixels, have a grain, and that grain suggests the best way to work. Go with the grain and one will find sturdiness combined with tremendous flexibility — a natural and exciting give that grounds decisions and excites with possibilities. Work against the grain and the work becomes precarious, difficult and fragile. Instead of the elegant bending that software requires to adjust to different screens, uses, and situations, the work breaks because it cannot adapt."

So, understand your medium as best as you can. Having a good relationship with developers helps a lot with that too.

4. Safeguard your time

I thought this issue was very particular to my experience, not being allocated full-time on one project. But talking to fellow designers, I discovered that time management is one of the hardest things to master in an agile workflow, across the board. We go through many different work modes during a feature design cycle.

At first, we wear the researcher's hat, understanding requirements, unearthing the motivation behind that new screen that the PO asked, talking to users, discussing technical limitations with programmers. Then, we might go into brainstorm mode, bouncing ideas around with our teammates. But at some point, we need to hide in a cave for a while and do the dirty work of creating UIs and prototypes that translate all that into actual products.

In my opinion, that time needs to be focused, calm, without interruptions. And that's when things get complicated, because, as I said before, a lot of a designers' work is communicating with the team.  Developers have questions. They need to know exactly how a feature will work. And they will break up your hyper-focused time to ask about the behaviour of a menu or request some SVG icon that went missing on the specs. And they're not wrong, they're just doing their job. The deploy will be blocked if they don't clarify that doubt right now, and the designer is the one who has the answers.  

One way of minimizing these kinds of interruptions is through great design specs, that show and tell exactly what should be the behaviour of a feature. Some aspects of the UI might seem super obvious while we're preparing the handoff, but there is no such thing as too much explanation. And depending on how the team is organized and how large it is, sometimes the specs for one flow get broken down into smaller tasks that are assigned to several developers, and you can imagine the mess if each of them understands that little piece of work differently.

A consistent style guide also helps a lot to make the dev's work easier and more independent from the designer.  Asynchronous communication is another great way to safeguard our focused time. I hide Slack (and its anxiety-inducing notifications red dot) when I really need to get something done, and respond everyone when I'm back from my "cave". Working like that has done wonders for my concentration. It requires a bit of self-control to slack someone instead of talking to them out loud when you're working literally 3 feet from each other, but over time we've fine-tuned the process and it's actually easier to track the little issues we discuss inside a chat window than it is to trust that our brains will remember everything.

5. Ask for feedback from developers, and really listen

Do it at every step of the way. When you're defining behavior, when you see the need to build a new component, when you're presenting research to the client, when you're handing off the specs. Bring your team along in the design process. If the developer actually helped you figure out the best solution to something, she will help you out when you're defending that decision with the client. She might even go for the most complex implementation if you both understand that it will lead to a better result.  Also, listen to your team if they have an opinion about your workflow, your review process, the way you organize your specs for them.

Respect the knowledge that was there before you. In Vinta, I joined teams that existed long before I came around, with their own processes and ways of doing things. We had to change some habits and come up with new processes, but I learned a lot by just asking “how do you think we should do this?”, and building that “how” with them.

In the end, we all want to design and develop products we’re proud of. And the best way of doing it is together, as a team. Huge thanks to Lais Varejão and Juliana Carvalho for reviewing this blog post so thoughtfully.

‍