I've worked with a lot of developers and having to hand off designs. It needs to be collaborative. It depends on what you are trying to solve. Don't expect your design to be pixel perfect. As a designer you should allow the developer to help solve the problem and communicate what you are trying to achieve. Identify where it falls apart and why it matters. If you can get them on board with what to look for, they start fixing those problems ahead of your review so you can start solving bigger problems that help usability. Sometimes you need a lot of mockups. Sometimes you can trust your dev to make it better. Do as many mockups as you need to illustrate your point. The more you involve them in the problem, the better they will be at helping you solve the problem.

Primarily a developer here**

When a member of the team hands over designs, few things go through my mind:

1. Have they provided all screens?
2. If they only provide one screen do they assume I'll adjust for smaller/larger sizes?
3. Do they have any thoughts on a grid system? Was it employed during the design?
4. What level of flexibility do I have in the development of these designed files? Things like a fluid layout vs pixel based, normalizing spacing values, etc.
5. Where's the style guide?
6. Is there any method to this "madness"

Overall - It's best to set these standards in the beginning with the developer (team) and over-communicate throughout the process.

Now each section in a little more detail

1. Have they provided all screens If the design team has provided all screens (or representation of breakpoints) then a developer can easily get things started, especially in a flexible manner. This means start with small/mobile and work up to large/desktop screens. This also allows developers to focus on development and now worry about designing in the browser. (Note: I work at an agency and while we love to design in the browser it can sometimes put a strain on a project schedule and budget).

If you can provide all screens, do it! It'll make development easier and uncovering any overlooked areas even easier to spot too.

2. If they only provide one screen do they assume I'll adjust for smaller/larger sizes? This happens sometimes if only one screen is provided and expected to be adapted for others (hint: typically large/desktop is provided). While this is fine it just means more development time. I first hand tend to use hypothetical values for things I know will need to scale. Or at least try to preset mobile/tablet values but having all PSDs are best if possible. Sometimes it's not possible and in that instances I think over-communication makes for the best solution.

3. Do they have any thoughts on a grid system? Was it employed during the design? Grids are about as common as cell phones these days but sometimes they are not visually represented in the final design file handed over to the developer. Personally, I'm moving away from Bootstrap based on its bulk and leaning toward smaller libraries that still provide shorthands for grids without all the cruft of other code. So, for me, if there isn't a grid I will typically use something like Bourbon to help create a grid on the go.

This can sometimes cause issues, though. Sometimes a designer might have something else in mind that wasn't communicated. In these instances we run into a tough problem, depending on how far into development we are.

1. Live with the grid used in development
2. Go back and recreate.

It's not necessarily tough for technical reason, just annoying to go back and re-do something based on a human error/oversight.

A quick and easy solution for something like this could be to have a pre-design meeting with the design/dev teams and figure out what those standards are. This way, both parties can try and preemptively prepare for whatever grid system is coming into place. And this way, you can determine if that grid is a pixel based grid (thus snapping into place at breakpoints) or a percentage based grid (fluid). If you know these things up front, it makes it easier to design and develop for.

*4. What level of flexibility do I have in the development of these designed files? * Things like a fluid layout vs pixel based, normalizing spacing values, etc. This is always the toughest for me. When final designed files are handed over, dropped on my desk, whatever, and I open those files for the first time, I never really know what I'm going to get. I'm unsure of the layer structure, the systematic thinking behind the design, what intentions were expected or even where to begin.

Often times small things like interactions or the "in-between" breakpoints scenario pops up and I'm left to make the decision on my own. While this is all fine and dandy more times than not, once the designer on the project reviews the work there are tons of critiques due to undocumented design.

Good example: designed interaction states for buttons, links or how font scales between small to large screen.

If a developer makes design assumptions it puts everyone at risk. Not that a developer can't make those assumption, but because they do not have the same context as the designer to the design.

Create a plan. Document. over-communicate to prevent hidden design "bugs" from popping up due to unacknowledged design elements.

5. Where's the style guide? Style guides usually act as my foundation when designing a site. It helps me quickly get up to speed with the base styles and how those building blocks add up to create a larger site/app/ecosystem.

The style guide should be my guide when asking any questions.

This document should set the basis of the design elements, the spatial representation of those elements, the interaction of those elements. And in some instances a few examples of primary elements in a responsive nature (small/medium/large screen adaptation of a module).

For me - I think my ideal hand-off would be a final design final with the accompanying style guide.

6. Is there any method to this "madness" Sometimes designers set up really cool, really smart design patterns that may go unnoticed to a developer. I recall one instance were a designer on my team changed the text color based on the page a person was one (this way it was all color coordinated and associated). While it was a great way to associate content, it wasn't something I easily picked up on.

Patterns that are unassuming should be documented to make sure its relevant to all.

But other than patterns, if there is anything that might be out of the ordinary or a "gotcha", be it brand/client related or a caveat that must be kept, these are the things I look for when reviewing design files before starting development.

Overall

• Plan - whats expected for the project, for the designer, for the developer.
• Document - what is agreed on, whats expected and what "gotchas"
• Communicate - throughout the entire process. In documents (style guides) in slack, in file handoff.

SB: It's an ever changing process so be aware it won't happen over night.

I can tell you how avoid a lot of these issues where I work. There is never a completely full proof way and I know not everyone has the same flexibility to work in different ways but this works for us. We try to always be tweaking and refining this process.

1. We wireframe together. - we discuss features and requirements in detail with the client, the development team, designer and project manager in the room. The wireframes are created as discussion happens to help keep everyone on the same page.

2. Design doesn't happen in a vacuum - With those wireframes design will be created based on the requirements. There will be a time for changes and even the development team is asked to be involved. Not every screen will need to be designed in PS or Sketch or whatever. Once look and feel and ui patterns are established the need for those tools becomes less.

3. Designers write frontend code - This is key for us for a lot of reasons. Since we are responsible for the interface from wireframe through implementation you have to worry a lot less about someone else making design concessions in the interface. Also that understanding of how things are made helps inform better design decisions in the early stages. We are fans of bourbon and have some of our own internal tools. We don't feel like grid systems or things like bootstrap or foundation work well for the custom software that we're building. This is just speaking for our workflow.

4.We keep an area of the app with a representation of all the ui in static form. These are screens that are used as our sandbox before things are "wired up". They represent the layout and styles and serve as an example for interactions before they are implemented. We have some process and internal tools around this that have become invaluable.

5.Development happens - the dev team will pull in our ui that was sliced. This just continues the dialog. Were there any issues? Does something turn out to feel less than ideal once it was starting to be implemented. Nothing here is written in stone and we encourage any member of the team be part of the discussion when it comes to UX.

1. Pushing to staging - after features are finished they get pushed to staging for testing and verification. It's still the designers responsibility to make sure the ui works in an optimal capacity and the client is going to verify and test the interactions.

2. Push to production - once things are verified, tested and certified as ready for production then they are pushed. Still always needs regular testing and checking from design.

• Deliver (semi-)working front-end
• Pair programming / designing
• Rough sketching on a whiteboard
• Deliver components instead of screens

Your design is finalized in the browser, not in Photoshop or specs files.

I'd design the site for each of the breakpoints that you plan on having. Your design would change at each breakpoint based on your content. The developer just needs to see how the site should react. I would start with a mobile design and add breakpoints as you need them based on content (not devices).

Regarding pixels, I think we need to move away from this mindset and move towards fluid layouts that are device and resolution independent.

Hope that helps :-)

Ideally the developer should be working with a framework such as Bootstrap for responsive design. I still haven't found the perfect way of handing off a design but at the moment I provide desktop, tablet and mobile version. I don't have time to design the in-between breakpoints so if the developer doesn't nail it, I pair up with them and we do it together. Before Zeplin launched I would provide a JPG with annotations, an invision prototype and an updated style guide. Using bootstrap SHOULD mean that you don't have to provide a mockup for all breakpoints, but it depends on the talent, passion and flexibility of the developer. As for percentages - NO WAY, just pixels and they can calculate it themselves.

In a creation fase I start with designing the most important pages in Sketch and Photoshop. I start with mobile and work my way up to a desktop view. These usually function as concept art.

During this fase I also draw any navigation patterns and, depending on the solution, I use a tool like Quartz composer to visualise interactions (that is easy to demo later on).

I'm working in a small team and only recently got access to frontend devs that actually know what they are doing. Until now I always create an interactive prototype using HTML, CSS myself.

Developers then do their magic stuff with Angular. I guide them and give feedback if necessary until a page is put online.

An interactive prototype really helps managing all your stakeholders. It also gives an accurate representation of what you'll get in the end.

For more or less complex interfaces we create a psd for tablet portrait and mobile view. As there is a team working on a project - designer usually consults the developer when creating mockups for responsive design.

This approach has been working fine so far.