Sustainability, or the idea of zero waste and reuse of things created (concepts & code), also applies to the world of user interface prototyping. On one hand, there might be a push to build prototypes of such quality that the code that they rest on could be reused further in the development process. This so called “sustainability across a process” is just one approach of how UI waste can be reduced. Another way of building sustainable prototypes is by reusing elements from project to project. So if on one project a widget was used in a prototype, and then the same code is used on another project, it would be a sustainable act as well. This I’ll call “sustainability across projects”.
The truth is that at times there is more value of building “throw away” prototypes that are not of production ready quality. Building something quickly without regard for code quality, learning a lot from it, and then correcting the design direction could be more fruitful than building “high quality” prototypes whose code makes it into the future. However, in order to support sustainable or reusable prototype elements across projects, of course we need the right tools and setup. The idea of relying on emergent patterns is a sustainable across projects concept which EightShapes has been supporting with their unify framework, but also something I potentially want to implement for fluidia.
Nice post. Personally I like an approach where in the initial faze of rapid prototyping (called spiking) you do not have to consider reuse of code (nor the aesthetics of the UI). This would mainly be done to prove or disprove a concept as early as possible and also help the team realize what parts of the project will be difficult or time consuming (also helps in estimating the projects time frame for clients).
I´m all for pretty and reusable prototypes with a unified UI but over the years I have found this reserved for projects with higher budgets, lots of alloted time or (in worst case) teams with bad communication skills. Keeping a library of code/graphics/components updated is time consuming. In the end prototypes are most often created to test something unique and new (well at least from my perspective coming from flash/actionscripting). Therefore it will most likely not exist in your library. In my opinion early prototyping should be about interaction and feel. Looks either come in later or when the lifespan/target audience of the prototype or the budget of the project warrants it.
I'd agree with the value of spiking. I guess UI libraries / pattern libraries such as YUI and jQuery UI in some ways have been emerging to make it easier to start off projects and prototype as opposed to reinventing the wheel. I wonder if the barrier to these libraries (both pulling and pushing ideas) could be lowered as part of the design tool used.