Mockup.

This guy is talking about building mockups, and only mockups.

A prototype is a working version of all key features that can be used as if it were the final product albeit in a somewhat limited fashion (E.g. the edges aren't rounded)

A mockup demonstrates the value in a non-working fashion so people can respond to the general idea.

If you don't get mockup vs prototype right, it's pretty hard for me to value your opinion on these matters.

IMHO, I don't know why people keep confusing UI with UX like they are the same thing, do you actually design the "UX" base on your own intuition without even know or test what the audience you are targeting for the specific product?. This more a wire framing to me, since this "prototype" is far from finish. I wait to read the next chapter since you it seems that it will address some of my concerns above :). Cheers

I too am a fan of rapid prototyping, but the example app here is incredibly simple. More complex apps require more time to refine & prototype.

That said, this sort of flat prototype should be do-able in a few days for even the largest of apps.

So, I'm in agreement with OP — except on the timeframe :)

This is a great post, but in these comments there is a strange fixation on the terminology. Is it really a mockup? Is the author describing an interface or an experience? None of these comments really say why the distinction is more important than the point of the post, which is to get an idea in front of users.

But if the obsession over the term is forcing you to ignore the point of this post, possibly this will help: a guy at Google apparently decided that the distinction was enough to coin the word "pretotyping": http://www.scribd.com/doc/62418833/Pretotype-It-Second-Preto...

(Even if the terminology doesn't matter to you, skim the book--it's free here and has got some great ideas).

Nice job, though you could argue a big part of the prototyping (in fact, the main feature) was already completed. Most of the design decisions, illustration and how the information should be displayed had already been 90% provided by Neila.

I completely agree with your last point on getting feedback and iterating on your designs. Prototyping is such an important part of the design process. ABP (always be prototyping.) I wanted a prototyping solution that worked within a designer's existing workflow which is why we built Stand In [http://standin.io] on top of Photoshop. It allows us to keep the prototype always in sync with the design and truly becomes part of the design process — not just a step afterwards.

I'm a bit confused by the article's blurring of design and prototyping boundaries. Is it reasonable (i.e. useful) to convolute wire framing with prototyping? I once worked as a prototyper for a design studio, and to them prototype meant an approximation of the product that could be used for critique and evaluation with users (so maybe a lofi paper prototype, deck-like click-thru prototype, or even a quick/dirty application).

I worked in a large, supposedly ground breaking digital agency where we had a game manufacturer as client. The client were keen on agile and continuos prototyping / mockups. Sadly the designers (pardon, 'creatives') and ux didn't want to know, the were too set in their ways and couldn't get out of the old workflow: work Photoshop / OmniGraffle; refine until perfect; pass on to developer. Eventually the client got pissed off and we lost them. The visual people just couldn't get their head around not having complete perfection at each step of the way. Shame, because it was a great project.

I think this is how most people work, unless you're a consultant that get paid by the amount of deliverables you produce. :-)

Prototyping to solve problems is often the quickest. Pulling other people's teeth to reach that point is what takes weeks. :-)

nice