UX Engineers: the missing link? (spoiler: not really)

My takeaways from the experiences of Google Material Design Engineering Manager Sol Chea and designers from Cabify, Liferay, Idealista and more.

Early this year, I met Sol at Google for Startups’ Campus in Madrid. When someone with a certain expertise on your field of work visits the Campus, it’s mandatory to stalk them until you get to share some of their wisdom.

So that’s what I did when I found out that an Engineering Manager from the Material Design team at Google was coming to Spain: we talked for almost two hours about startups, UX, and collaboration between design and tech, and that lead us to this rather rare profile that his team has: the UX Engineer.

As Sol told me, those profiles are key to coordinate the efforts when designing digital products, and not only in early stages: because they truly understand both sides of the equation, they are fundamental when scaling your team or organization.

And he knows about that: the Material Design team alone is around 200 people.

Someone with a design background and technical skills is capable of discussing effectively [design] ideas with developers.
This person is not a genius that lives in an ivory tower ideating new stuff and then presenting it to “the builders”. This person participates in the whole process because we’re in 2019 and waterfall should be fucking dead already.

Sol’s team is constantly looking for new ways to help other teams to overcome design and organization challenges with new tools (see the Material Theme Editor), so after our talk, he wanted to know more about how we work, “we” meaning: other designers from the Madrid scene who face these kind of problems on a day-to-day basis.

I told Sol about Collisions, an interdisciplinar community that I joined some months ago to meet different people and foster this kind of conversation, and we planned a small meetup with our friend Ismael González, who offered to host it at the upper floor of Cabify’s office.

In two days, we already had a list of awesome attendants: Zhenia from Idealista, Victor Valle from Liferay, Irene and Cristina from Clarity, Andrés Noceda from Designit (now Cabify), Alba Arias from Spotahome, Jesús from Lola Market, Daniel from Secuoyas and Alejandro.

We discussed the many pros & cons of design systems, the need for controlled inconsistency across the whole production process (for testing, for example) and agreed on how not speaking the same language is the root of many problems.

Having a library of components reduces the time invested in decision making, or as Miguel told me the other day:

Using existing components helps calculating the cheapest way to produce something new.

But that’s not the ultimate solution, as most of tools lack space for things like brand voice, and sometimes we face [design] challenges that drift away from what’s ready to serve in that library, being forced to take decisions in situ, or in other words: to ideate, deliberate and to reach agreements.

That process (designing) implies avoiding this “demiurge mentality”, where The Product Designer™ feels like the architect of all, and delegates construction labor to the minions in developement.

The overall conclussion was:

The process is broken and the tools are inmature.

Sketch revolutionized how we design interfaces, and Figma took that to the next level making it collaborative in real time; none of them feels like actually building the final product, though.

Having in your team someone like Irene, with technical skills and a background in design, is not just awesome: is necessary. But it’s not a magic solution, specially if companies keep planning developement cycles in waterfall, either internally or with third parties.

When I started designing digital products, I had little or no idea about developement (and to be honest, about design). Luckily, I had Carlos Hernández by my side, and he took the time to teach me HTML, CSS, some JavaScript and a lot of cloud stuff that I never fully understood.

We’ve been working like this ever since:

Wrapping up

I’ve heard that the “should designers code” era is over. For my experiences in the Spanish scene, I wouldn’t bet on that. Anyhow, treating that as problem #1 would be, as we say here, “fixing the house starting by the roof”.

The foundation of successful organizations is effective communication –which is WAY harder than learning JavaScript–, not having a team filled with unicorns.

Because maybe it’s not only about designers and developers not fully understanding how each other works, but also how organizations are designed, how the role of management is perceived and how information flows in different kinds of structures.

The #1 problem for me is not that “developers don’t understand us”. Is that most of the time we design whatever the fuck we want, to be honest. Sometimes even using “data” to justify our decisions, and then we pass the ball.

We wouldn’t say that an asyncronous football game where each team plays at a different time makes perfect sense, right?

Let’s keep the conversation going

This was originated after one of the many events that Collisions hosts (almost) every month.

We believe that another way of doing things is possible.
Let’s make it happen: join the community.