Designing Wireframes – How Much Detail is Enough?
One of the recurring issues I seem to encounter just about every time we’re creating wireframes for a new client or internal stakeholder is determining how much detail to include. In these situations, I’ve always had to fight the urge to put in too much detail and/or polish in order to make a better impression. In the past this tendency has bitten me more often that I’d care to recount, so now I go out of my way to avoid it. Why is the urge to deliver more finished artifacts early in the design cycle generally a bad idea?
The reason is that most people typically have a very strong inclination to get caught up in the details, including design look and feel rather than concentrating on things like functionality, workflow, information architecture, usability and placement. Virtually every time I’ve gone to the trouble to throw in a little color or some styling, the conversation invariably turns to discussions about irrelevant stuff like font choices, drop shadows, reflections, and round corners versus square etc. It seems that once the conversation has fixated on this kind of topic, the really relevant material is lost. It just seems a fact of human nature and believe me, it doesn’t just stop at wireframes and diagrams; it permeates so many other client/designer interactions as well.
So what is the solution? The easy answer is to resist the temptation to make early conceptual work slick or polished and go with some variation on the old “napkin technique”. By that I mean showing initial ideas in a state that looks like something you might have drawn on a table napkin during a lunch discussion. Make the early drafts purposefully rough and make sure you warn the stakeholder what you are doing. That way they won’t feel nervous about the quality of the finished design they’ll be getting and can concentrate on more salient items. It’s mostly a matter of managing expectations effectively.
Let me also clarify here, that I am not talking about designs for RFPs or other mechanisms intended to sell a prospective client, stakeholder or agency on an concept or campaign. There are times like these where it is in everyone’s best interest to produce something beautiful and more polished. If your Account Team is trying to close business, then only supplying them with rough wireframes and diagrams is virtually guaranteed to ensure failure. In these cases you need to provide examples where people can more easily envision what the final product might be like. This is especially critical with new relationships where the customer may be more literal in their interpretation of your design capabilities. Make them feel more comfortable that any final product is going to be a great user experience. Don’t make their imaginations work overtime in these circumstances. In these cases I would also make clear that the final design and functionality are going to evolve and change. Managing expectations is important.
In circumstances where you are creating wireframes and diagrams that have more practical function as in during the actual Software Development Lifecycle (SDLC), then producing wonderfully beautiful and polished artwork early is likely going to bite you. For these cases, you’ll make faster progress and better convey functionality through much simpler and cruder imagery. There are a few pretty easy methods and tools for accomplishing this including scanning sketches, photographing whiteboard diagrams and software like Balsamiq etc. I will cover some software tools for Wireframing in another post, but it’s possible to make rough low fidelity wireframes and diagrams in virtually any program you’re most comfortable with.