Don’t Drop That Shadow

As a coder, I spend way more time worrying about how something works, or how someone might break it, than on how it looks. I leave it to the designers to fret about that sort of stuff, and just make sure it’s usable and won’t crash when fed crazy input. (What my high-school physics teacher called “monkey-proofing.”)

A recent project is a classic case in point: tons of UI stuff going on, and the flow isn’t completely worked out, so I built a somewhat functional prototype. It’s nowhere near finished, but the parts we’re focused on right now are working. The designer had included some drop-shadows along the edges of these elements, but as they had nothing to do with how they work–they’re sliders that can be “tossed” and animate to a stop–I omitted said drop-shadows.

Guess what the designer’s very first comment was? “The drop-shadows are missing.” Even though we both knew they were completely extraneous to the actual issue of how the animation works, he just couldn’t get past it. It was like an air horn blasting over a gentle harpsichord melody off in the distance; in your ear, it’s all air horn.

Tonight, as I continued working on the prototype, I figured I’d spare him the visual agony and put the drop-shadows in. It took about five minutes.

So I figure I saved five minutes last night only to spend five minutes tonight, plus several minutes lost today discussing the damn thing. In overall time, I lose, but I lost even more: it also took time to get the designer to focus on what really matters about the UI, which remains a not insignificant issue. But for all I know, his brain is clouded even now by drop-shadow absences.

I guess the moral is, for the designer’s sake, and your own, ┬ámake even the prototype look as much like his design as you can. Evidently it’s a corner you just can’t cut.