Do high fidelity wireframes defeat the purpose?

Question

Isn't the purpose of a wireframe to remove fidelity, assisting stakeholders in focusing on structure, architecture, content and general layout instead of the finer details about the graphic design?

I have definitely had early stage meetings derailed due to too much fidelity in a wireframe and the stakeholders get all hung up on exactly which shade of a colour we should be using or how many pixels should be between two elements.

While I do understand there can be some benefits from using high fidelity, doesn't it just create more problems than solutions, especially when used early in a project?

See also Using color in wireframes...is this a "no no"?

Answer 1

Isn't the purpose of a wireframe to remove fidelity, assisting stakeholders in focusing on structure, architecture, content and general layout instead of the finer details about the graphic design?

The purpose of wireframes is to focus on structure, yes. Not necessarily remove fidelity or graphic design. Sometimes those are necessary to talk about structure.

You tagged your question with both wireframe and prototyping. Which is it? They're not the same thing. Wireframes are about structure and prototypes are about experience. Use each in the right place but not interchangeably.

It's up to you to learn when to use which fidelity. Depending on your project's needs and your client, as well as your team, budget, abilities, etc. you should figure out which fidelity works best at which stage of the project. For instance, the app I'm designing right now is a rich experience where the prototype needed to communicate exactly how rich the experience will be early on. So we started in HTML and polished up the visuals quickly in order to communicate that intent. On other projects you may not want to do that, but there's no blanket rule that says you should always go one way or the other.

Answer 2

From a prototype standpoint, I find there to be a spectrum of options:

paper wireframes <--------------------------------------------> working code

How many steps you put in between those two ends of the spectrum depends on a number of things, but tends to be where things can get mired.

I'm a big fan of keeping wireframes as lo-fi as possible. Ideally, they don't even leave the confines of UX...they simply become UX's sketchpad. From there, the team begins designing in code as soon as possible. It doesn't have to be production code, but once you get it into the actual medium it will be used in, you're well over halfway there.

It's the stuff in the middle where it looks closer to final--but isn't--and it feels like it is clickable--but truly isn't--is where I think a lot of wrong turns can be made.

Answer 3

I have a different interpretation of HiFi and LoFi wireframes. I use Low fidelity wireframes purely for layout and high-level content positioning, and i go with Hi Fidelity wireframes when we need to be more specific about the content being used.

I more often use a high-fidelity version so that we can be specific and give the design team and developers something more concrete to work to, but without being too prescriptive about how things need to work.

You could go even more hi-fi and add in dimensions, specific content (i.e. not lorem ipsum) all the while still being classified as a Wireframe.

Some quick examples of what I am talking about are:

Low-Fi Wireframe

High-Fi Wireframe

Answer 4

For me, wireframing and prototyping are two separate stages of the design (i.e. pre-coding) process - agree with Rahul; they're not the same thing.

We try to keep any initial conversations to wireframes - simply ensuring we have the core information architecture of a page/application right. Keeping wireframes lo-fidelity makes shifting, resizing, adding and removing elements, etc. all quick and simple.

Once we reach agreement with clients on those aspects, we can begin to add logic and functionality to give a representation of the interaction - this is where the prototypes and increased fidelity comes in.

This would be our approach in an ideal world. It is, as you know, very rare for projects to sit in an ideal world. Sometimes, you'll meet clients who'll be very experience driven and simply won't get lo-fi wireframes - they'll need colour, imagery, functionality and sample content to really get their heads round what you're going to deliver. Alternatively, you'll get clients who will totally get the wireframes and will have a set of requirements which are fine-grained and detailed enough for you to construct without additional time/effort of prototyping.

You need to have the skills to do both, but what you spend your time on and how much detail you go into will be governed by your type of client and commercials.

Answer 5

Generally speaking wire-framing is the low cost quick way to put ideas on paper to enable discussion, review, and further improvement.

Early stage wire-frames will be low-fidelity both to get started more quickly and receive feedback early on without investing too much time. In these early stages you might also focus more on the sequence of events, i.e. how will a user transition from one state to another.

As the early wire-frames gain traction and approval you start fleshing them out with slightly more detail, probable keywords and so on.

So I see wire-framing moving from lo-fi to hi-fi as the iterations progress.

The next stage would be prototyping, and once again different levels of prototypes can be created from the static to the faked behaviour using some javascript.

It all depends on the project complexity and the way meetings and approval proceed.

Answer 6

Personally, I feel wireframes should be anywhere from a paper sketch to a full blown graphic representation (w/o any functionality), and used based on where in the lifecycle you are. If the site is just in a head, start with a paper sketch. If the site has been out for years and you are only making feature adjustments, maybe it's wireframing from a current screenshot. The decision should be based on what the goals are of using the wireframe.