I have noticed an increasing number of conversations taking place within the UX community questioning the relevance of wireframes to the development process. The primary concern seems to arise from situations where clients who have signed off on wireframes then reverse their position, demanding change, when presented with a visual mock-up where the only difference is that visual design has been applied to the wireframe.
These experiences are leading some to question the ability of stakeholders and key decision-makers to differentiate between wireframes and visual mock-ups. As a result, they are ditching the wireframe in favour of jumping straight into creating a visual mock-up to avoid potential headaches and save time and effort.
Here at U1, we have not experienced these sorts of problems. At least not yet! We don’t ascribe this to any special innate qualities of our clients, although they are all marvellous, or the wireframes that we create, which are also marvellous. Rather, we feel the difference may lay in the way in which we position wireframes and explain their role in the development process and how they differ from a visual mock-up.
For us, wireframes are intended to represent where content and functionality will sit within a page independent of branding and look and feel, but importantly they also represent the interactions that are possible. To this end, we will always create wireframes using tools such as Axure which allows us to build interactivity into the wireframes. Inserting this interactivity requires minimal additional effort and allows clients to view the wireframes in the same context (i.e. a web browser) that their users will experience the final site. It also assists with their understanding of how the proposed page layout (i.e. where content and functionality sits) will influence the user experience.
The additional benefit of creating interactive wireframes is that it then allows for some user research to take place in order to validate the wireframes. Whether the user research is ad-hoc or more formal, it provides a rationale for minimising the changes made to page layout once the project moves into the visual design stage.