Wireframes Up For Disucssionby Emily
Trying to describe my job title "UX Design" to friends & family members often ends in blank stares, numerous questions and ultimately total confusion. I've somewhat given up all hope for that one and have settled on "I organize websites" or "I make things look pretty." Which is not really true but we'll deal with that another day.
Turns out, even among designers there has yet to be a convention for how wireframes can and should work.
Wireframes do not have a formula
Wireframes (a key part of UX design) are the beginning framework for apps and websites. It's the research that goes into all of the information on the page - where buttons are located, how many buttons there are, what flow people are taken through, what forms are needed, etc. It gives the client a brief overview of what their final product will look like.
That said, there is no right way to create them. There's no set formula, textbook or website you can go to in order to find an "official wireframing rulebook."
Does this create problems? Yes. But it's also quite fantastic.
There seem to be three "levels" of wireframes: basic sketches (just getting the very bare bones of an idea out onto paper), low-fidelity ones which are good for testing how a project will flow and the high fidelity wireframes that are much more detailed and thought out including content.
Sometimes including small icons or faded imagery can help to better tell a story. Adding a little copy can give an indication as to how a user will be prompted to continue. It can help to know how long a chunk of text will be in order to allot for scroll bars and next buttons.
And when it comes down to detail, I'm still learning where the line is between not enough and too much.
Where wireframes stop and content starts
After getting the initial brief from a client, wireframes are started. They digest the ask and start determining the layout of the information. Is this a game that people will play? Just a simple form? Wireframes at this point also help to determine the required technology - does this best live on Facebook? Should there be a mobile component?
But the question is, where does wireframing stop and design & copywriting start?!
In the example above, do you have any idea what this app is about? Or what the buttons are asking you to do?
So often in creating wireframes, I find myself wanting to start copywriting (momentarily forgetting the fact that I am not one). The content of the project is so key to a user being able to flow through and understand what is going on. Content aids a user in determining their next action and deciphering what a site is about. It's important right down to the one word buttons (submit, send, share, continue, etc.). But it can also trip a client up. If copy is put in by someone other than a copywriter it often causes more trouble than good by causing them to concentrate on the wording of something rather than the layout or functionality of a website.
With the example above, we solved this issue by NOT writing the copy and instead using the "a" indicator to explain the functionality on the side of the design. Notes on the side of wireframes are a huge help in being able to describe what something does. We were able to describe what the pop up would ask without actually writing the copy ourselves. The client understands what happens, how it will be laid out and how the copy will guide the user. In this approach, it's then passed off to a designer to give it the look and feel and finally given to the copywriter as the icing on the cake.
Ideally these three (UX, Design and Copywriting) would work together from the beginning. There are standard conventions for button size on mobile to keep in mind as well as text length that determines the need for a scroll bar and specifications for design assets that need room to breathe. Clearly, having too many people associated with all parts of the process could result in a "too many cooks in the kitchen" scenario but it could also prove to be helpful.
I'm not really proposing any huge changes or even pretend to know the end all be all answer to what a wireframe should be, but I'm interested in looking further into it.