Agile Ones

I have always been a firm believer that screen mockups of proposed software functionality provide enormous value when trying to communicate how an application is supposed to function.  It helps both the client and the development team envisage how the application will look, feel and function before a single line of code is written.  This saves a ton of time and rewrite.

However… it’s not fool proof and it only helps up to a certain point.

Momma knows best

It doesn’t prevent people who consider themselves usability experts from making mistakes.  I had a recent experience with a client who said they wanted best practice user interface design, but then demanded everything be done exactly the way they specified.  I created screen mockups exactly as the client requested to avoid the “brass knuckles”, but then provided tweaked versions to try and make it more user-friendly.  It not only added overhead to the process and eliminated creative collaboration, but made every effort at trying to guide the design process a bruising experience.  Frankly, it doesn’t matter how pixel perfect the screen mockup is and if it represents exactly what the client asked for, if the real users are left out of the evaluation, the code will need to be re-written if they refuse to use it.

Setting expectations / Better feedback

The other complication to screen mockups is that they can lead to the impression that the software will look *exactly* like the screen mockup.  I should mention that my screen mockups look like someone took a full 24 bit color picture of a real application.  When laced together in PowerPoint I’ve had people believe it is real software.  Up until now I have always preferred doing mockups with a paint program, because I love color, it helps me visualize what the application will look like, it is very efficient, and there are no artificial limitations on placement, color or functionality that might be imposed by a screen mockup program.  It also does not have the limitations imposed by prototyping tools which constrain how the user interface can function, and could lead to licensing and ongoing maintenance costs if integrated with the development code.

However… I am starting to think it can be a mistake in the wrong context, and I am reconsidering that in some cases black and white wireframes might be better.  There is a great blog entry from Creating Passionate Users which talks about making the demo match how done the application is to foster better feedback from non-developers.  She postulates that “the more “done” something appears, the more narrow and incremental the feedback.  This correlates with some of the unexpected feedback we received on a recent project, where the client spent a considerable amount of time debating what the icons should look like and the color of the fonts, while we were more concerned about whether the functionality was right or not.  The additional complication was that the client became addicted to wanting everything in a screen mockup, even when development was well under way.

http://headrush.typepad.com/creating_passionate_users/2006/12/dont_make_the_d.html

So apparently I am late to the party… I guess I’m not the only one who has run into this issue before.  After poking around and looking at a variety of screen mockup applications I’ve found more than a few where a key selling point is that the output can be made to look like it was essentially drawn on a napkin.  Sigh… Sounds like I’ll have to get rid of my nice satin table linens and pull out the paper napkins.  

Mara Pederson, May 2010