Wireframes: how many details are needed?

Recently a colleague of mine asked me about the difference between a wireframe and prototype. Which got me thinking: how would I call most of my deliverables? where do I draw the line – and how detailed does a wireframe really need to be?

The terms are often used interchangeable, but there is a difference between a wireframe and a prototype:


  • static
  • no visuals
  • skeletal structure
  • focus on the WHAT


  • shows a sequence
  • interactive (most often)
  • representation of the final product and its behaviour
  • focus on the HOW

There are lot of articles where you can find a more detailed description about the difference:

Wireframes & Prototypes: Is There Really a Difference?

Why We Prototype Vs Wireframe


But why do we use wireframes?

  • Wireframes support the communication within an interdisciplinary team: the visual designer is being informed about the type of information that he needs to care about, the developer gets an understanding about the interactivity.
  • Wireframes offers a first visualization and supports the communication with the client: it’s easier to talk about a visual draft than about a vague idea that is only described with words.
  • Wireframes can be used for testing to get feedback in early stages of the development process.

That’s the theory so far. But how doesn’t know the situation: you presented the wireframes to the client and they got signed off; you seemed to have a common understanding. Until the client sees the final design layout  and all of a sudden a black & white wireframe gets a “face” and feels different…

And handed your wireframes over to the visual designer and the front-end developer. As the wireframe won’t define all the details there is still a lot of room for interpretation…

You use your wireframe in a usability test. The test participant comments on the stumbling interactions; you know that the interactions are depending on your wireframe tool and you know the real product will feel different…

Sergio Nouvel summarized his opinion about that exact problem:

Ditch traditional wireframe

In his opinion, wireframes are:

  • difficult to test, therefore not really helpful
  • not time-efficient as the interactions are only replicates of HTML/ CSS
  • not responsive, you need to build several wireframes for different sizes

Which are good reasons to start designing wireframes in the browser.

I agree we should start earlier with HTML/ CSS, but we still need to have a concept first, be sure that we understand the real problems and define the best solutions to it before we start designing.

I have the feeling that this discussion easily interferes with a feeling of “ownership”. Who should be responsible for the wireframe, who should be in charge to define the interactions?

In my opinion we should stop to think about “ownership” and think more about collaboration: developing a usable and enjoyable product is the result of having people with different skills and know-how working together.

I still think that wireframes will have a lot of value – but we should go back to simplicity: use wireframes to define the structure of content and to define the sequences. But focus on its main purpose: simplification of communication. Don’t get lost in details – use annotations and link to existing examples to define the interactions or the “feeling” that you want your product to transport.


About the author

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.