The function of wireframes can often be difficult to describe to clients, especially those who are unfamiliar with design terminology. Often UX designers must explain the purpose of wireframes to ensure that they get adequate feedback from stakeholders on whether their requirements have been met in the outline they have created. For years UX designers have used the analogy of wireframes acting as blueprints for a project, but is this really the right approach? Is this a term that clients will understand, or could this lead to further confusion?
Blueprints have been used in architecture for hundreds of years and are still in use today. In architecture these are technical drawings which show the layout of a building, sometimes including how it should look from different viewpoints. Blueprints are usually handed over to technical specialist so that construction can begin, but with software design, wireframes are not always the basis for a final specification.
Many designers sketch wireframes on paper, which are by no means accurate technical drawings. Instead these are used to incorporate user research and stakeholder requirements into one design. While wireframes can be created to show exactly where each component should go, there are other functions that can be incorporated depending on the fidelity of the wireframe. Ultimately it doesn’t matter which analogy you use to describe wireframes to your clients. The most important thing is that they understand what stage of development you are at and how final the wireframes are. Make it clear to them if you are still interested in their feedback that wireframes are just a draft and they will more readily make suggestions of how to improve the design.