When does a prototype become alpha software?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

tl;dr

YES

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.

Conclusion

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.

Answer 6

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

Answer 7

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.