I frequently spend many hours in meetings with users, emailing users, instant messaging users and phoning users to determine their requirements. I then spend countless hours developing an application that I think satisfies their requirements. Only to demo the app and have the users point out 50 things they would like to see differently ("that's not what I meant"). And around the wheel we go again. All because it is difficult for users to "see" the finished product before it's, well, finished.
I was lucky enough to attend a session by Chris Blatnick at Lotusphere 2009. [Editor's Note: Flattery will get you everywhere! ;-)] Among other things, he covered Low-Fidelity Prototyping, which he has also covered on his blog. He also calls the technique 'paper prototyping' because it is just that, drawing out on paper what the app is going to look like. Everything. Buttons, views, tables, etc. Check out his blog to see more on how to do it.
I immediately got home from Lotusphere and had to try it out. Luckily, I am in the early stages of a new application and could put this right into action. Oddly, I used it on myself first. I think Chris' intent was to get better feedback from users before beginning coding, but I was able to use it to clarify my OWN thoughts on the application before even speaking to the users. (Woohoo!)
I drew out several of the screens required for the application and immediately saw flaws in the design. Back to the drawing board, literally, and I redesigned several portions. Drew them up again and realized several features that I knew the users would ask for when I showed them. I added those onto the drawing. Now I could bring a much more "developed" application to the users before even getting any of their feedback. I looked like a hero! Additionally, they were better able to envision the finished application, and add their feedback, BEFORE I had coded anything!
LFD from a user session. The red pen is actually from the user's input in the meeting, adding two new sections and a field, while removing an entire column of data they decided was confusing to the users.
I am also working on an in-production application. The users frequently have new requests and features they desire. In the most recent release of the application, a new form was added based on vague user input. (You know how it goes, "Hey we want the form to do this and this, you're the designer, you figure it out."). The users had some pretty negative feedback. The feedback tended to be along the lines of "this sucks" and was not very useful in figuring out a solution. I decided to meet with some key users and had a paper prototype in hand. I offered them some visual suggestions as to how we might change the form. Seeing those suggestions "in real life" enabled them to provide constructive suggestions on what they would actually like to see on the form. They were passing the paper prototype back and forth and drawing on it until they agreed on the new layout and design. Again, all before I coded (okay, re-coded in this instance) even one line of code.
I can't recommend this technique nearly enough. It saves me time as a developer and makes the users happy with an end result they like, as well as making them feel invested in the product. I am looking forward to using this in all of my designs.
About The Author: I've been an application developer in Lotus Notes/Domino for four years. I am currently the lone developer at my company, so like many others, I am overwhelmed and expected to do miracles therefore I love to learn techniques and technologies that will make me more efficient! Prior to working in IT, I've been an Investment Analyst, a temp, and even an actress (long ago and far away).