In order of vagueness-to-precision, the requirements for a Proof-of-Concept are the least defined, and a full system implementation is completely specified. Understanding where your project lies in this spectrum will help you gauge how much effort you need to put into non-coding activities and help manage your expectations when receiving deliverables.

Proof-of-Concept

Commonly known as a PoC, proof-of-concept work should determine if a given approach is appropriate or to find out if integration between two systems makes sense from a technical point-of-view. It can also be used to uncover deficiencies in the architecture or the system design. It's often used as a non-committal way of exploring the capabilities of a system and as such usually lacks unit tests, non-functional criteria, documentation, strict design constraints, visual design, and other aspects required for the creation of a reliable usable system.

Often the PoC work will really be a prototype and not intended to prove that something works. The only thing that should be carried forward from a PoC is library code and tools created to assist in creating these libraries such as code generation tools.

PoC code should usually be discarded at the end.

Prototypes

Prototyping is often used as a mechanism for discovery and quite rightly so. It's use implies that the solution is known but the form it will take is subject to too many uncertainties that the only realistic way forward is to create something with limited functionality to show the way forward.

Very often the prototype will form the bulk of the groundwork for the finished product. Many might argue that this shouldn't happen but in the real world the work done is often too valuable. This is true if the prototype is successful and covers all the needs of the problem at hand. It's also true when the prototype is an extension of an existing product or an implementation using a specific platform where the limitations of the prototype are in fact the constraints of the underlying technology.

Prototypes should be built in the same way as production code, but with less constraints on the developer. They need the freedom to hack and create in the fastest possible way, and yet still create all the secondary outputs that are required such as unit tests, documentation, release notes, correct code styles, and follow the quality assurance guidelines that are in place.

It used to be said that prototypes should be discarded at their end but more often than not they are released as 'beta' products or further developed into complete solutions. Prototypes should be rolled into the final solution if they prove successful.

Implementation

If you already know the majority of the elements of the UI and the solution architecture the most appropriate strategy is to start implementation. This doesn't prevent exploring the technical options for subsections, modules, and components of the system particularly in areas that interface with other systems and for parts of the UI that have been loosely defined.

Obviously final implementation is subject to the most rigorous testing and ratification. It must conform to the requirements but this doesn't preclude that components cannot be developed as prototypes.

Conclusion

If you know a lot, build your solution to a specification and explore the gaps with proof of concept work. If you don't know that something will work, prove it. If you don't know if the parts you intend to use will fit together in a logical way, do a prototype. Don't mix the terminology of prototype and proof-of-concept - one is inherently more rapid to do and is generally unsuitable for production use. Expect to throw a small percentage of prototype code away even if it's successful, and a high percentage of PoC code or face the penalty of adding documentation and unit tests later.