Hey designers. How often have you designed this…
…and had it show up in the product looking like this?
More often than you’d like, I’ll bet. It’s very frustrating, especially when you’ve spent days getting your comps pixel-perfect. What can be done to prevent it?
Often, engineering teams encourage the designers to “file a bug” for every flaw. This works poorly for two reasons. First, filing bugs is tedious, error-prone, and discourages conversation between the designer and the front-end engineers. Discussing the technical and design constraints often leads to a better solution for both parties, but the bugbase is a poor medium for this discussion. Second, fit and finish bugs tend to fare poorly during the bug triage process. Individually, they just aren’t very important, but together, they are extremely important. Triage, which usually looks at each bug in isolation, loses sight of the bigger picture when prioritizing design bugs.
Recently, I’ve started encouraging the teams I work with to adopt a process proposed to us by Marty Cagan – I call it the Product Punch List because it’s similar to punch lists in building construction. Once the product or feature reaches “substantial completion” the engineers and the designer schedule a “fit and finish review”.
The focus of the review is to uncover all the lingering look-and-feel defects. The goal is not to find workflow, functionality, or interaction framework issues – usually “substantial completion” occurs relatively late in the process, so these must be in line with what we intend to ship. Attendees must include the product designer and an engineer, ideally an expert in UI programming who will make the fixes herself. Depending on the team, the product manager/owner, quality assurance engineer, and/or members of the management team might be required as well, but I try to keep the meeting as small and efficient as possible – we likely have a lot to cover!
During the meeting, we walk through every piece of new UI in the product. And I mean every one – every menu, dialog, and error message. For every defect we identify, we record an action item, either for the developer (“move the label 2 pixels down”) or the designer (“redo the dialog layout for a 500×400 size”). If the developer expects the implementation of a proposed change to take a significant amount of time, we may discuss alternatives. But if a suitable one doesn’t present itself quickly, we leave the change on the punch list as-is.
For the review to have an impact on the product, the management team must allocate time for the developer(s) to make the fixes. This may be a team effort, or may be assigned to a single UI expert, but it should be allocated as a bucket of time during which the developers try to address all the issues on the punch list (it’s often a good idea to have the designer extra-available during this process, sitting alongside the development team if they don’t normally do so). If any punch list items cannot be addressed in the chosen time frame, we log them as bugs and allow them to go through the normal triage process, but the team makes every effort to prevent this from happening to as many issues as possible.
When the process works well, fit and finish improves tremendously after the fix period ends. Suddenly, the entire team realizes their product can be beautiful as well as functional, which helps raise everyone’s internal quality bar. When the whole product looks bad, teams can develop a fatalistic attitude, refusing to fix even small things because they (correctly) believe it won’t make a difference. But when the product looks polished and beautiful the small flaws stand out, and often the will to push it over the hump into greatness suddenly appears.