The delivery phase of the design process can take place once we have our content developed and mockups approved by the project stakeholders:

This stage basically breaks down into three tasks:

This last step is by far the most difficult of the three. There is likely to be some significant visual differences between the designs and what has been developed. Even when we have supplied specification documents calling out the margins, kerning, leading, and other attributes, things will be slightly different. The fact of the matter is that the level of control you have over such things in Photoshop is far greater than you have in a web browser. HTML5 and CSS3 have been offered a great deal more control, but often still fall short of what you need.

This issue has actually led to a new career path in the software industry called a UX developer. It is for that rare person who has both the ability to code the frontend as well as an eye for design. If we find that our team has significant issues with the translation of mockups to the final design, we may consider hiring someone to help in this capacity.

With this being a rather common problem, we might expect all eyes to be on the end result. We could argue that it is everyone's responsibility to ensure that the product developed matches the mockups as close as possible. After all, there were many eyes on the designs as they were produced. Many opinions were expressed during their creation, and a final agreement made on content, navigation, and it's overall look and feel. Yet, it more often than not falls on the designer to oversee the efforts of the development team's attempt to recreate what is represented in the mockups. At this point, many people hold strong opinions about the details and nuance of the product; however, these seem to fade from the minds of those who held them once the product enters the development phase.

The trick to resolving some of this before it starts is to include the developers earlier on in the design process. It tends to be natural for a wall to build up between the development and design teams. They speak entirely different languages after all, and get called in at different stages of the software development process. It will be of great benefit to all those concerned if we include them early and often.

Furthermore, we will want to ensure they are involved in the earliest discussions so they can weigh in on the technology or technologies that should be used. A discussion about the desired features and our initial ideas about how we think we will attempt to create the user experience should give them enough information to decide which technology to use. Their decision should give us a better idea from the start as to what limitations we may have as well as what options we might have at our disposal.

Beyond this, we should include the development team in subsequent design reviews. This will help them understand why certain decisions were made and point out the significance of certain parts of the interface that should not be altered. Assigning a primary point of contact from the development team who is included in the brainstorming sessions and designer reviews can help our teams stay on the same page without disrupting the entire development team's schedule.

All of this can help prevent the more serious issue of designs and features being significantly altered or cut without notice. The common excuse is, "I know you are very busy" and "I didn't want to bother you." Set the expectation from the start with the entire team that you would like to be involved with any changes that are made to the function, flow, look and feel, and so on. You may have been documenting the product decisions until this point, but there were many eyes on the work, and approval is given by all. If there is a change in what had been approved, it will need to be discussed with the stakeholders.