What Is the Difference Between Wireframe, Mockup and Prototype? | Hacker News Reader

What Is the Difference Between Wireframe, Mockup and Prototype?

brainhub.eu

70 pointsmwarcholinski27 comments

I really disagree with thinking about the interactions that late into the process. I think that, today, interactions are at the core of an application instead of just being eye-candy.

Putting your wireframes in a prototyping tool allows you to quickly test and figure out if the interactions that will drive your flow are good or not. You really don't want to know this only when you're done choosing your fonts/colors and aligning everything.

With the "wireframe prototype" you get a good idea of the structure and the main interactions. The mockups can give you the look of the app. The final high quality prototype is also not always super useful, and should be used, imho, as a communication tool with the clients if they need it.

To me, a wireframe specs out the UX and shows all possible user interactions. A mockup is a static representation of a wire frame with design added. A prototype is a working representation of a wire frame with the design added. Though the functionality may be simulated or mocked.

These are good definitions.

IMO, prototype may have very different look and feel vs. the mockup. An Excel spreadsheet might be a reasonable prototype for core functionality.

Demo is where you combine look and feel with core functionality. It can still be very hacky under the hood and use pre-rendered output etc.

Granted, this assume complex functionality. If your reusing a common pattern like website with checkout then it's a non issue.

That really depends on what kind of product/service you are talking about.

Some categories exist in such abundance that one way to stand out is the create superior interaction.

But it's not always necessary to be successful.

As much as moving the fashionable styling from the beginning of the development process to the middle is an improvement, it still should probably be at the end. My preferred lifecycle is:

sketch -> wireframe -> prototype -> stylish paint job

Here is a nice table describing all three : https://camo.githubusercontent.com/7ddc56aa95ab03ebf7194a3fa...

Not about the op but I've always hated the name "mockup". Maybe it because it seems less technical than other terms used in the design process such as wireframe and prototype. I also dislike the way the word sounds. I often use alternatives like sketch or draft since they describe an output that is usually fairly short in the time frame of construction and open to future change. I hate the name mockup so much I think I may have opted to honestly not use the app Sketch if they had named themselves Mockup.

"Comp" or "layout" would be the more technical terms for that, though I've found they're generally less understood.

https://en.wikipedia.org/wiki/Comprehensive_layout

Generally the difference is that programmers make the prototype, designers make the mockup, and no one makes wireframes.

My UX dev colleagues say they now skip "sketch" and "wireframe" and most of "mockup", and proceed directly to what I'll call "high-fidelity mockup". This is possible because they have fully embraced UXPin. I'll not use the term "prototype" because I limit that term to coded artifact. And on top of the speed benefits of skipping sketch and wireframe comes the fact that the development goes twice as fast because they skip "prototype".

It says functionality is represented in a wireframe. Doesn't wireframe simply shows structure? That is, which elements goes where. The functionality is shown in a prototype.

You could argue that Wireframe shows functionality, whereas Prototype tests functionality.

That makes sense.

Exactly. As long as you share a common language in your team, and with your client, it doesn't really matter.

If someone says "I need a wireframe/mockup/prototype" then clarify exactly what they are looking for - functionality? layout? content?

Mateusz Warcholinski mentioned Balsamiq[1] as an example of his definition for a "wireframe" tool.

Therefore, instead of trying to parse his description of "wireframe", it may be better to just look at Balsamiq's capabilities: https://balsamiq.com/

To me, it looks like his idea of wireframe is something "clickable" ... such that it launches another fake page, but not functional. A Balsamiq/wireframe tool is something non-programmers like designers and business leads could use to communicate a UX/UI.

[1]Mateusz Warcholinski wrote: "My favourite tool to do it: Balsamiq"

Tad snarky.

I didn't intend it to be. I advised the questioner to simply do what I did myself : ignore the definition that Mateusz Warcholinski wrote which is open to misinterpretation (as this HN thread shows and Mateusz has acknowledged) and simply go to balsamiq.com.

After studying Balsamiq, work backwards from that to get an idea of what he meant by "wireframe" and whether or not it has "functionality".

I use Balsamiq, and I quite like it. It is a wireframe tool, but also more. My typical workflow is to do the wireframe and get it approved, import images into the wireframe to turn it into a mockup and get that approved, then use the mockup to implmenent the prototype. I like that I can simulate functionality in the wireframe and mockup. In fact, I typically don't even know how I will implement the prototype until the mockup is complete with simulated functionality, because that's what I'll use to determine the implementation (for new projects only, of course).

You cannot define a structure without it implicitly acknowledging what functionality archetype will be associated with it. For example, even in a most basic wireframe of a web app if a wireframe showed a left column about 20% wide and 100% height anyone with any experience in software will instantly assume a hierarchical menu of some design.

I would agree they aren't tightly coupled but there is definitely an association there that can't be completely separated.

I think the overall point of this article is spot-on: the goal is to iterate over the understand - design - build - use cycle, with each iteration working from the known to the unknown - by pinning down those design and architecture decisions that can safely be made early.

With regards to "when should one introduce interactions / logic / UI" decisions, I think it depends on the sort of application you're building, who is the user, and what are the risk factors that need addressing.

If the goal is to build a simple blog-like site for a mom-and-pop shop, then you might want to start with paint & chrome, because while many platforms could suffice, the importance of front-end gloss might drive implementation choices.

If the goal is to build a geodetic-measurement app for plate-tectonic specialists, perhaps you want to start with the engine, without which the entire effort is pointless.

To me it's all about

- Achieving a shared vision early then refining

- Surfacing risk areas early then addressing

Past that, how many iterations you need and what you call them is mostly semantic, once you understand what you're trying to achieve.

Thanks for feedback guys. I agree that in various companies those terms might have a bit different definition.

I wrote this, because I couldn't find anything good enough describing this topic. We often got aks by our our customers or first-time-founders - What is the difference? And why and how they can do it?

Blog about design; presented with a massive self-linking clickable image with no hint of content below the fold.

why is this article at the top? this is like web dev 101 stuff

A lot of developers still don't do this often, don't do it properly, or don't know what to call what they're doing. To you it may be 101 stuff, and it is to me, but if you were educated in front of, say, a form designer, that's a hard habit to break.

Wireframe, mockup, prototype,

those terms are arbitrary to some extend. You can have any degree of interactivity with any of those states.

Every article on Hacker News is 101 for some segment of HN'ers. Pick a piece of software and there's a non-trivial probablility that someone who wrote some or all of it has an HN account.

That's not to say it's a great article. But I can see why some people might find it intellectually interesting or useful because it cleared up confusion.

Hacker News is not uniquely immune to Endless September [0]. The expectation regarding dealing with it, using civility, is not unique either. But it is uncommon.

[0]: https://en.wikipedia.org/wiki/Eternal_September

Reply on news.ycombinator.com