Achieving Fit and Finish with Punch Lists

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.

2 Responses to Achieving Fit and Finish with Punch Lists

Ken Sundermeyer was the master of this. When we were working on Contribute, he (along with NJ) would do fit and finish reviews with each feature team as each feature was being completed, and it made a world of difference.

This happened to me recently with a client (go to gild.com and you’ll see what I mean). I believe the solution isn’t to hold more white-noise meetings that eat up valuable time (especially in a lean start-up environment). Instead, I believe the solution is to hire designers with front-end chops. They’re rare, but they exist.

If you can’t get your hands on designers who possess both the level of detail and finesse that makes an excellent visual designer, plus the coding skills to implement those designs correctly, then it’s best to have a good front-end developer on hand who employs levels of extreme attention to detail — who knows CSS better than anyone else in the company — and source your visual design work to a freelancer, contractor, or someone off-shore until you find that rock star.

Design is important; very important. With mobile trends expected to grow exponentially in the future, design will be more important next year than it is today. Also, with mobile sweeping in, product designers literally have less real estate to work with. Because of this, designing for mobile forces you to focus on what’s important, and enables you to innovate more on an interaction level. In this regard, pixels are “worth more” on mobile than they are on desktop.

Especially in the future, pixel-perfection will continue to grow in necessity; and on a side note, as technology continues to phase out reliance on plugins, heavy assets, and rich media, designers will be expected to have those coding chops as an absolute minimum requirement.

Very soon, core UX people will graduate to a special flavor of product designer that this industry has yet to see for the most part. I believe UX will begin to separate itself from UI more as mobile gets comfortable with its new throne, and as UI returns to its aesthetic roots. What I extrapolate from that forecast is that this problem may actually solve itself, as our industry gets more sophisticated. UI and visual designers will also be CSS3 gurus, and UX designers will handle a lot of the psychology that visual designers should’ve never had control of in the first place.

This transition will result in an extremely valuable liaison design role in start-ups everywhere; and it’ll hopefully move us one step closer to closing the gap between design and engineering.

Search for:

About Rob

Rob Adams makes products people love. He is currently employed as a design researcher by Adobe Systems, Inc.