How to win developers and influence features as a designer.
Jokingly at Hashrocket we have defined the cycle of development as a three step process. We toss it around jokingly but the it's sort of ground in truth.
- First the devs complain about the feature.
- Then they implement it with great speed.
- Finally they congratulate themselves on a job well done.
It's funny but there is some truth in there. As designer it's my job to set the project team up for success wherever I can. Design aesthetics are important but just as important is working with your project team.
Even this development cycle allows for that ideal but most of all it comes down to trust. Unfortunately that's the part of the equation that takes the most time but here are some simple concepts that will put you on track.
First the devs complain about the feature.
If the dev team is complaining about a new feature it's a product of one of several conditions.
- They were totally unaware of the features existence.
- They disagree with the features value.
- It's a tedious task that they're not looking forward to it.
The first scenario shouldn't happen. Not only should the entire team be aware of upcoming features but as a designer I should be having discussions with the dev team personally about the interactions I'm designing. I need to have enough humility to listen to others but the confidence to stand up for what I believe to be the right decisions.
The second condition also is usually a product of poor communication. Getting the whole team on board with new features is invaluable. No one want's to work on something they see as being worthless. The "why" for any feature is important to the whole team not just me the designer. If you can get complete "buy in" from everyone it will go a long way.
The last scenario is not always avoidable. Some features are necessary but not glamourous or fun to develop. Just like it's not always fun for me to design forms, it's not always fun to implement them. Sometimes we just have to "suck it up" and do the work that needs to be done. Don't worry. There are always some cool new problems to solve just over the horizon.
They implement it with great speed.
This leads me to something everyone hates. Doing things over. There is a difference between changing a feature based on user feedback and something that was implemented wrong. If this happens it's on you as a designer. More than likely you failed to communicate or didn't provide all that was necessary. Take responsibility, learn from it and do it better next time. No excuses.
Finally they congratulate themselves on a job well done.
It's time to celebrate your victory. And more than likely you were a part of it since you set your team up for success. More than just a high-five will go a long way. Inquire about the challenges the devs faced. Don't just act interested. Be interested. It's invaluable for building relationships and by now you should have checked your ego at the door. Caring and respecting each others roles and work is the only way to build trust. If you want to step on toes and belittle your teams roles then you're creating unnecessary hurdles for yourself and working with your project team.
The simple conclusion.
It seems so simple. Communicate, provide the necessary assets and celebrate your victories. But more often then not when we have visiting developers or designers they are blown away by the relationships and dynamic we have within our team. It may appear easy on the outside but I assure you we've worked hard to have the level of mutual respect and trust that exists between us. So designers, embrace the cycle of development and set your developers up for success. In return you'll have a better product and mutual respect from your team.