Ah, the fine art of wireframes. Probably the most recognized tool of the User Centered Design process. It's used in a many of today's application and web design projects. There are applications to help you wireframe. Websites about wireframing. Even groups to show off your wireframes. Some wireframes are pencil some are digital. Some are sketchy some are clean. What "wireframe" means goes beyond style these days and it seems to change depending on who you talk to and when you ask them. The clarity or lack therof is not in the drawing but in its purpose. Let's look at wireframing and see what it means to us now.
Wireframes are rough sketches or drawings representing the page layout. The drawing can contain such things as page elements, content inventory, and annotations.
Wireframes are not graphic design and don't have anything to do with visual design. Keep saying that; it might help later.
Back in the Day
The idea of wireframing started out simple enough. It was born from a need to create quick drawings for content placement, hierarchy, and interaction. We used paper and pencil or a white board and the world marveled at how fast our teams could design and develop solid solutions.
The way wireframes are being used today is changing. Time to market is becoming shorter. The kinds of interactions being represented are richer. And honestly there is more buy in from stake holders towards the process of “user centered design”. Visual communication is now at a premium and wireframes seem to be the commodity of choice.
HOW WIREFRAMES ARE USED TODAY
Wireframing, in this sense, is done with zero documentation to work from. This is the documentation ideally created during a work session or two. Wireframing can speed up gathering requirements and improve communication. The main idea is to make drawings that everyone can see and come to an agreement on "what the application needs to be". Great tool for national or global teams.
The deliverable from this is not to be used as a UI wireframe document. During the requirements gathering no one really cares to discuss content relationships and appropriate hierarchy at that level. There should not be time for that. It might, however, be a great start to the next conversation.
Information and Interaction design
This is the traditional process and deliverable that has been attached to the word "wireframe" for so many years. Based on documented requirements, client input and whatever else the UX practitioner is handed and expected to make UI magic from. This is a road map for the user interface and interaction design to be reviewed by the clients stake holders, SMEs, as well as, Technical Leads and even Graphic Designers. Still a very rough set of drawings built for rapid iteration and constant feedback it’s a good idea to make expectations clear that this is not visual design, but the information design.
This purpose to me is the most laborious. The level of detail here is not what was intended when wireframes first became a thing. However it does cut to the chase for the guys in the trenches. This drawing is a blueprint pure and simple. The level of detail here is down to the user control and the line length of the text. It makes my head hurt writing this paragraph.
EFFECTS OF PROCESS
Traditionally this process allows for more time between deliverables so the drawings can be more detailed, but the danger here is… well the drawings can be more detailed.
It's important to set expectations on effort and purpose of the drawings. As the project moves from stage to stage if the intent of wireframing becomes blurry things can get messy.
The quick iterations between reviews I think plays into the strengths of wireframes. The one huge caveat being the really detailed blue print for the developers. It can be problematic making the deadlines with that much detail. The UX practitioner needs to know his/her technical stuff and perhaps even rapid prototyping is more useful than wireframes once some of the more high level questions are answered.
HOW SHAREPOINT ADDS A WRINKLE
Unlike most custom applications, with SharePoint the casual user will likely have some ability to edit the site in some way. Wireframes can be used to help define areas of interaction and who can do what. Also, each web part is its own little peice of business logic and wireframes can help decide which ones can be used and what explain what it is they do.
When creating a site or application with SharePoint administration and content management functions are part and parcel with the framework. Wireframes can help make clear what that experience will look like.
At the end of the day
It’s all visual communication and wireframes still look like ugly drawings of web pages, but the difference is the intent of the drawing and the audience that will digest it.