Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

How much detail should you put in your wireframes?

I have been creating a lot lately and I usually end up putting a lot more detail in something that I am handing off to another designer; whereas if I am going to be designing it myself, I always seem to have a lot less. Is this the best way to go about it?

share|improve this question
    
Can you be more specific in your question? You're saying that sometimes you put in more info, sometimes less, but there is no criteria against which we can judge right or wrong here. –  Peter Jan 7 '13 at 21:23
    
More or less detail in what respect? –  Mohit Jan 8 '13 at 4:37
    
You've not asked a well-defined question: you say that you sometimes include more detail and sometimes less, but with no indication of why you do this. Although a 'best' answer has been selected, without any context, this is a pretty meaningless question as it stands. –  Peter Jan 8 '13 at 10:15
add comment

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

4 Answers

up vote 6 down vote accepted

This is a very general question, and deserves a very general answer. (Which is cool.)

You should put as much detail as you need! There's no right answer. In general, stick to the minimum required to move forward. Don't waste your time! Try putting half as much detail in and see if it gets the results you need. You may find that you were wasting a lot more time than you think.

Sort-of a follow-up question: Are you using Photoshop? Photoshop prototypers are notorious for over-detailing. I almost never use Photoshop if I can get the same result from HTML/CSS/Javascript. (37 Signals agrees.) If you can, skip Photoshop. I personally love using Balsamiq. It's fast, easy, and purposefully limited. You can't waste hours over fonts, because you only have 2 to choose from, tops.

To answer your question a bit more, we need to get back to why we're making wireframes / prototypes in the first place: to test things out. If you're just testing out the IA for your site, you probably don't need to spend time adjusting color schemes or edge beveling. But, if you're testing out a radical new visual design, then you may need to put in the time working on those details.

I'm using "test" in a very loose sense here. A full clickthrough HTML prototype in a usability lab and a simple doodle on a napkin are both tools used in testing. It's just a matter of what you're testing and how accurate your results will be. The HTML protoype will give you pretty accurate information about what users will do with something, but it will take a long time to make. Showing someone a napkin sketch will take two seconds, but will give you really general information. (Maybe even miss-information.)

These ideas don't just apply to websites -- you can make a simple / complex prototype for a car, building, service, song, PhD thesis, whatever. Anything man-made has any number of conceptual levels at which it can be represented! Check out the amazing book Understanding Comics. It'll change the way you approach the craft of UX.

Good question.

share|improve this answer
    
It all depends on what the purpose of the wireframes are. If they're for user-journey testing, or initial concept mockups then that's one thing, but if they're for the functional specification that needs stakeholder signoff or need to be handed over to development to implement then that's another. Cater the Wireframes to their purpose. –  JonW Jan 8 '13 at 8:56
add comment

This is a classic where "Less is more" apply:

enter image description here

That said, you need to show the important stuff, highlight important elements and make sure that your white spaces are in order. That is more important than putting everything in IMHO.

The real deal here is to leave out everything not absolutely important for the wireframe in order to make what is important stand out. Not the other way around, trying to cram everything in one singe wireframe.

If you need to, you can have more than one wireframe showing the same view with different elements in different scopes. That way it will be easier for the customer/stakeholder to make desicions based on your wireframes. Result is all that counts when it comes to customer/stakeholders.

share|improve this answer
add comment

Just enough to communicate what you need to communicate and nothing more.

(how much you need to communicate will vary wildly based on the project, the team, the process, etc.)

share|improve this answer
1  
I think this answer sums it up the best. –  kontur Jan 8 '13 at 7:02
add comment

I work at a fast paced start-up where time and resources are scarce. I have been practising what I call MVW (Minimum Viable Wireframe™). Basically, don't apply any more detail than is necessary to convey the direction.

I let the project or task dictate the method. It can be as dirty as a whiteboard collaboration with the developer to solve engineering and use case details. I might take a photo of it and email it. Other levels are a Google presentation doc for flow, or a doc for screen shots with call-outs. These are good for enhancement to existing features. The Google docs are shareable and can be commented on. A top level is a git branch with a working prototype that offers a productionable code that can be merged into the main branch.

My advice is never design more than is necessary to work out the details. User testing or engineering will always flesh out more in the end. I embrace that and allow it to happen.

Anyway, that's my style and it works for me, my team and the product I work on.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.