As a mobile dev, this article kind of irritates me. It seems like the author is trying to shift his responsibilities to the client or designer. Here some tips:
- wireframe first. At least on a whiteboard. Build the interface with stock or ugly controls from that, iterate the interaction. Only once that is done, send ugly screenshots to the designer to beautify.
- I believe that every dev should have photoshop, and know the basics. You shouldn't need a 24 hour turnaround to cut an asset or fix a small issue.
- actually talk to the designer. Don't make the client be a middleman. When you feel a screen is done, review it with design first. Try for pixel-perfect accuracy, but don't get too hung up on it, often a five minute chat can suggest alternatives that save hours of work.
- always decide what screens will work in landscape, or portrait, or both, up front. This is easy to forget and sometimes difficult to retrofit.
- not the only approach but one that works for me, pick one device (screen size) to be the "hero" device for a project, and build for that first, then go back and and adapt for the rest. This works better if its a more constrained device, as adapting to a larger/faster device is easier. I often use a 5c as the target.
I disagree about every dev needing to have photoshop and knowing the basics - even though I personally have done this in the past i have found it to ultimately be a waste of time - something looks simple enough to change, sometimes you get lucky, it is, other times, 20 minutes later you're looking through photoshop menus/dropdowns. The designer know these tools the best, I'd rather take your third point and talk to the designer and communicate that you need him/her to be available to work through these points. There's so much for a developer to know and be focused on without having to learn to use the designer's tools as well.
Just like the designer would benefit from knowing how code works, don't you think the developer would benefit from knowing how photoshop works?
I find it kind of interesting that a developer would even feel a reluctance to understand one of the basic methods used to deliver to them what they need to develop.
You are missing out on great opportunity to have an informed opinion, think about alternatives, find potential business ideas from something thats not optimal and in general just have a better and more productive relationship with designers.
I at least realized that learning to code as a designer, even just a little bit, both taught me a great deal of how to build things for developers, help them solves problems that might require a different way to think about the technical issue of something and not do stuff that are completely retarded and impossible to do.
No they are actually benefits from learning photoshop because you understand what they are doing more technically. Adding a drop-shadow as an example. Or doing a gradient with specific ratio, angle and so on.
You literally get access to the very parameters and their values you might have to use.
It's not about learning how to use photoshop. It's learning how photoshop works, just like I learn code to understand how most code work. That doesn't mean I would call myself a developer who can code like a pro.
- wireframe first. At least on a whiteboard. Build the interface with stock or ugly controls from that, iterate the interaction. Only once that is done, send ugly screenshots to the designer to beautify.
- I believe that every dev should have photoshop, and know the basics. You shouldn't need a 24 hour turnaround to cut an asset or fix a small issue.
- actually talk to the designer. Don't make the client be a middleman. When you feel a screen is done, review it with design first. Try for pixel-perfect accuracy, but don't get too hung up on it, often a five minute chat can suggest alternatives that save hours of work.
- always decide what screens will work in landscape, or portrait, or both, up front. This is easy to forget and sometimes difficult to retrofit.
- not the only approach but one that works for me, pick one device (screen size) to be the "hero" device for a project, and build for that first, then go back and and adapt for the rest. This works better if its a more constrained device, as adapting to a larger/faster device is easier. I often use a 5c as the target.