Some things can’t be wireframed(insideintercom.io)
insideintercom.io
Some things can’t be wireframed
http://insideintercom.io/things-cant-wireframed/
18 comments
My quick summary:
1) Bad example of a detail-poor wireframe that actually could have been good with actual content text and more precision.
2) Explanation that wireframe leads the design direction and sets its own limits of creativity. They constrain your execution to well-known paradigms and restricts innovation.
3) A vague point about alternative methods of user interaction that can't be wireframed and one must leave the comfort zone of traditional UX.
Ironically, the whole post seems to be a retrospective reflection on how Intercom.io COULD have developed their own product, but chose not to. https://www.intercom.io/ is a direct example of wireframe-driven design that fits into the same boxes that OP wants to break.
Ironically, the whole post seems to be a retrospective reflection on how Intercom.io COULD have developed their own product, but chose not to. https://www.intercom.io/ is a direct example of wireframe-driven design that fits into the same boxes that OP wants to break.
Amen. The entire idea of having one person wireframe a layout and someone else "design" it is broken.
Designers aren't decorators. Give them a problem to solve instead of boxes to color in.
Designers aren't decorators. Give them a problem to solve instead of boxes to color in.
this is the stupidest post ever.
this post should be called some ideas cant be captured by some wireframing methodologies and tools, who are used by people who are dumb.
I agree with everything said by the author, but I think that mood boards help to fill the gap.
Interesting, I'd love to read a post on how you use Moodboards
Not sure I agree with this. The article compares extremely low-fidelity wireframes with very high fidelity mockups. You don't have to choose between one or the other. Tools like Balsamiq allow you to create mockups that give a better approximation of the real thing with substantially less work.
I'm not saying you shouldn't create high-fidelity mockups, but get the usability problems solved first in a lower-cost environment. That could be as simple as a whiteboarding session or using index cards. You should be excited for a product/site not only based on how it looks, but what it does.
I'm not saying you shouldn't create high-fidelity mockups, but get the usability problems solved first in a lower-cost environment. That could be as simple as a whiteboarding session or using index cards. You should be excited for a product/site not only based on how it looks, but what it does.
Mock ups (high fidelity) should actually precede wire frames and prototypes as a way of promoting a project in its very early stages to stakeholders. They are brainstorming outputs but don't really represent real design output yet, and must be promptly shelved after their internal promotional planning use.
The author is simply confusing interaction and visual design. The former involves wireframing, the latter almost always does not.
The author is simply confusing interaction and visual design. The former involves wireframing, the latter almost always does not.
Hey Netfire,
My point isn't about low-fi wireframes. (here's a slightly more complete version of the same wireframe: http://d.pr/i/N6Oo )
My point is that wireframes as a starting piece aren't always correct, and that if you do use them, it'll put you down a certain path, and that path isn't always correct.
My point isn't about low-fi wireframes. (here's a slightly more complete version of the same wireframe: http://d.pr/i/N6Oo )
My point is that wireframes as a starting piece aren't always correct, and that if you do use them, it'll put you down a certain path, and that path isn't always correct.
Wireframes are maps, not models.
Author doesn't seem to know what a wire frame is. And doesn't seem to have any concept of how UI/UX should be done.
Wireframes are typically used for determining how much of each screen something will take up. After that you move to a Mock up.
You don't need to see video play to know that the video is going to be too small if the Logo is 1600x800 on the page.
A wire frame should be more like the pencil sketch or white board image that you use to talk about what is going to where, and to be used as a "map". It doesn't convey what things will really look like as much as give you an idea of where things are and how much real estate they take up.
Think of a wireframe like a relief map. It tells you how tall the hill is, and where the canyon is, not how beautiful it will be or what color. A blue print tells you where the studs in the building will go, but you get a better picture of how the building will look from a little Styrofoam model. They are both important, but they aren't the same thing.
Author doesn't seem to know what a wire frame is. And doesn't seem to have any concept of how UI/UX should be done.
Wireframes are typically used for determining how much of each screen something will take up. After that you move to a Mock up.
You don't need to see video play to know that the video is going to be too small if the Logo is 1600x800 on the page.
A wire frame should be more like the pencil sketch or white board image that you use to talk about what is going to where, and to be used as a "map". It doesn't convey what things will really look like as much as give you an idea of where things are and how much real estate they take up.
Think of a wireframe like a relief map. It tells you how tall the hill is, and where the canyon is, not how beautiful it will be or what color. A blue print tells you where the studs in the building will go, but you get a better picture of how the building will look from a little Styrofoam model. They are both important, but they aren't the same thing.
> Author doesn't seem to know what a wire frame is. And doesn't seem to have any concept of how UI/UX should be done.
Don't be harsh. We all have different ideas of what wireframes are.
> Wireframes are typically used for determining how much of each screen something will take up. After that you move to a Mock up.
I guess web design is a bit different from the more app design field I'm used to, where wireframe is more of an interaction tool used to describe non-visual user experience and flow while the visual toolkit/guide does what the web wireframe would otherwise (not just layout, but everything else visual also). Mockup is mostly used in the early concept and planning stages before design begins in earnest. You move up from wireframe and visual guides to...prototypes.
Don't be harsh. We all have different ideas of what wireframes are.
> Wireframes are typically used for determining how much of each screen something will take up. After that you move to a Mock up.
I guess web design is a bit different from the more app design field I'm used to, where wireframe is more of an interaction tool used to describe non-visual user experience and flow while the visual toolkit/guide does what the web wireframe would otherwise (not just layout, but everything else visual also). Mockup is mostly used in the early concept and planning stages before design begins in earnest. You move up from wireframe and visual guides to...prototypes.
The author's point is that for some projects wireframing may not be appropriate. I've had this experience on numerous occasions where let's say a full-color design comp or an interactive prototype would better serve the concept, which may be hard to grasp otherwise.
This is especially true when taking a design first approach, or when your project gains nothing by illustrating hierarchies, navigation, or other wireframe-able things.
This is especially true when taking a design first approach, or when your project gains nothing by illustrating hierarchies, navigation, or other wireframe-able things.
The author either thinks the readers are either stupid and don't know the difference between a Hammer and a Screwdriver and why you can't drive nails with a screwdriver....
Or the author is stupid and was driving nails with a screwdriver and wrote this post to explain why they changed.
Or the author is stupid and was driving nails with a screwdriver and wrote this post to explain why they changed.
Look, it's great when the person in charge of deciding policies is the same person doing the work, and the same in charge of selling it to whoever must be convinced. But most people work on different environments (yep, even when they own the company), and communicating, even things that appear obvious to one of the parties, is crucial to make right decisions on those other environments.
For example, if you are looking into hiring a designer, if you didn't read the article and makes the obvious decision of asking a wireframe from the biders, you just alienated everybody that could make your site great. That this is obvious for the alienated designers changes absolutely nothing.
For example, if you are looking into hiring a designer, if you didn't read the article and makes the obvious decision of asking a wireframe from the biders, you just alienated everybody that could make your site great. That this is obvious for the alienated designers changes absolutely nothing.
Or Drakaal is a gutless troll who wishes he could write articles that people cared or even talked about. That's also a possibility I guess.
This is a very low-class and frankly foolish way to interact with someone criticizing your work. Even if it's true that drakaal is not a popular content-producer, and even considering he could have phrased his points more respectfully, that's no reason to just blow off his reasoning entirely.
Anyway, here we all are caring and talking about something he wrote.
Anyway, here we all are caring and talking about something he wrote.
I think you will find from my comments on HN, My youtube channel, and my interactions in volunteerism, with political movements, and law enforcement that I may be a Troll. But I'm not gutless.
-Brandon Wirtz
-Brandon Wirtz
Respect.
Wireframes you can click through.