Better Engineering Collaboration

I feel confident in making assumptions based on my experience in companies and start-ups as a digital product designer, where I have either followed or helped create processes. 

The general case is that one defines a PRD, or objective of the problem to be solved and then validates/verifies/idealises/tests the design of the solution based on the goal. 

It usually involves several rounds of feedback, reviews, or critiques in the form of comments, meetings, or presentations. 

When all this is advanced, and the approved decisions are hopefully the right mix of data-driven and product intuition, in an agile cyclic environment, designs are ready to be built in code. 

Now it's time for your engineering partners to start building it. 

—

On collaboration

However, where were the engineers before? They were with you from the beginning, hopefully. Moreover, if not responsible, they were at least accountable for your actions. 

You've been working closely with them throughout the entire process; if not, you should cut the time to do that. 

The main reasons for all the great benefits that come along for me are two: 

1. They already have the context of where the final design comes from and what the choices were 

2. They can give you the most valuable feedback on technical constraints if you have a different solution or feature that requires components outside of a most-likely design system used.

—

On the actual handoff

I use this term because it gives the idea in English, but it is much more of a hot potato process, as my colleague Dan would say.

The conversation turns to the technical side: it usually involves specifications around sizes, typography choices and any other design decisions so that engineers know first what to code and second, they do not have to guess. 

This stage was of great interest, and I noticed utterly different experiences.

Regardless of the quality of your craft, just as you do reviews and presentations, you want the actual implementation to reflect what you think is essential, which is where you know you have spent the most.

I have seen and contributed to superpixel detailed specs in Figma, down to simple comments and off-screen notes, as much as Loom videos using similar cases to adopt.

The prototype you want to build starts from the path you want to start marking. Soon, together, now.

—

Where there are silos, there are problems. 

Design and engineering resources could have unnecessarily wasted every time a new style guide, and you must create a component kit. 

Furthermore, the edge cases for each component will need to be reconsidered every time a new one-off variant is created, and will often be forgotten, leading to diminished product quality or prolonged-release timelines due to unforeseen design dependencies after the engineer handoff. 

The problem is that one does not have a cyclic building experience. 

As my friend and mentor, Bob Baxley wrote, 

Shipping is a consequence of creating something worthy and not a goal in and of itself.

Not having to constantly re-implement each essential component for each module and reconsider every edge case can easily cut down engineering implementation time by at least 50%.

—

What is next

This image 👇🏻 is the recognition my front-end eng. proudly deserves.

There is so much gratification in working well with people who have an eye for detail and a willingness to follow a collaborative process.

None of this is (just) luck, and I have been through many where it was really difficult, or sometimes even non-existent, to manage the implementation transition. 

Try to interact with the person writing the front-end, especially post-pandemic and In Real Life. 

Make yourself care about creating value and impact with an A+ result, and don't mark the to-do as done in your tasks. 

Everything else will take care of itself. 

Have fun

—

Writings