Designers are a precious and proud people. I’ve met a few who would rather have pixel-perfect builds than let their colleagues work normal hours — that’s not a collaborative process, it’s a dictatorship.
The expectation that developers ruin the hard work of us designers is poisonous.
Developers are doing a tougher job than people give them credit for. Instead of complaining, designers should figure how to work with them to make this difficult job easier, and how to work with them to create the most efficient process for everyone.
If this ruffles your feathers, then you might be the one who’s treating a developer unfairly.
Mutual respect
I can’t work on a team where people don’t have respect for the work and skills others have. All of our jobs overlap. UX Designers, Visual Designers, Developers, and Project Managers each have skills the others do not, but they also overlap.
This isn’t just an empty ‘Hey, I respect you’ and a thumbs-up, it’s allowing people to take ownership of their own work, and giving them control over your work too. Even though they’re a developer, they may be okay designing something from a quick sketch based on your visual language without any design input!
Mutual respect gets rid of the us and them mindset. It helps develop better relationships with your colleagues by fostering a happier environment.
Don’t be so damn precious!
Design is about communicating something in the most effective and appropriate way possible. Fuck this nonsense about it fixing the worlds problems. It doesn’t.
When working with developers, this means reaching pixel-perfection on that new Halfords site is a low priority. The highest priority is making sure the message you wanted to convey is conveyed in a way that doesn’t look broken. That’s it. Getting miffed about kerning is just going to make you angry, and the developer frustrated.
My development critique is a two-step process:
- Does the build communicate what I wanted it to communicate in the most appropriate manner?
- Are there any fundamental visual or interaction design problems?
If the answer to #1 is ‘yes’ and the answer to #2 is ‘no’ then it’s okay for that to go live. That’s not to say I’m flimsy about the details… Rather, I think it’s more important time to sweat the big picture stuff instead of worrying about the border radius of that text input in the footer of a website.
The highest priority is making sure the message you wanted to convey is conveyed in a way that doesn’t look broken. That’s it.
Adapt to their processes
Development is a rigorous process. It requires lots of planning, tools, and applications to help it flow smoothly. I’m not saying us designers have it easy, but I’ve never seen a visual designer have to work until midnight on a Friday because the recently deployed application doesn’t work on some obscure mobile OS.
By saying ‘yep, I’ll create a GitHub issue in that branch’, you are making a developers job easier with very little effort. This is the environment they are used to, and it’s easier to figure out how to create a Jira ticket with an attachment than it is for a developer to find the exact folder where my most up-to-date designs are.
I’ve never seen a visual designer have to work until midnight on a Friday because the recently deployed application doesn’t work on some obscure mobile OS.
Respect their time
I’ve worked with designers who assumed their time was the most precious on an entire team, but it wasn’t true. I’ve been busy, but I don’t think I’ve ever been as busy as a developer, so I trust that the thing that they’re doing is going to get done.
To help this in the past myself and developers have sat down together and gone through the list of tasks — bugs included — and prioritised all of it. It provides an opportunity to understand what takes time in development, figure out whether a feature is worth the effort, and for us to negotiate the importance of tasks.
Developers can be their own time managers, they don’t need a looming designer asking them when that typographic hierarchy is going to be fixed.
Get them involved
What’s worse than being dropped into a project at a crucial stage? This is when many developers in an agency environment are called in. Designers should be proponents of collaboration, getting developers included at an early stage.
This isn’t just inviting them to planning meetings, it’s involving them in workshops, sketching, design critique, and anything else you are doing.
A developer’s insights are valuable from the start, and the feeling of involvement from being present will make them respect and love the project even more.
This entire post is selfish
We’re not an altruistic species and I’m not going to pretend to be either. I don’t do the above for selfless reasons, I do it because it makes life better for me. By making developers more design-aware, by making our processes more efficient, and by having a happier team, it makes my life easier.
If I adapt to their processes, they adapt to my processes. If I respect their time, they respect my time, and if I get them involved, they’ll get me involved too. It works both ways. We all win.
Thank you for reading my post! If you enjoyed it and want to stay in touch, let’s speak to each other in one of these places: Twitter, Instagram, my portfolio.
The post Designers. Work better with developers. appeared first on Design your way.
Source: http://ift.tt/2uscynN
No comments:
Post a Comment