After moving beyond the phase of paper prototypes, or prototypes built in something like Axure, we'll often build quick and dirty web prototypes in HTML, CSS, and Javascript. So far, we've taken the same approach as with any other prototype, in that these are meant to be tested, used to garner user feedback, and eventually discarded.

However recently we've been approached on multiple occasions by customers to continually add features to these prototypes until they essentially become a minimal viable product. When should the transition typically be made from throw-away prototype to alpha software in the UX process?

  • 2
    I think the only answer is "when it makes sense to do so." It's going to vary wildly depending on the team, product, company, process, etc. – DA01 Sep 3 '14 at 20:02
  • @DA01 I suppose the hope is that along the way someone has found a decent process or set of standards for how and when to make the transition, naturally always with a bit of room for variance given the differing situations you mentioned. – gotohales Sep 3 '14 at 20:46
  • 1
    @Izhaki I've seen both. Sometimes eager developers will try to implement our prototypes by plugging them directly into their dev environments, other times clients will continuously widen the scope of the prototype to try and evolve it into a finished product. – gotohales Sep 3 '14 at 23:08
  • 8
    Wouldn't this question be a better fit on Software Engineering than here? – Bergi Sep 4 '14 at 11:58
  • 3
    A hint to solution lies in last line your question "... in the UX process?" Organisations that have a UX Process separate from S/W Development Process generate this Prototype / Alpha conundrum. This may help explain variety of answers below. – Jason A. Sep 4 '14 at 12:33

I hope the answer to the question is never.

A prototype is meant to be a test. Built using the most "hacky" approach with the least amount of time to get initial feedback on whether a concept is viable.

The alpha is something you give to actual users. This is the version, if successful, you hope to build upon to become the beta and eventually the product you release to the public. I would hope your alpha is built upon a solid enough foundation that you can built upon.

A hacky prototype usually provides a very poor foundation. If you do have a prototype based off a proper framework (very rare and I question whether you could have gotten away with a more low-fi prototype), then when all features in your MVP is complete and your devs feel they have sufficient stability to support your X number of alpha clients. And you have a plan in place to handle bugs from clients etc... then it's okay to start alpha testing your software.

Otherwise... please leave the prototype as the prototype and build your alpha properly from scratch.

Two cents from a designer who've seen more than one prototype pushed into being the actual product code and the resultant nightmare of the team trying to build on top of that shaky foundation.

  • 16
    As soon as the customer and/or the suits approve the prototype. I've suffered through the same nightmare of a prototype that evolved into a real product. The cost of building on a hacky foundation is so enormous that it will exceed the cost of throwing it out and doing it right long before milestone 1.0. – Kevin Krumwiede Sep 3 '14 at 21:04
  • 1
    I don't know that that really has to be the case. Iterative approaches that start out quick-and-dirty are really the best way to go for some scenarios. If you give some thought to breaking things up in a way that you can go back and do things the "right" way later it isn't miserable. – Casey Sep 3 '14 at 23:45
  • 2
    @emodendroket iterative approach is good in some situations but then you don't have a prototype. Prototype has to be quick to develop and to change, it has not to scale. Iterative approach (when used) is usually second step: when you know where you have to go then you start to build it and you refine product iteration by iteration. You can also drop prototype and start directly with that approach but it doesn't change a production-quality product into a prototype. If they're same thing then 1) you have too good prototypes or 2) too bad production code... – Adriano Repetti Sep 5 '14 at 8:15
  • 1
    Oh please, let's face it. "Prototype" is mostly a buzzword for managers in big companies to fight their QA departments and suffering engineers. I still remember when I was young and stupid asking a dumb question: "This project has been running some years and we are already past 40,000 lines of code. When will we be allowed to write tests?" To which the answer was: "Oh! this is just a prototype, don't worry about those things now" – SystematicFrank Sep 5 '14 at 11:36
  • 3
    Never is the correct answer, I hate when people want to reuse prototype code without rewriting it. – Juan Mendes Sep 6 '14 at 13:55

Mostly working self employed / freelancing on website related projects I would say it's the developer/designer's decision if it's a (working) prototype or a (buggy) alpha version. A prototype is never ment to be public while an alpha version robably is. The line between those two is difficult to draw – but for me / with web projects it's the moment when I dare to say "we're online".

Or to quote the software relase life circle as it can be found on wikipedia – but in my own words: an alpha version is a (first) version of a software – a prototype comes before that.

  • 1
    I agree, I believe it's the developer's job to say, "yes, this is ok to be an alpha." An alpha is never going to be perfect, thus being labeled as an alpha. – Majo0od Sep 3 '14 at 19:36
  • When, before being "online", would you say the developer transitions from prototype code to production level code? – gotohales Sep 3 '14 at 20:48

Unlike nightning, I hope the answer to the question is always.

On detailed designs

What else do you give in your design deliverable to developer if not a full specced-out design that ideally has be the same one you've used in your user-testing using prototypes?

My experience is that if you leave any stone unturned with your design - ie, any place for interpretation - the developers will come up with all sorts of solutions that can very well be counter-usablity.

And then if you use prototype A.01 in testing but then give design A.05 to the devs, the gap between the two is untested.

No doubt, early prototypes are often scoped to key design challenges, but late ones should, in my view, be as close as possible to the real thing.

Coded prototypes in modern age

In this day and age, where many designs involve an excess of interactions (and animations), functional prototypes become more and more important. Personally, the interactive requirements of some designs mean that spelling these out in a static document makes no sense whatsoever. I find myself sometimes delivering designs with an interactive prototype (an actual website) saying "this is how it should work like" and only spell in the design document things you cannot show (or not obvious) on an interactive prototype (eg, "Sorting by 'active' means by the most recent timestamp of both posts and replies").

Deployed prototypes

Having had my time as a developer, I have recently ditched wireframes altogether and jump straight from excessive sketching to working prototypes using HTML, CSS and AngularJS. The backend is all a stub simulating the real system, but the front end, in quite a few cases at least, can be copied-and-pasted to the actual system.

However, as nightning mentioned, speed is critical for these prototypes, so although the prototype works as expected, its code is fairly dirty in most cases (you don't spend time to code it right, you just need it to work). So some extra refactoring work is often needed.

  • 1
    I hope you don't copy/paste code... else +1 – kaiser Sep 4 '14 at 11:47
  • 2
    A design prototype is very different from a software prototype. And since software prototypes generally are not tested, refactoring (except in very simple cases) becomes error prone and takes a long time. Better to rebuild the software using TDD once you understand the problem space. – l0b0 Sep 5 '14 at 7:34
  • @I0b0: "... using TDD ..." Thank you! Thank you! – Bill Dagg Sep 12 '14 at 22:23

I think this depends on your software methodology. This somehow reminds me to eXtreme Programming (XP), where you start with the simplest solution and keep adding new functionality through short development cycles.

If you are following a methodology such as this one, then you can transition when the main features are included.

I can agree with the previous answers but I can see this is not always possible. In many real client projects, you don't have the full and closed list of requirements. In many cases, your customers have a very limited knowledge about... many things. So you have a dynamic list of features to implement which can grow (or even shrink). Summarizing:

  • Prototype: a simple proof of concept that you can show your client.
  • Alpha: all (or most) main features implemented.
  • Beta: all features implemented.
  • Release: Beta + approval from your customer. This means tested successfully by your customer.

Note: If you are following this methodology, you test every feature that you implement.

Source: http://en.wikipedia.org/wiki/Extreme_programming




Versioning systems

Semantic Versions is only one of many ways to version/name your steps to the final product. And alpha is only part of the Semantic Version idea. In other systems there is nothing like an Alpha version.

Some version number systems aspire to merely label changes in an interface, but there is much in the human experience that lies outside of this. Sometimes a version is just a number, but sometimes what we really want is a poem.

Quote: Sentimental Versioning

(Be in) Version Control

Nowadays all software products should use a VCS Version Control System from the very start. This gives developers and designers the possibility to iterate quickly, keep separate elements on different branches and merge parts from variant A.1 to Variant A.23 and present the difference. As long as your "prototype" is under version control, then it's already part of the final product.

Hint: with for e.g. Git you can split things into orphan branches or subtrees to break them out.

The workflow changed - Your toolkit as well

With modern tools like Yeoman who allow you to use generators to quickly bootstrap your Application. We are beyond the days of prototypes for the webs front end. We start with what is real. We have tools like Grunt, Gulp, Robo and other task runners who help us the skipping prototyping stage and directly jump into scaffolding things that we will use in production.


If you get a no by someone, then they just got stuck with a 1998-style toolkit. Scaffolding applications is what happens now. The only thing you mock is the database. And even for that, you got Mock frameworks.


Prototype: Demo/Test version with some features still missing/incomplete

Alpha: All features complete

Beta: All features complete, no known bugs

(At least in theory ;))

  • 1
    If this were true, no software would ever be shipped – BlueRaja - Danny Pflughoeft Sep 4 '14 at 0:00
  • Well, I already said "in theory". – Roman Reiner Sep 4 '14 at 5:48
  • "All features complete, no known bugs" = the wet dream of any dev – Alex Sep 4 '14 at 7:40
  • Upvoted. This is right, even if it's just theory (like most answers here). – kaiser Sep 4 '14 at 11:48

I would say that a proptype has made up data on each page, often the data on different pages don’t relate to each other. E.g. it shows a concept in such a way that it is clearly not useable in reallife.

But an alpha allows data to be saved and the next time it starts up it uses the saved data.

Often an alpha will “do less” then the prototype, as the prototype is trying to show all the concepts, but the alpha just has the pages that are most required to allow anyone to use it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.