“It’s a bummer that the implementation looks completely different than what we designed”

There are very few things more disappointing when I’m interviewing someone to fill a UX or UI Design position than that comment.

That one.

That exonerates the designer from anything.

That puts the blame on another person, another team, another country, another universe.

That one. That usually comes after a praise.

“This interaction you created is really great.”

“Well, thanks… It’s a bummer that the implementation sucks though. The developers weren’t able to follow what we told them to do and ended up implementing something really bad, super hard to use.”

Breathe.

If the experience wasn’t implemented as we envisioned, that’s as much our fault as it is anyone else’s.

Our role as designers is to create *experiences* that are easy to use, not *mockups* that are easy to use.

We are entirely responsible for the products and experiences people use. That’s our job; it’s in our job title. Which means we are also responsible for the final product implemented by our teams.

If the final implementation does not look great, one of these things happened along the way:

• You didn’t follow through all stages of development and were not available to give feedback and course-correct as the code was being written.
• You designed an interaction that wasn’t feasible in the first place, considering the limitations of that platform/code language.
• You did not document the interaction with enough detail, which caused the developers to lose track somewhere along the way.
• You ignored the developers’ concerns when they tried to alert you that interaction was too hard to implement.
• You didn’t have enough discussions with the tech team about creative workarounds that could fix the implementation issues you and your team were seeing — or to simplify the interaction a bit.
• You didn’t come up with a plan B or C when you realized the implementation was not going to live up to your (and your users’) expectations.
• You didn’t test enough with users to realize that interaction was not as conventional as you thought it was. If something is not conventional, it makes it naturally harder for developers to have a reference that they can follow.
• You didn’t share the ownership of the work with the developers, in a way that would make them feel part of the solution — as opposed to just following what you told them to do.
• You weren’t able to convince your team (or your client) to launch a 1.1 version with fixes to that issue.

Sure, you are hired.