Beta

The nuts and bolts: The term “beta software” refers to apps undergoing testing and have not been officially released. Generally speaking, there will be multiple versions during this time frame which can change at any given moment based on user feedback or other factors.

---

Remember the old Nintendo Power magazine (R.I.P.)? Remember all of the awesome walkthroughs, tips, tricks, and other resources? But there was one section that triumphed above the rest. That section was filled with future game releases.

One of the most interesting aspects of those upcoming games was all the information on the beta release. But when the games finally hit the general public, a lot of the features and images previously published in the magazine were nowhere to be found. That’s because the developers either found the features or screens to be unnecessary or didn’t feel that added much. So they dropped them. Unbeknownst to us, the editors over at Nintendo Power were actually teaching us a lesson in releasing products in beta releases.

With a beta release, you’re making your product available to your potential users for the first time. Your main purpose usually is to increase usability for your product through a type of unmoderated user testing. You will often find that beta fits into the prototyping phase of the iteration process.

With beta releases, there are two options for you to consider: open beta or closed beta, which we like to call a private release. The differentiation comes down to whom you release your product to. That being said, there are many aspects of each that you need to keep in mind when making your decision.

Open Beta

For products being used in open beta, this often means anyone and everyone has the ability to acquire the product and check out the feature-complete product.

Usually, you would have to sign up to a mailing list or some type of registration to receive the product. However, everyone can still procure the product instantaneously rather than waiting to be invited to use a beta-version or being one of the lucky few chosen for a private release.

Open beta allows for you to demo your product out to all potential customers. Paired along with the vast amount of potential customers you get to reach with this test, you also have the ability to get great amounts of feedback from testing the user base. One such well-known documented case was with Gmail.

Google’s email client was released in 2007 for the general public, but held the beta tag well into mid-2009. It was speculated that Google held onto it for so long because it didn’t quite grasp that enterprise businesses would be OK with continuous updates and releases. They shed the beta moniker to prove that they were ready for enterprise use.

That being said, however, open beta can be beneficial to getting your product to a large potential user base. It can be very tough waters to tread if you’re not very careful about your product’s state of stability and usability.

Private (Closed Beta)

On the opposite end of the spectrum of an open beta, you have a private release. This is for a group of people, users, customers, clients, etc.

Private releases can help you do three great things that you cannot get with a public beta:

• Build enthusiasm amongst users for your new product by shrouding it in exclusivity.
• You have the chance to select the appropriate audience to play around with your product that you can trust to give you necessary feedback, rather than just publicly maim you and your product via the myriad of social channels.
• Introduce new users to a retest of updated features, rather than recycling the same users over and over again for your new features.

Since the release is only limited to a few users to browse and check out, designers can have closer contact and easier communication regarding any bugs, errors, problems, otherwise any complications and get those inhibitors fixed promptly and more accurately, rather than dealing with a multitude of emails as would have been a result from an open beta release.

Private releases are great to test with an actual target audience. You can also use them to build your loyal customer base. It’s something we’ve used in the past. Because we want to cater our products to work best with our customers. A closed beta release worked well for a private release with Notable, a precursor to Helio. We developed our first iteration of Notable, which we then used around the office. We found that it worked just fine for us and completed what we designed it to do — provide a means of annotating screenshots with feedback. We took this as a sign and decided to run a private release of our Notable ZURBapp.

After the private release of Notable, we found that most of our users found the core concept of posting was working out just fine. However, there was a slight snag. Users were confused with the way posts were being organized within the workspaces.

With feedback in hand, we appropriately amended Notable and eliminated workspaces for everyone except premium plan users, essentially layering complexity into the product through pricing. After the changes, we found people were finding it easier to use and they were making more posts. The next iteration of Notable went over much better with our private release users.

But is it OK to Publish Your Beta Product?

Publishing in beta can be a double-edged sword if you are not careful. Sure you can publish something that is not complete, but you don’t want to publish something that will not work.

With beta releases, you want to make sure the features within your product are working and have clear instructions to follow. You need your users to test your features and make sure they are completing tasks and functions, as you would prefer. This is how you gain specific data and further the evolution and progression towards better products.

Going back to publishing, if the features do not work, there is no way to gather data, and in turn, you are slowing the design process tremendously. In the end, you are hurting yourself and your product. As long as your features aren’t broken, you should be OK in publishing.

If your product is ready to be used by the masses, then why should it carry the “beta” title?
If you are using an open and public beta strategy, as we’ve discussed previously, you may be nailing your own coffin shut.

By allowing the public access to your product early in its beta phase, most end-users don’t understand what the term “beta” truly means and just assume this is your product. So, if it works well, then you may have dodged a bullet. On the other hand, if your product does not perform well with its public beta release, then the masses may believe that your product is a bust and not want to continue to deal with your new product as was the case with the new Windows OS.

However, if you’ve thoroughly tested within your own team and find yourselves using the product sufficiently, it’s time to push forward with a beta release, preferably a private one to help build excitement and get valuable feedback.

The biased eye sees no flaws, thus we need to send it to others to show us things we may have easily overlooked.

So what will it be? Shall you push forward with your product as is, or do a private release and test your product? We’re fairly certain we know what you will do, and we look forward to being a part of your beta release to make your product beta and beta, get it?! Better and better … a bit of a stretch, but we laughed.

Put Your Beta to the Test

Helio makes it easy for you to test your beta with an actual audience, one that’s likely to be your perfect target. So stay on target, like Luke Skywalker, with our test template.