Wireframing, Prototyping, Mockuping – What’s the Difference?

Introduction

I’m very happy to welcome you all to the first part of this online course on wireframing and creating design documentation. I hope you’ll all have fun and learn useful, applicable techniques that will make your everyday work life much easier.

I’m Marcin Treder and I currently serve as CEO of the popular User Experience Design Application – UXPin, but I’m also a seasoned User Experience Designer and a manager of User Experience teams.

SEE ALSO: Hot User Input Design Patterns for Mobile

In a series of 7 articles I’ll discuss, in detail, methods of wireframing and, in general, creating design documentation. I’ll guide you through tips and tricks that helped me in my practice and I sincerely hope you avoid some of my painful mistakes.

Articles are meant to be highly practical so expect just a little bit of design philosophy and a lot of real life stories.

All the examples of design documentation are created in UXPin – the first ever User Experience Design application.

Are you looking for responsive website templates and online website builder?

Get Startup Design Framework now!

Use coupon code START50 for 50% off!

Sign up to UXPin for free (14-day trial) to keep up with my examples.

Wireframe, prototype, mockup – what’s the difference?

A couple of years ago I realised that a lot of my IT, non-designer, friends were using the names of my beloved design deliverables synonymously. They assumed that a wireframe, prototype and mockup are exactly the same thing – a kind of greyish, boxy, sketch representing an ingenious idea.

The problem with their simplified view is that they never know what to expect from the work of User Experience designers and they often get confused. ”Why the hell is this not clickable?”, ”Well, I didn’t know that I was supposed to click here…” – these kind of comments are annoyingly common in UX design projects.

Confusing wireframes with prototypes is like assuming that an architectural blueprint (a detailed plan of a building-to-be) and a display house, are the same thing.

Though you may certainly try to live in a display house (you know – its beauty is supposed to demonstrate how cool other houses in the area are), you can’t count on a comfortable stay in a blueprint – it’s just a sheet of paper.

A display house and a blueprint are different means of communication in architecture:

-  a blueprint serves as a building plan and should specify how the building should be built

-  a display house provides a test drive for future residents

The same differentiation can be applied to wireframes, prototypes and mockups. They  look different, they communicate something different and they serve different purposes.

A display house and blueprint do have something in common though – they both represent the final product – actual house. And again exactly the same common trait can be applied to wireframes, prototypes and mockups – all these documents are forms of representation of the final product.

Believe it or not, the difference between a prototype, wireframe and mockup was always one of the first things I tried to teach members of my User Experience Design team.

Yes, it’s really that important.

Let’s discuss wireframes, prototypes and mockups in detail, so you’ll grasp the idea of what to use in specific situations.

Wireframe

1. What is a wireframe?

A wireframe is a low fidelity representation of a design. It should clearly show:

- the main groups of content (what?)

- the structure of information (where?)

- a description and basic visualisation of the user – interface interaction (how?)

Wireframes are not just meaningless sets of grey boxes, though they may look exactly like that. Consider them as the backbone of your design and remember that wireframes should contain a representation of every important piece of the final product.

UXPin

„Representation” is a crucial term here, which will help you find the right fidelity – speed balance. You can’t go into too many details, but on the other hand you need to create a solid representation of the final design that won’t miss out any important piece of it. You’re setting a path for the whole project and for the people that are working with you (developers, visual designers, copy writers, project managers – they all need well-created wireframes). In fact you’re creating a map of a city. Every street is represented on a map, but it’s vastly simplified. You can sense the architecture of the city if you look on a map, but you can’t perceive its beauty.

Wireframes should be created quickly and almost the whole time should be spent communicating with team members and…thinking. The mere activity of wireframe-creation should be really quick.

Visualisation should be aesthetic, but this is vastly simplified. Black-grey-white are the typical colours you’ll use (you may add blue to specify links).

If something takes too much time to prepare (e.g. choice of icons, uploading images), you have to represent it in a simplified way (e.g. using placeholders – crossed rectangles for images, plus an appropriate description). We tend to call wireframes low-fidelity deliverables (lo-fi).

Remember – a well-created wireframe communicates design in a crystal clear way and sets a path for the whole team.

2. When to use wireframes.

Wireframes are typically used as the documentation of the project. Since they are static and fix interaction with an interface at a specific point in time, they should be accompanied by the written word (from short notes explaining interaction to, when needed, complex technical documentation).

However they might be also used in a less formal way. Since they are quick and simple in form, they serve well as clear sketches for inner communication in the team. If developers ask how something should be done – the answer can be provided as a rapidly created wireframe.

Consider this: UXPin is a start-up with really rapid development cycles (releases every couple of days). We use wireframes to quickly visualise tasks (even small ones!). It eliminates misunderstandings and is really cheap.

Wireframes are hardly used as a testing material, although they may help to gather feedback in initial, guerrilla-style, research, in which you don’t care about methodological purity, but rather try to get some quick insights.

Wireframes placed in the context of the whole design story can be surprisingly effective and, though in recent years they’ve received some bad press, are still indispensable as an initial stage of complex projects.

Prototype

 1. What is a prototype?

A prototype, often confused with a wireframe, is a middle to high fidelity representation of the final product, which simulates user interface interaction. It should allow the user to:

-  experience content and interactions with the interface

-  test the main interactions in a way similar to the final product

A prototype is a simulation of the final interaction between the user and the interface. It might not look exactly like the final product, but should be vastly similar (it’s definitely not a greyish, sketchy thing). Interactions should be modelled with care and have a significant resemblance to the final experience. Interdependence between the interface and backend mechanisms is often omitted to reduce costs and speed up development cycles.

2. When to use a prototype.

When to use a prototype

Prototypes are used to their full potential in user testing. Such a simulation of the final interactions forms great material to check the usability of the interface, before the development actually begins.

Prototypes usually aren’t the best documentation you can imagine, since they force the „reader” to take some effort to understand the interface. On the other hand, a prototype is the most engaging form of design documentation as the interface is tangible and straightforward.

Beware that prototyping is rather an expensive and time-consuming form of design communication. I’d suggest rather creating prototypes that can be reused in development (yep, it means that you need to code some HTML, CSS and probably IS on your own). It’s especially effective in relatively simple projects.

Done right and combined with user testing, prototyping can pay for itself.

Mockup (mock-up)

1. What is a mockup?

A mockup is a middle to high fidelity, static, design representation. Very often a mockup is a visual design draft, or even the actual visual design. A well created mockup:

-  represents the structure of information, visualises the content and demonstrates the basic functionalities in a static way

-  encourages people to actually review the visual side of the project

Mockups are often confused with wireframes, due to the names of some software companies.

2. When to use a mockup.

When to use a mockup

Mockups are particularly useful if you want to get early buy-in from a stakeholder. Thanks to their visual nature, mockups don’t have the resistance of the low fidelity deliverables and are much quicker to create than prototypes. They are a good feedback-gatherer and, if placed in the context of the whole design story, can form a great chapter of documentation.

Sum-up

Table

Where to start?

Before you choose a means of communication in the design process you need to:

-  specify the problem that you’re trying to solve

-  get to know your target group

-  have a look at what competitors have done in this area

-  set overall product requirements

That’s a minimum. Now think which deliverable will be most appropriate for you. Consider your product and team. What will work best for all of you? Formalised documentation, or informal quick sketches and face-to-face discussions? Do you have time and money for solid user research, or are you just going to visit a local cafe and hand a couple of sketches to your prospects?

What skills do you posses? Can you code?

Having a look at yourself, your team and your project should guide you through the process of choosing the right deliverable.

You can, of course, create all of them and…in many cases you will! Don’t be afraid of taking this step. They all make sense and, done right, can bring you closer to great design.

In this particular course, we’ll focus on the creation of low fidelity deliverables and on creating consistent design documentation based on them.

The next article will teach you how to create a wireframe efficiently by concentrating on the context of the design story and spartan aesthetics.

Sign up on UXPin to start creating design documentation today!

Marcin Treder is a design enthusiast who literally lives for creating best user experience possible. After years working as UX Designer and UX Manager he focused on his own startup UXPin - The UX Design App, that provides tools for UX Designers all over the world and was recently voted the best startup in Central and Eastern Europe. You can follow him on Google+.

Newsletter

21 Comments
  1. arsado Jul 24, 6:47 pm

    Thanks, great article for those, who aren’t familiar with UX terminology.
    I am glad that there are more and more great tools for UX designers popping up everyday. But I still prefer invisionapp, much polished and usable tool, that allows combining “wireframes” and “prototypes”.
    keep going.

    Reply
    +2
    • Stéphane Jul 28, 8:24 am

      Thanks for the tip about invisionapp, i’m trying it right now. It can be THE solution i’m looking for with my clients, especially to have good answers and validate the mockup and the prototype in the same interface.

      Reply
      0
  2. webdesdev Jul 24, 9:09 pm

    A very nice article, I knew the meanings and creation of these but your Insight view to explain things clearly to everyone is well appreciated.

    Reply
    0
  3. Marcin Treder Jul 24, 9:15 pm

    Cheers guys! I’m glad that you liked it :). I’m working on second part of the course right now. Should be published next week or so.

    Reply
    0
  4. silvercover Jul 24, 10:12 pm

    I really liked this article. specially the Sum-up section, Thanks.

    Reply
    +1
  5. Nick Jul 24, 11:58 pm

    Great article I really like the in depth descriptions of each. I think that we’ll see a combination of all three things in the future as rapid prototyping is becoming more and more common and clients want to see things turned around so fast. Coded wireframes are something worth mentioning I think too :) Great stuff though!

    Reply
    +1
  6. Dina S Jul 25, 6:41 pm

    Thank you for a great article! Really helps me to understand in which way I should develop my knowledge and gain experience. Looking forward to your next articles :)

    Reply
    +1
  7. Lila Jul 28, 7:09 am

    Thank you for this article! It’s very informative and clearly explains the difference between all three, in terms everyone can understand.

    Reply
    +2
  8. Stéphane Jul 28, 8:06 am

    Thanks for your article, it save me some time of explanation to my clients! Impatient to read the second par of the article/

    Reply
    0
  9. Greg Dlubacz Jul 28, 11:03 pm

    Thanks for such a great article and sharing your knowledge. Can’t wait for the second part of your course. Keep up the good work!

    Reply
    0
  10. Anastasiya Jul 29, 8:11 pm

    Thank you for the article. It’s easy to read and understand. Waiting for the second one!!!

    Reply
    0
  11. Manuela Jul 29, 11:39 pm

    May I ask what application UXPin use for wireframing?

    Reply
    0
  12. Marcin Treder Jul 30, 2:04 pm

    Thanks guys for all the kind words! :) Second part of the course is ready and is awaiting publishing.

    @Manuela – of course at UXPin we use… UXPin – our User Experience Design App contains great wireframing editor.

    Reply
    0
  13. Shani Dec 19, 10:14 am

    Great article.
    Thanks!

    Reply
    +1
  14. Dmitriy Feb 6, 11:59 am

    Very good article.
    Thank you very much!

    Reply
    0
  15. Ankit Khetarpal Mar 15, 10:10 am

    Simple and useful. As a newbie in the silicon valley I appreciate the information you have here. Thank you so much Marcin, the article was really helpful.

    Reply
    0
  16. Aqeel Ahmad May 27, 4:51 pm

    Very Nice Article, I was always guessing the difference among these three concepts and have a very clear understanding now.

    Reply
    0
  17. Prasad Sep 18, 8:48 pm

    Wounder-full article. Very useful and simple. Very nicely articulated. Thanks a lot.

    Reply
    0
  18. Trần Đình Khánh Oct 31, 1:58 pm

    Great article.
    Thank you for this.

    Reply
    0
  19. RYOHOI Nov 13, 5:18 pm

    LOL when I reads “due to the names of some software companies” : ), you’re damn brilliant dude!

    Reply
    0

Leave a Reply

*
* Minimum length: 20 characters