How do you choose between wireframe and prototype in UX design?

Wireframes can be done both digitally and physically with pen and paper. When starting out it’s great to sketch out 3 to 6 initial layouts on paper before transferring it over to digital. This helps to get you out of a stagnant state of mind or falling into a repeatable design state. Wireframes should have clear definition of what element is what, images typically being being box’s with a cross between the corners, and buttons are clearly labeled.

I have found helpful to begin with a flow chart. For a brand new UX, I often begin with post-it notes on a board, each of them with the touch points and interactions (front- and back-end). It helps me identify all the user-facing points that will be passed to the design team to create the wireframes, and this also helps me as reference to write user stories, feature requirements, test cases, alt-states, etc.

It's always worth starting with Wireframes, even if they only last a day. The reason being you can quickly try things, and get as many of your ideas out of your head as quickly as possible. Once you've got something you think works, then you can try it on Users if possible, but certainly good to talk through with a wider team and stakeholders. Stakeholders can be tricky to navigate when going through the process of designing User Experiences, but involving them throughout different stages will help reassure them and get buy-in.

Every design I work on, whether is a website, an app, a print design, or even a logo, starts out as wireframes drawn with pencil on paper. Wireframes are quick and easy enough to draw that they enable and even encourage rapid ideation and iteration.

You can prototype your wireframes too of course. However, this is only useful if you have some unknowns that doing so would help you work out. Will users understand the flow? Perhaps it's particularly nuanced. Will users be able to follow the information flow? Perhaps it's particularly long, or even complicated. Otherwise, a low-fi prototype can be a barrier to users understanding the overall product, causing feedback to be flawed.

When working on something technically challenging, wireframes are great to map, discuss and improve processes based on things perhaps your design team can't see. Like information architecture quirks that prevent stages from being done in a certain order for instance. However, when it comes to user testing, the user is effectively not testing the final product or even something that visually resembles the final product. Therefore observations made are only really useful if you are testing for something specific, that you can hone in on.

Prototypes are a great way of showing a finalised product. However, we would recommend ensuring development teams and software engineers are involved in this process. This is to ensure that the prototype does not represent some blue-sky thinking. There is no reason your high-fidelity prototype does not represent the final product exactly unless you're not listening to your dev team.

At the end of the day, you need to evaluate the three key things for your project, time (deadlines), resources (what skills are available to you) and budget (how much can you add to the previous two). From here you need experienced team members who can plan how to get the most out of your project based on these constraints. In general, Wireframe quickly before prototypes are designed. Test both, even if one is wires are only internal.