Only Designers Should Design Stuff

Whoa whoa, just kidding! But seriously, “Only designers should design stuff,” was said during a meeting with a client product team, and I couldn’t have been more ashamed to be a designer. I actually wrote a post about this a couple of years ago.

Developer Feedback

As designers, we often hold user feedback in high regard. We crave it and base a lot of design decisions on it. We should also value the feedback of developers.

As we work to craft a solution, we should make sure to consult developers. They can provide useful insight on technical feasibility or streamlined development approaches.

Over time, working closely with your development team builds camaraderie. Asking for their input early, and often, builds a lot of trust. It gives us designers an opportunity to understand the ecosystem (integrations, APIs, limitations), but also lets us stress the importance of key design decisions to the dev team.

100% Right vs. 100% Done

I think designers have a misconception about developers that they only care about getting it done fast, and not necessarily right. While I agree that the tech team often looks to streamline areas, it is not unwarranted.

This can actually be another opportunity for designers. When a developer offers a faster approach to developing a feature, take the time to evaluate whether doing it the “right” way adds more value than a different solution. As we work in an agile, MVP approach, getting a feature completed and tested quickly is better than not getting it done at all.

This is not to say you should always defer to your development team on alternative solutions. Many times, you shouldn’t deviate from the original design too much, or even at all. I really hate the phrase “choose your battles,” because it should not be an Us vs. Them mindset. But, definitely be selective about which areas you want stand up for.

Finding Compromise on Design Decisions

Everything my 7-year-old son sees he says he wants for his birthday, or Christmas, or “just because.” The more things he says he wants, the less likely I am going to believe he truly wants it. If we take that same approach to all things design (and their implementation), we create a situation of diminishing prominence. However, if we comprise on some features, but then push hard for others, the development team is going to be more inclined to take on a harder development task for the sake of design.