One of the most common frustrations in software product development is the disconnect between what a designer envisions and what a development team delivers. As a product manager, I am certainly not alone in my experience of repeatedly trying to untangle why the product that our team shipped deviated so much from the original concepts we saw come from the designer(s) on a project.
Sometimes a mockup can be a very high-level suggestion or illustration of the basic data elements and intended user stories. In other team workflows the design is meant to be implemented literally, perhaps even down to the pixel. From what I understand from conversations with Kayak founder, original CEO and product visionary Paul English, he would work with designers to create exactly what the product should look like and do, and deviation from that was viewed as incomplete work. But for most of us, things won't always turn out pixel perfect so understanding what happens between design and production is important.
Over the years I have dived deep on various occasions when this has happened, and come up with a handful of common and very different reasons for this disconnect to arise. Here we will discuss each reason, as well as strategies for addressing the different scenarios, should they arise in your work.
While working on a feature lots of things can change. In the best case scenario you'll have the designer embedded with the developers and a close relationship between these folks drives collaboration which leads to a terrific result. That means that throughout the process the designer might iterate and create more mockups and/or the designer and developer might work on the feature together in real time, leading to a productive and healthy deviation from the original idea. Along these lines the development team may learn from user testing that the design has some deficiencies or stumbling points and as a result iterate on the original idea to improve it based on these learnings.
Changing the idea as you go is healthy as long as the designer is involved every step of the way so they're not surprised when they see the final product. That's why it's important to be clear on what is changing and why the team decided to pivot. Your team should be documenting what they learn and sharing their rationale along the way so that everyone is on the same page when it comes time to ship the final product.
The tendency for designers to mockup screens and features using data they make up as they go is overwhelmingly common. The danger here is very real: the real (production) data can present a host of unforeseen challenges. These challenges range from the severe to the more mundane. Perhaps the mockup turned out to be actually impossible or highly impractical to implement; for instance it is not uncommon these days that there are search or sort features that the datastore is not prepared to deliver. Less severe but still a speed bump would be text content being longer or shorter than the designer had expected.
An example that has stuck with me, having been a product manager for many versions of the timeless "contact detail page," is the reality that the data a CRM system has for a given contact is often disparate (data for some fields and not others) and various (countless possible fields). When these screens were initially designed it was easy to assume that each contact would have a small number of key/value pairs populated, but we quickly realized this wasn't the case. We handled that at HubSpot by a) allowing "favorite" properties so each user can easily see the data they care about (common for sales reps) and hide the other data and b) show all the fields on a separate screen intended for the debugging/integrating/etc use cases (common for marketers or Ops folks).
Design with production data! It takes more time and effort, but it is well worth it. It's also a great excuse to keep the design folks close to the engineers early in the process.
Details, details, details. Not everyone is a detail-oriented person; some people write the essay before completely reading the question while others digest the question and make an outline before diving in. Not surprisingly, the way these two types of people approach projects, vision, and ownership varies. As a result, disconnects can arise when work crosses from one discipline to another, carrying the expectation that details of all sizes will be recognized, respected, and implemented.
It's not hard to believe that developers who are deep in the details of "left-brain" work may approach the visual implementation with a drastically different attitude than those who created the mockups or prototypes. In these cases it's imperative for the designer to have a close relationship with any of the engineers implementing the designs, and to feel comfortable underlining that, yes, in fact 20px of padding versus 2px of padding is a universe of difference.
Next time a detail is overlooked, use it as an opportunity to set a tone for why the team should get in the habit of paying closer attention. Log those moments as bugs and clarify in the ticket why details matter. The team will quickly get the message and start switching gears.
No developer is quite like the other. Some have stronger opinions about design and different ideas on what the "right" approach is. At HubSpot we have team members who focus entirely on design engineering, for example, and these folks are understandably much more vocal about the user experience and look and feel of the product than, say, back end engineers. But at the end of the day, everyone involved in the process brings their opinions to the table; the problem arises when they aren't discussed, explored, and put out on the table. There's a good chance that the last person to touch a product before it ships will not see eye-to-eye with the original concept and that's when the outcome switches gears.
It's crucial to communicate who the owner is early and often. The rubber has to meet the road somewhere and ultimately there needs to be clear ownership over the user experience. Whoever owns these final decisions in your culture, be it designer, PM, or someone else (if it's not the designer though, then ... why? just, why?), that person needs to casually reinforce the ownership model. Saying things like "there are clearly several approaches here and though it might not be perfect I'm going to decide that we do the following..." makes it clear who's calling the shots.
Let's face it: every developer has a different skillset and not everyone is a master of CSS and HTML. Even those with fairly extensive knowledge of front-end technologies might need to stretch to implement a mockup to the pixel. One senior front-end tech lead on the HubSpot team once spent two hours implementing a gradient because a designer insisted it was important. It was a tricky implementation that was new to that developer even though he's senior in his experience and talents. In some cases, those two hours might not be as easy to find and can shift the outcome of your product.
Work with engineering leads to ensure that front-end engineers have the tools and workflow knowledge to implement designs accurately. Guarantee that skills like determining what color type is being used and measuring padding and margins in the mockup are common knowledge across your group.
These five obstacles and solutions echo a common theme that will help keep your mockup and final outcome on the same page: tight alignment between product, design, and engineering is crucial. Collaboration across teams and talent is key to developing successful products so don't let miscommunication or other avoidable hurdles throw your team off track.