It’s hard to say that an wireframe is wrong. There’s no right way to do wireframes, so why should there be a wrong way?
However, there are ways in which wireframing can go (terribly) wrong. And I’m going to list the top 10 why reasons that happens. Bottom up! There will be two sets of reasons: too much of something, and not enough of something else.
10. Too much time spent on wireframes
Remember, as it’s often forgotten. Wireframes are not the final design. They will not go into production. Nothing will actually be used in real product development. And that’s a good thing for many reasons. But for one reason, you shouldn’t spend too much time on wireframes. How much time is too much? Well, that depends on you. If you have a day to put a bunch of screens together, then spend a day. If you have an hour, do it for one hour. But don’t push other things because you still have to work on the wireframes. It’s just not worth the extra effort.
9. Too many (similar) screen mockups
Again, this is not development we’re talking about here. If two screens have pretty much the same sort of features, then why prototyping them both? One is enough. If you have smart developers working with you, then they will get the idea. It’s better to detail one screen a little bit more, then to have two screens roughly sketched up.
8. Too many possible future features
Start simple. Really, really, dead simple. There is always the first brick. Then, only, comes the second one. And the third, and so forth. Deadlines will force you to throw things out before they actually get fully implemented. Sometimes even before that. Then you’ll have to mess up your designs because now parts of it are gone. And things start to fall apart.
It’s easier to put things in as you really, really need it, than to take things out when the remaining parts are not ready to fill in the empty spaces.
7. Too many details, too low, too deep
You don’t have time now to set in stone the exact layout, the exact sizes, the exact font sizes, colors, and every other tiny details. It just doesn’t matter how much data you want to collect for users on sign-up. Future is always uncertain. Things will always change.
Wireframe for change and for the future. The best designs are those that can adapt to change and not those that try to prevent it.
6. Too much talk
Wireframes are a great mean to improve and help communication. But there’s a limit. They help you get a better idea of how that UI might look like once implemented, but not how it will look like. Make the distinction. Save some conversation for later, when you and your team will be in front of a screen that’s closer to reality.
5. You don’t think it through
Wireframes are supposed to be fast. But. That doesn’t mean that you should just start throwing stuff on the canvas just because. If something works for Google, it will not necessarily work for your intranet corporate website. Social sharing buttons make sense when they do.
Of course, wireframes make it obvious that something is not right. That’s the whole point. The faster, the better. But still, it’s so easy to put things in a wireframe just because you can, although you probably shouldn’t. Wireframes are a tool. In the end, it’s still up to you to decide what’s best.
4. Too few people involved
What’s the point of flashing ideas on paper if you don’t show anything to anyone. Sometimes, someone will spot an out-of-place something just with a throw of an eye. Does it hurt to ask for feedback? Most certainly not.
3. Too little, too early
Just as too much, too late, this too can get you off track. At least it’s early enough so you can get back on track right away. But don’t think that scribbling something on a wall is wireframing. It’s a start, but it’s just as fuzzy as your thoughts. It doesn’t help communicating ideas, and it doesn’t help building them either.
Things will start to make sense as they come together in a coherent, specific, thought-through manner. It may take hourse or days, depending on the complexity of the task at hand. Take you time.
2. Too few explanations
Don’t expect people to just get your wireframes. The point here is to create software that doesn’t need too much explanations. But in that process, you will start with screens that require explanations. Why did you put navigation there? Why did you choose this screen-flow? Why did you split that form on two screens?
Questions like these require your assistance. It’s best to offer it.
1. Throwing the wireframes into the wild
This is by far the biggest mistake. And it follows naturally from the previous one.
It’s not a piece of art. You’re not Picasso. Your wireframes don’t have a life of their own. They will be forgotten. They are orphans without you. They are tools and extensions of your brain. That’s why they need your presence for when people will need answers. Because wireframes, more often than not, create lots and lots of questions. And that’s a measure of their success and utility. To drive the conversation forward.
That’s when they are really fruitful. And that’s when they need their gardner around.
So, do you subscribe to any of these points? Do you find them problematic? Is there anything else that you know UX designers do wrong when wireframing? I’d love to hear your opinion.
