Sketch, Wireframe, Mockup, and Prototype

One part that new UX students struggle with is what deliverables they must create and when to use them. There is always confusion between sketches, wireframes, and mockups. Here, I will try to clarify each one with their intended use. Keep in mind that this could also change across companies and what is considered a wireframe at your work could be referred to as a mockup on another company. Also, depending on the design process of your organization, you might use some of them or not. For example, there are companies that jump into high fidelity wireframes while others take slower steps by starting with low fidelity ones.

In the end, all these tools serve for communication between the team, learn how the users expect the system to work, what makes sense to the users, and test ideas before they go to production.


While doing requirements elicitation, you can sketch your ideas right onto paper as they come to your mind. This is useful because you don’t forget any details during the interviews. Moreover, it helps in communicating within the team on how the design could work at the front end. With sketches, I prepare doing it with pencil and paper. Nothing fancy because the intention of this method is to put the ideas into paper that later serve for exploration. Sketches are part of the creative process of design but they are meant to be disposable and change rapidly.


After the kickoff meeting and constant communication with the customers and users, a designer might create a first set of wireframes. The first set of wireframes are called low fidelity wireframes because they are an enhancement to the sketch but now done with a design tool.

In the low fidelity wireframe, you are concentrating on the information architecture and structure of the app/website. Think of the header, footer, main content, buttons, and other components that make up your page. Colors are irrelevant and unnecessary and placeholder content is added.

The high-fidelity wireframe is where you add colors and replace the dummy text and placeholder images with some real content to provide context to the pages. I don’t like using “Lorem Ipsum” text on high fidelity wireframes because they could be distracting. Moreover, you could use some content related to the application so it is easier to test. This wireframe is how the final product would look like.

Note: Some teams would have a mid-fidelity wireframe that would be a transition between the low and high fidelity.


A mockup is the same as a high-fidelity wireframe. In some companies, the low fidelity wireframe is called “wireframe” while the high fidelity one is considered a mockup. Others would call mockups to designs that they present to stakeholders or direct users. If there is any difference between high fidelity and mockups is that in some organizations, mockups contain “real content” to simulate the real world while the high-fidelity wireframes might still have dummy text and concentrates more on the look & feel of the application. Just make sure that you are on the same page when communicating with your team about the expectation for your designs at any point in time.


This is when you make the wireframes or mockups interactive so you can test with your team and real users. The prototype could be:

  • A Figma, Sketch, or Adobe XD project made interactive.
  • A series of screenshots and put together within the app or website for users to click on.
  • HTML pages with no real functionality in the backend. Like a wizard of Oz but the click-through from page-to-page loads just a plain HTML file with no connection with backend services.
  • There are “paper prototypes”, that are made with printed screenshots, wireframes, or sketches of the app for testing with users. As they are paper and disposable, you can use paper prototypes during any phase of your design process.


In each of the steps or phases of your product design and development, it is important to continuously test your features and ideas with real users. Usability testing is a must in order to really solve users’ needs. I hope that these explanations help you to communicate better with the team and the users. For students, now you know what your instructors expect when the assignment is mentioning one of these UX deliverables.

Teylor Feliz
Teylor Feliz

Teylor is a seasoned generalist that enjoys learning new things. He has over 20 years of experience wearing different hats that include software engineer, UX designer, full-stack developer, web designer, data analyst, database administrator, and others. He is the founder of Haketi, a small firm that provides services in design, development, and consulting.

Over the last ten years, he has taught hundreds of students at an undergraduate and graduate levels. He loves teaching and mentoring new designers and developers to navigate the rapid changing field of UX design and engineering.

Articles: 182