Feedback
Posting a mock-up for the world to review has reminded me a typical and often repeated scene in my experience as a software developer.
It usually goes something like this:
I take a working prototype or screen shot to a co-worker in hopes of receiving feedback on the functionality or layout. Any given screen shot or prototype probably contains at least a half-dozen, usually more, concepts that were greatly debated. Likewise, there may be at least as many concepts that are just throw-in’s because there is not enough information yet to design it or lay it out completely.
The latter category often includes things like fonts, colors or wording of various labels. These are details that are really important to the final delivery, but are often not very important in the early stages.
However, when I hand this work of genius (imho) to a co-worker, they are immediately drawn to and highly annoyed by one of these “unimportant” details. I’ve had many heated discussions about designs due to this kind of misunderstanding. What I’ve learned, after all these years, is that I am usually on the wrong side of that argument.
If you want feedback on a proposed layout but the reviewer is horrified by latin filler text, labels that say “Default”, gaudy sample colors or the use of Comic font, don’t get mad at the reviewer. They are giving you valuable feedback. Sure, it might not be about the feature were asking about. But it is valuable feedback.
Do something about the thing that is bothering them and then ask for feedback on the feature in question. Remove it, put in dummy text, put in real text, use a generic font, or get rid of all colors. Whatever it takes. If your design isn’t flexible enough to let you do that, re-consider how you are prototyping.
I’m sure this is why many Information Architects recommend prototyping on paper instead of in PhotoShop or in working prototypes. People tend to make all kinds of incorrect assumptions about a screen shot and become inflexible. Where as, clearly a drawing on a napkin is just an idea that can be easily modified.
Here at FogFanz, I just experienced a slight variation on this story. My original idea for the makeover mock-up was to test out the idea of putting big honkin’ icons on the FogBugz interface. However, as I created the screen shot other potentially good ideas began to dominate my design. Or at least they dominated the part of the design I liked.
But then, readers did exactly what I asked. They commented on the icons. My favorite thus far is this one:
Why would you waste so much space on large icons? That’s an improvement?!? Please don’t listen FogCreek!
By the time I read that comment, I was already convinced that the icons, at least as I had envisioned them, would not go over well with existing FogBugz users and Fog Creek would need to have a lot of confidence in a design to upset their existing users like that. But at the same time, I was temporarily frustrated that the commentator in question appeared to have disregarded the entire design because of the icons.
For a fleeting moment I thought “but what about the other ideas?!” That was my problem, not commentor’s. The only thing to do was to create a version without the icons and see if, without the icons, the ideas stood on their own.
If something in the prototype is causing a problem and distracting from the issues you want to explore, remove it! If it was a good idea that was just poorly implemented, you can always get back to it later. Good ideas won’t just go away. They find a way of working themselves back into a project. But bad ideas need to be vanquished as soon as possible.
