I love prototyping as a fast effective way to put a UI in front of a user.
Many times though, management get their beaks in the way, and the prototype is dragged kicking and screaming into main stream development.
How do you manage management into not doing this?
Use a tool like Microsoft SketchFlow, or make your prototype in some other language or platform, making it nearly impossible to integrate into main development.
There's also a joelonsoftware essay about showing screenshots and prototypes, where he makes unimplemented and unworked aspects appear obviously broken/unimplemented, making it clear where work still needs to be done.
Important Corollary Two. If you show a nonprogrammer a screen which has a user interface which is 100% beautiful, they will think the program is almost done.
...
What can you do about this? Once you understand the Iceberg Secret, it's easy to work with it. Understand that any demos you do in a darkened room with a projector are going to be all about pixels. If you can, build your UI in such a way that unfinished parts look unfinished. For example, use scrawls for the icons on the toolbar until the functionality is there. As you're building your web service, you may want to consider actually leaving out features from the home page until those features are built. That way people can watch the home page go from 3 commands to 20 commands as more things get built.
So, try making your prototypes in Photoshop instead of Visual Studio, or something along those lines.
Don't prototype with working code. Prototype with pencil and paper, or a software equivalent.
Using Mockups feels like drawing, but because it’s digital, you can tweak and rearrange easily. Teams can come up with a design and iterate over it in real-time in the course of a meeting.
Using paper has the benefit that team members can easily jump in, and everyone understands it's just a blank sheet of paper. This makes it seem less precious.
Never compromise the quality of your code.
Writing junk code is a false economy.
As other posters have suggested you can achieve this by using specific tools for mock ups.
However, there are different reasons to building prototypes. Sometimes you can show what you need to without writing code, but often this is not the case. A stakeholder might want you to demonstrate the technical feasibility of a feature.
Build the absolute leanest thing you can to demonstrate the feature/prove the concept. Leave out anything else.
For a UI feature, make sure you don't develop anything on the server - dont touch it at all. Develop again mocks/fakes built in.
If you need to put effort into making the UI conform to the style of the rest of the application dont bother. If it looks good enough without any effort then change the colours to make it stand out, or maybe even a watermark to show that it is a prototype.
I've found the most likely offenders of causing prototypes to turn into production code are sales people. They will sell your product to new customer - without this new feature, the client would not have signed. You can't blame them, they have targets. Be careful with them; make sure they don't make you take out the things that indicate that it is a prototype. You have to stand your ground - they probably should not be misleading customers anyway.
Your management may start to force you to do turn a prototype into production code piece by piece, if you followed my first piece of advice never to write crappy code, there you should be no problem. Gradually, you build up the software, without compromise.
Then if management start to force you to reduce quality you have to ask yourself why. Are they passive? weak? desperate? None of those things are good reasons to stick around at a company.
Pretty simple really. Tell them that they would end up losing their favorite client if they end up putting this buggy mess for show.
And yeah, ask them to take their chances if they really know better.
Finally: Please don't say the prototype has specific bugs A, B and C. Then you'd be made to fix that bug, and management will claim they channelized energy into making software production ready.
Chances are with those performance bonuses and future stock grants these days, they will listen.
Sidestep the problem in the first place. DON'T FINISH IT. By that I mean don't make it look pretty or like it's a fit with existing styles on the site. The goal is simply to get the most crude working version of it possible so you can see that the very basic UI flow works. If you throw existing site style on it or overly polish it, they're going to assume you can just "plug it in." Management is like Pakleds from Star Trek. They just want you to "make it go." The more ready you make it seem, the more ready they're going to think it is.
If that doesn't solve your problem, get a job at at least one company with a well-known brand name for a year. Put your email and number on an online resume and you will be fighting recruiters back with a stick, which will enable you to say to them "absolutely not" with the confidence of a dev who knows what they are doing and can get a new job tomorrow where hopefully your expertise on the matter is taken more seriously.
I'm currently working on a codebase that has not two but a triple-stack-whammy of Rails, .NET and Java. The reason we got the Rails tacked on was because a prototype was done in Rails and the top dog at the company said "make it go." We need to say no sometimes. As long as we're not doing it all the time they should take us seriously.
But yeah, whatever you do with a prototype, make sure it starts out real ugly.
If you sit down and throw UI controls for a "prototype", there is exactly zero reason you should ever automatically throw away that design. If it was good enough to show management, then it's a good place to start when to code the "real" program.
Moving from a prototype to a more "polished" UI should be nothing more than a series of entirely justifiable steps. You had to add a second button. You got feedback from users that they found the order confusing. Your organization's standards group dictated a minor change. You had to change the size of a text box for internationalization.
Not a single one of those reasons is "well, it was just a prototype." In UI design or in code or in writing, ANYTHING can wind up living forever. And those that don't all should have very good reasons to kill them.
Realistically, if the reason you didn't just drop in your UI to the existing code was "I had to re-write it in our correct framework", that should be enough of a reason. And if it wasn't, you should probably have a discussion about the UI framework itself, but that's another question.
I used to have this problem, until, I realized it wasn't a problem but a way of liberating myself from the rather outdated development standards imposed on most shops.
So you tell your management you are writing a prototype, you pick the technologies that work best for you, for this problem area, and you then write the software in the full knowledge that it will go in to production.
You escape the tedium of "applications must be in java 1.6 using Web(insert expensive J2EE engine of managements choice)" and pointless naming standards etc.
My current prototype languages of choice are "php" (which totally scales to heavy duty production environments -- just ask Facebook) and the very elegant combination of Groovy/Java with either Tomcat or Jetty.
The groovy/java combination is great for rapid development. Groovy is nice to use quick to develop but performs like a geriatric snail, however it is trivially easy to re-factor performance critical sections in to pure Java. Wedding the application to Tomcat or Jetty means never having to deal with EJBs and other J2EE horrors again.
The main advantage of having a working prototype as opposed to a sketch as proposed by several posters is user feedback. Prototypes are a great way of getting the business truly involved in the design. Once they realize they can say things like "shouldn't that field be on the main screen" and hey presto! there it is on the main screen at the next demo they open up and get involved in the design bringing years of valuable business experience to the project.
