From idea to core prototype in hours, not weeks | Hacker News Reader

From idea to core prototype in hours, not weeks

williamnewton.co

29 pointswilliamnewton24 comments

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.

This post is talking about prototypes from a usability perspective, not a technical perspective. A prototype by your definition ( a "real" prototype) would use data and be built in about the same way as the final product would be. I'm talking about how to prototype the experience. I see how it's easy for you to misunderstand me - apologies for not being clear.

Then it would be helpful if you qualify prototype as "ux prototype" or "interaction prototype". Paper prototypes, which this is fairly similar to, is a term that is lexically unambiguous. Without the qualification the title becomes confusing. I initially thought you were claiming to have a methodology to get a "real" non trivial prototype in a few hours.

That's not how its used in UX design. A mockup is essentially a screenshot: non-interactive, visually accurate. A prototype is an interactive simulation of the system. The term encompasses simulations which are very far from the final product, like creating interfaces using hand-drawn pieces of paper and sticky notes which are operated by a human acting as the system.

I find that it's helpful to evaluate ideas on their merits instead of quibbling over terminology.

If we go by intent: a mockup is used to get project buy-in and early feedback from stakeholders; design is still at the planning stage. A prototype is an abstraction of the system used to validate interaction features during design.

Getting terminology right is important from "does X solve problem Z, and are X and Y the same thing when it comes to solving problem Z."

Chicken chicken chicken chicken chicken[chicken], chicken chicken chicken (chicken chicken chicken chicken).

Chicken: http://isotropic.org/papers/chicken.pdf

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

Exactly — start with intuition then get feedback and fix what you were wrong about. And it's definitely far from finished. Thanks!

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.

That's accurate, and I think that's all the more reason to jump in and start. The content is all there, but there's more detail needed to make an app like this awesome, including stats and UX polish. I'm advocating for the 'just start' approach.

Indeed, the "just start" approach is awesome. It cuts the excuses people find to continue to "prepare" or procrastinate.

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 would use Standin if I used Adobe CC. Nicely done.

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).

Is it not clear that my approach is to 1. map out the idea (wireframing) and then 2. hack together a prototype?

Your post mixes together wireframing with prototype hacking. But I guess this is to be expected when programmers are doing design, a designer would look at this very differently.

Agree.

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.

This resonates pretty well with me due to my current role in an organization. Did anyone own the execution side of the project to hold the designers accountable for late deliverables?

Of course not, it was a creative agency, our job as developers was to cater to every creative's wish

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

Reply on news.ycombinator.com