How to work with engineers: a designer’s perspective
Designers visualize how we want things to be. We attack the problems from a different — often opposing — perspective than engineers do. We see the end product, and then build a process behind it.
These visions are based on user research, data, intuition, and design prowess. They don’t come out of thin air.
Many engineers I’ve worked with have an iterative process. Knowing what the final goal is, they break the problem into little bits and build each of them one by one. Where designers go top–down, engineers go bottom–up.
The engineering decisions are based on technical restrictions, difficulty, and programming knowledge.
Know how programming works
There’s a recurring question and discussion in the product design world: “Should designers learn to code?” I want to say “not necessarily,” but knowing how to write code has shaped my design career.
From a young age, I was fascinated with computers. I started designing and building my own web pages for fun. Back then I did everything on my own. I even remember reading a Dreamweaver MX tutorial book.
In doing so, I learned about problems that arise when implementing designs. I knew that the more images there were, the longer it would take to load a page. Custom fonts were not an option back then, and if I wanted to use gradients and effects on buttons, that would require more images.
I realized it was better to recycle images, create patterns and button images that could be manipulated and turned into several. I was saving myself time on implementation by considering those issues in the design phase. As my engineer friend Keenan said: “Reusable sets of patterns in both design and code create a highly effective ecosystem in which to build user interfaces.”
He mentioned that often times, engineers spend their time thinking about the reusable functionality, and not much time thinking about the reusable parts of the interface. A good designer will point out the user interface patterns to the engineering team. That way, they can build reusable components that will facilitate the engineer’s work, and allow for a faster iterative design process.
If you manage a well structured set of styles, changing a parameter in the whole set will become a simple process. One change in the right place, and the whole set is updated — much faster than revisiting every single style one by one — keeping consistency and adding velocity to the process.
I don’t have to write HTML and CSS anymore, but having experience in the field, I’m more aware of how the limitations and nuances of the programming languages factor into the end design. From time to time, it’s fun to play with them (last year I built a prototype writing my own HTML and CSS) but it’s not necessary anymore.
As a designer I have to be aware of the limitations that code has, and the best way to do so is learning how code works, or how to code.
It’s similar to editorial designers not needing to know how to run a huge press. But it’s imperative they know about the grammage of paper, or the number of ink colors available as they design a publication.
Be aware of the technical constraints that affect your design
I remember the first time an engineer told me, “I love working with your designs because they’re so easy to build!”. I didn’t see it coming at all. I was just doing my job the way I used to do it for myself, saving time on implementation, mainly because I was saving myself some time. But now it was clear I was also saving someone else time.
Even more, by being aware of how the code worked, I was able to come up with designs and solutions that no other designer in the studio could. This allowed me to collaborate with the engineers in building new ideas and to be more creative, by using all the potential and hacks that code allowed. The resulting designs were more dynamic and interactive than what other people could build.
Recently I got that type of feedback again from more engineers that are happy with my way of working. This time it goes beyond thinking like an engineer — it’s also about flexibility.
When someone comes to me with technical constraints that challenge the design, I rarely push them to work around those limitations. I ask myself if there are any other valid design solutions. Often times there’s more than one answer to a question. If I can come up with something that saves engineering time, we can implement it faster, and spend more time in polishing the most important aspects of the design. Surprisingly, many times a constraint has led me to find a new design approach more effective and simple than what I had at first. Constraints spark creativity.
It’s not often that a design can’t be implemented. I am very lucky to work with a team of amazing skilled engineers. That being said, sometimes there’s no alternative, or way around a technical limitation, and we have to face it. When that’s the case, I explain with detail why the proposed design is the only way to go. And since I concede often to technical constrains, the team know that this specific part of the design is important.
By picking our battles, and having flexible designs, we can focus our efforts on the really crucial parts of the user interface.
Bring your engineers on board as soon as possible
The sooner you can get input from your engineering team, the better. “Can we do this?” should be your most used sentence at the beginning of each project. A product manager I collaborated with a lot used to create tasks in Asana with the designs I was iterating on, almost daily.
The engineers would often comment on the design and give me feedback, and share their excitement. The value of this technique was double.
By taking the whole team into account we made them participants of the design process. They could warn about the technical issues we could be running into. And at the same time they started thinking of possible workarounds for those issues. Once the design was finalized, they either had a solution to the technical limitation, or we had fixed it through design.
Plus, we got them rallied up around the new designs. Putting them in the right mindset and yes… creating hype. Same way you get excited when you see a trailer for a movie you’re dying to see.
Having engineers as part of the design process helps anticipate problems and be aware of what can be overcome technically and what needs extra design thinking.
Accept and deliver good feedback
After all this time I’ve also come to notice that most engineers appreciate mathematical precision. Their strengths don’t necessarily lie on the visual side. Or they are not confident enough to make those calls. Some of them will give their opinion on designs they consider confusing or unattractive, but they don’t want to make the call. Which makes total sense, I don’t make calls on fields in which I am not proficient.
But… I really admire when an engineer approaches me with a design they have feedback about. I listen to what they have to say, and try to understand their perspective. Sometimes they are not aware that some other designer or engineer is working on that component at the moment. Or there is a higher constraint. Or we might be deprecating some aspects of the design.
Whenever that happens, I explain what the issue is, always with a smile and happy to help them understand what’s going on.
But sometimes their feedback is spot-in. Sometimes it turns out that once we implement a design all over the interface, edge cases surface. In those cases I try to find out what the causes are and what our options are. After finding a solution, I send the feedback to solve the problem, thanking them for spotting the issue and improving the design.
Whenever I give feedback to an engineer I try to be very specific and encouraging. “Nice job! If you can add 10px margin between this and that it will be perfect” for example. That gives the engineers really concrete action items, making a change fast and highly targeted.
Feedback goes both ways. I always keep in mind that we are a team and we have the same goal: build great product. If I dismiss my colleagues’ feedback, they will dismiss mine. And even worse, I will learn nothing from them.
To put this advice into bullets:
- Know the medium and its constraints.
- Choose your battles. Not every aspect of the design is equally important.
- Make engineers participants from the very beginning of the project.
- Be really specific with your feedback. And be open to receive their feedback.
This advice is aimed for lean product design in the modern startup world, where the goal is to ship new features and experiments frequently, and to iterate quickly on them. And yet this can be applied to other design and product processes. We always have to make concessions, but by having mutual understanding between designers and engineers, we can achieve faster and better results.
If you found this article interesting, click the❤️ so more people can find it. For more content on User Experience, User Interface, and Product Design follow me on Twitter.
