The purpose of the Flickr group is to share wireframe photos of all types.

There are a lot of great ideas floating around in the group. If you are a UI designer and want to publicize some of your wireframes, methods, etc. I encourage you to do it. In the end it can inspire and teach you new techniques. After I finish working on a new wireframe project for an application I’m building I hope to get some pictures listed in the group.

Related articles:

1. SXSW 2009 – Day 2
2. SXSW Interactive 2008 – Day 1 March 7, 2008
3. Blog Response: IE 6 The Devil Not In Disguise

Lately, I’ve been trying to push the power of paper-prototyping. It’s a tough concept to get across though because some just don’t see the value. In fact, the customer, BA, Product Owner, just want you to show the customer a mocked up (coded) prototype. This is nerve racking because problems and issues in the design can be ferreted out much quicker using the paper prototyping method.

The overwhelming response to paper prototypes that I have personally faced is: They don’t seem professional, are hard to read, may be difficult to understand complex web actions. These people need to quiet down and listen. Paper is cheap and easy to modify on the fly. Paper prototyping is more than just showing a piece of paper. It’s about defining, refining, and streamlining the interaction between the user and the proposed widgets, functionality, etc. Paper and markers and traditional means can represent all these concepts with little difficulty. You just have to get a little creative at times, but the new ideas that come from these paper prototyping sessions can point you in a new direction.

Several times I have worked through a prototype with limited customer feedback(not recommended) and discovered core application function that was not identified. By discovering this up front you can better prioritize absolute functions from secondary functions. IE: I need to be able to save my book title, but I also need to give it a custom save descriptions.

Customer: “Wow, we never thought about that. We just wanted them to save the book using the title as the saved name.”

You may even discover larger problems such as entirely missing pieces of functionality.

If at all possible you should involve the end customer of your product. I’ve been trying to get this practice cemented into our process but it’s not an easy one. The general premise is this; everyone feels they are right and specs were translated correctly into business needs. It kind of makes sense that you need the customers input to ultimately test the system? However; this type of input rarely seems to happen at the level required. Focus groups, usability testing, is an afterthought and tends to be reactionary instead of proactive

Related articles:

1. Which Widget is the Right Widget for My Application Design?
2. When is it the Right Time to Use Icons?
3. Design Experiences: Don’t Rub Your Product Experience All Over Me.