Schedule a Call

  • How to Turn Beta Testers Into Real Users

    Find the right beta testers and they’re more likely to become real users.

    When testing for Usability, UX or running a Q/A Bug test, you typically want to run the tests with participants that match your target audience as closely as possible. When you obtain feedback from users that are representative of the people who will actually be using your finished product, you can draw meaningful conclusions from the data and take the right actions to improve your product.

    Although testing with your true target audience is sometimes not possible (e.g. very niche audiences), when it is, you also get an additional benefit: Your testers are more likely to turn into real users. In fact, your testers are probably more likely to become active users of the end product than organic users that you might acquire through other methods.

    The reason that the right testers are more likely to become real active users and ambassadors of your product is that they will probably feel a sense of buy-in. If they have provided you with feedback and have helped you improve the product, they will feel like they have some ownership in the end result. This is more likely to lead them to continue using your product and even spread the word about it. They might brag to their friends about that fact that they got early access and helped with testing, which will result in more exposure for you.

    Now that we’ve established why it is a good idea to test with your target audience, let’s take a look at where to find the right beta testers.

    Here are some of the best FREE resources to find beta testers that might be a great fit for you:

    • Reddit  – Reddit is one of the best resources to find any sort of a niche audience. Subreddits are communities within Reddit for different interests, and it is very likely that there are subreddits that relate to your niche. You can promote yourself or your product by engaging and adding value to the group, or simply by running ads within them.
    • Hacker News – A social news website with entrepreneurial / technical audience (developers, startups, etc), that are generally eager to help. This could be a great website to promote your startup / product to potential beta users.
    • Blogs / Press – Here is a good list.
    • Daily featured startup email lists – Featuring your startup on popular sites like BetaList, Product Hunt can be a great way to add a lot of beta users to your email list. The users you find on these sites might already be early adopters in general – so people that sign up for your list are likely to be enthusiastic about providing feedback and are self-selecting as a part of your target market.
    • Beta testing platforms (not free) – Beta testing platforms like BetaTesting and others are a great option for finding the specific users that you’re looking to target. At BetaTesting, we can help you target your ideal audience through demographic targeting, and a screening survey for refined targeting on any criteria: interests, lifestyle, etc.
    • For specific countries – In addition to the above mentioned resources, there are some things you can do to acquire users from specific countries. For example, you can advertise in those countries through Google Adwords or Facebook, post on blogs/press sources that are specific to that country, and target users in their local languages.

    Finally, just because you’ve managed to find the testers that match your target audience doesn’t mean your work is finished in turning them into real users. The likelihood that they become real active users depends on one thing: Are they excited about your product and do they want to continue using it? Treating your testers as customers from the very beginning can help immensely in ensuring that they remain excited.

    Here are some tips to follow to get better beta engagement:

    • Remove obstacles – Any inconvenience in using your product can turn off users easily. Go out of your way to make sure that the process of testing / using your product is as easy and enjoyable as possible.
    • Be thankful – Don’t take your users for granted. Appreciate the fact that they are taking time to provide you with valuable feedback. Always make sure to read their feedback and respond directly where applicable.
    • Communicate – Communication is key. Keeping the users updated is not only helpful in the feedback process, but it will also help in keeping them excited about the product. You can provide a quick recap on the test, update them on any changes, and let them know your launch date etc.
    • Distribute – Be sure testers have access to the full public product when you launch. They might have had access to the “beta” version through a third party app like TestFlight. Do let them know when the finished version is available through regular channels like App Store / Play Store etc.
    • Improve – If for some reason, you see that users aren’t engaging as much as you’d expect, it’s a sign that they are not interested / excited or that they don’t find the product useful. It might be a good idea to read some of their feedback and improve the product or make necessary tweaks.

    Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.

    , , , ,

  • Communicating UI Design: Problems with Lorem Ipsum Placeholder Text

    Avoid the pitfalls of pasting improbable dummy placeholder text (lorem ipsum or otherwise) into your user interface designs.

    When communicating UI design, you’ll sometimes use temporary placeholder text (“dummy” text) in your wireframes, mockups, or even interactive prototypes.

    Below I list some of the problems with pasting perfect pieces of placeholder text all over your UI design.

    Note: in this article, placeholder text refers to temporary dummy text (e.g., lorem ipsum) that appears in UI design mockups and documentation. It does NOT refer to the placeholder text labels that appear inside form fields in a published app or live website.

    Common placeholder text problems

    Unrealistically concise titles, labels, descriptions, etc.

    Intentionally or unintentionally, placeholder text often depicts headings, labels, text blocks, etc. as shorter (i.e., containing fewer characters) than real-life content will actually be in the final product.

    This might happen due to bad assumptions, wishful thinking, or from a conscious or subconscious desire to make the design to look nicer.

    • Invites designers and reviewers to ignore and defer design concerns such as:
      • Text overflow (e.g., text wrapping vs. ellipses vs. other)
      • Proper static font sizing
      • Whether to specify dynamic font sizing.
    • It will be more expensive to address such design issues later (and/or might result in a worse implementation than if those aspects of the design had been considered and specified earlier.)
    • The design under review doesn’t have the same visual effect the real-life product will.

    Related: on occasion, placeholder labels are longer than the real-life text will typically be. Some of the same problems can result.

    Ambitious UI elements that no one will want to fill with real text

    Sometimes designs include well-intended text-filled elements… that are doomed. Perhaps a place in the UI is carved out for a page summary or detailed user instructions. These UI elements appear sensible and look nice with dummy placeholder text! But when it comes time to actually write something to put in there, problems become apparent.

    • In the abstract, design reviewers can lazily assume all sorts of compelling, life-changing, product-selling copy will fill the spaces reserved for text.
    • Reviewers might even be lulled into not thinking about that element at all. It looks good in the mockups… and it’s probably there for a reason, right?
    • When the time finally comes, however, filling those elements with text might not work out:
      • No one knows what to actually put in there; or
      • Any text that is put there is not useful or is unwanted noise.
    • Perhaps some pages can make good use of that text-filled element, but other pages just don’t need it at all. Design guidance is needed for when the element is empty.
    • Perhaps the amount of text actually written for this element in the final product results in an unbalanced or odd-looking UI. Not what the designer intended. If the truth was known earlier, the designer could have improved the design before it was even implemented.

    Multiple elements copied and pasted with the same placeholder text

    Just about any app or website has the potential for repeated elements on the same page (e.g. article previews, product cards, etc.) It’s common for the designer to copy and paste the same components with the same lorem ipsum placeholder text for each instance in a UI mockup.

    Identical blocks can give an unrealistic impression of the design

    • Everything lines up nicely
    • Everything looks neat and tidy
    • The overall effect is not realistic

    Identical blocks can obscure design and layout issues

    • Allows designers and reviewers to misunderstand or ignore issues of alignment, sizing, layout rules, etc.
    • Many of these layout details would be immediately apparent if the placeholder text were simply varied instead of repeating the exact same text for each
    • For example, cloned box-elements displayed side-by-side are always the same height. What happens if one box has more text? Does it wrap to more lines and make that box taller? If so, do all the other boxes have to match that height? What if one box has way less text? Does the box get shorter? Is there a maximum and/or minimum height for boxes? Etc.
    • Again: it is better to consider, address, and specify around these issues sooner rather than later.

    Filling every possible data slot with text, when in real life that won’t happen

    Mockups often include all of the data that is possible to include, in every instance. In the final product, however, all the data might not always be available or necessary.

    For example, a user account panel may need to be able to display address, phone number, email address, etc. But what if the address and phone number were optional when the user signed up, and she left them blank?

    For similar reasons as mentioned above, it helps to create and see mocked-up examples where optional data is not shown, in various configurations. This will clarify the impact (or lack of impact) missing fields have on layout. For example: should there be “holes” where the missing data would have been, or does the other data “move up” to fill the gaps?

    Holding on to lorem ipsum for too long

    Content is very important. Depending on your product, it might be the most important thing.

    The further along you are in the project, the more you should be using and testing real content in conjunction with the design.

    As your initial design graduates from lo-fidelity sketches/wireframes, realistic content needs to replace more dummy content. As your mockups graduate to higher-fidelity prototypes, lorem ipsum should be banished, and you should be incorporating and testing the actual intended content wherever possible.

    Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.

    ,
    , , , ,

  • How to Find Beta Testers for Small Business Software

    There are many benefits to beta testing your small business software before final release. Beta testing helps you test key processes and performance, get feedback on UX (User Experience) and UI (User Interface), identify bugs, and verify that your ideas are well-received.

    It’s always ideal to test your product with users that match your target audience, specifically when seeking higher-level UX feedback. However, finding beta users for business software can be significantly more difficult than it is to find testers for consumer products – especially if you need the software to be tested by a business as a whole, or by a specific group within a business. For example, if you need an entire HR department or sales team within a company to test your app as a group, you are likely to have a very difficult time finding willing testers.

    Let’s look at why it is difficult to recruit small business beta testers, and what are some potential ways to get around this.

    It’s difficult because:

    • Incentives – Incentivizing a business is a lot more complicated than an individual. Someone interested in a consumer app might be happy to provide feedback for a small reward or for free access to the app for a certain period of time. On the other hand, it is very unlikely that even a small business would find it worth their time and effort to test / provide feedback for anything less than $5K or more.
    • Reliability – Even if the financial incentive was adequate, businesses might still be reluctant to use software for testing purposes. The tasks or processes that they are using the software for, will probably have a direct impact on their customer’s experience or on operations within their company. This is why they want to use proven software, and not beta software which likely isn’t feature rich and may have technical issues.
    • Logistics – It can be logistically challenging to coordinate the testing of your software with a business because it will often require buy-in and approval from multiple people.

    Potential solutions:

    • Individual testers – You may want to reconsider if you really need to test your product with an actual business. In many cases, it may be possible to simulate the experience / interaction a normal business might have with your product with a group of individual testers. For example, if you have a to-do app, can you recruit individuals that work for small businesses to provide you with feedback? Also, for some types of testing you can still get invaluable feedback from testing without your true target audience (e.g. Bug testing or UI testing). In any of these cases, you can follow the same advice we provide for finding beta users for consumer products. Also, at BetaTesting we can help you target professionals based on industry, company size, and job function.
    • Existing network – Can you test with your existing customers, partners, or other contacts in your network? Think about if you have existing relationships with businesses that would benefit from the product you have built and if it would make sense for them to test it. This would ideally be a situation where your software or app can add value to their business without having to disrupt any of their current workflow.
    • New customers – If you do not have any existing relationships with businesses that can help you with testing, it might be a good idea to start acquiring some of these customers. Some methods and resources to acquire B2B clients (not necessarily just for testing) are:
      1. Cold email – The important thing to keep in mind when reaching out to businesses through cold email is to not come across as spam. keep the emails short and simple, point out how your software can benefit them (if you have an example of how a previous version of your software has helped another business, definitely include that), and avoid pushy marketing lingo. Also, make sure that you’re reaching out to the right person whenever possible.
      2. Content creation – Writing interesting and engaging content that is relevant to your target audience will help you attract more traffic to your site and establish you as an authority in your niche, potentially resulting in more customers for your product.
      3. Reddit, Quora – Great resources to find people within any interest group, engage with them, and promote your product. Reddit most likely has subreddits that relate to your niche where you can run ads.
      4. Linkedin – You might already have people in your extended network (who you have shared connections with) that are in your target market. If you see someone that you think would benefit from what you’re offering, send them an invitation to connect, along with a personalized message. If they accept, you can now consider them a warm lead and have a conversation with them through LinkedIn’s messaging system.
    • External help – If none of the above seem like feasible options for you, you will need the budget to pay for external help. This will probably mean offering sizable incentives to recruit willing businesses.

    Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.

    , , , ,

  • Adobe XD Update Adds Two Long-Awaited Features

    The June 2018 Adobe XD update improves the tool’s prototyping capabilities by adding fixed-position elements and overlay support, among other enhancements.

    Just last month, Adobe put their UX design and prototyping tool—Adobe XD—on a promising path of improvement while simultaneously making the tool free to use for everyone.

    This month’s update—available as of June 19—fulfills a bit of that promise with a handful of improvements, large and small.

    Two long-awaited features

    The June Adobe XD update brings two features that move the tool’s prototyping capabilities closer to those of its advanced peers.

    These features are: overlays and fixed elements.

    image of youtube video about Adobe XD update features

    [Adobe video on Fixed Element and Overlay features on Youtube]

    Fixed elements

    This feature allows you to mark elements that should remain fixed to their position on the artboard, regardless of scrolling.

    This means that you can now have a fixed header, bottom navigation, etc. that acts properly in prototype mode for your scrollable screens.

    Unless, of course, you also wanted those elements to animate on scroll. XD still can’t do that.

    Overlay support

    With overlay support, artboards can now be displayed on top of other artboards.

    This is most straightforwardly useful for pieces of UI that temporarily appear “on top” of other content on a screen. For example: you can configure your prototype such that when the user taps a button, a small modal dialog appears in the middle of the screen.

    XD designers could also, for example, display a mobile keyboard over the current screen of an interactive prototype, without having to fake the effect by transitioning from one copy of the screen to another copy of the same screen with a mobile keyboard pasted on it. In addition, as an overlay the mobile keyboard can now be more realistically animated in the prototype—it could slide up from the bottom of the screen, for example—because the underlying screen doesn’t move in the transition.

    In addition, support for overlays allows for more flexibility in your prototype and more economy of artboards in your project file. For example, an XD project could include a single drop-down menu artboard that can be used by any number of other screens. Before overlay support, a designer would have to make a dedicated copy of any and every screen she wants to support displaying the drop-down menu.

    Other improvements in the latest Adobe XD update

    Private sharing (BETA)

    About private sharing, Dani Beaumont of Adobe writes:

    You are now able to create a new private link for your prototypes and invite someone to view it by email. You can include a message, and once they’ve received your email, they will be able to view and comment on your design.

    Adobe provides a video of private sharing in action.

    Ability to adjust an image after dropping it into a shape

    Adobe refers to this as “improved crop and place image fills.” You can now resize and reposition a masked image you dropped into a shape. (Video link)

    This beats the previous process of dropping an image into a shape, not liking the result, cropping/scaling the image in an external application, and then trying again.

    Improved Photoshop and Sketch image fill support

    Related to the previously mentioned improvement, adjustments to image-filled shapes from Photoshop and Sketch are now preserved when importing files into Adobe XD.

    Also:

    • Support for Typekit fonts on mobile
    • Math calculations in property fields

    About the math calculations, the update announcement on the Adobe blog provides some examples: “For math calculations in property fields, you can reduce grouped objects by 80 percent, quickly dividing an artboard area for tile design, or moving an object in an X or Y location by a specific number of pixels.”

    Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.

    , , ,

  • Project Tips for When Your UI Design Includes ALL CAPS Text

    From design and implementation to translation concerns, here are some tips for your project when your UI design includes ALL CAPS text elements.

    Whether you’re following a standard design language like Material Design, or have developed your own custom look and feel, your new website or app design might include UI elements that use uppercase text (“ALL CAPS”).

    Subheadings, button labels, tiny links, etc. are common candidates for ALL CAPS treatment.

    Below are some tips for you to apply to your project when handling ALL CAPS text in parts of your UI design. (These tips would also apply if your website styling used forced lowercase in some places, e e cummings style.)

    These tips might just save you time, money, and hassle!

    Note: By my reckoning, these tips are in rough order from more obvious to less obvious. Your mileage may vary.

    1. Make sure ALL CAPS isn’t used in places where there will be a lot of text to read.

    As it is commonly believed, all-caps text is somewhat harder to read than regular sentence-case (“mixed-case”) text.

    I’ll spare you the controversy, conflicting cases, and misapprehensions on this matter. Suffice it to say, readers tend to read ALL CAPS text a bit more slowly, and tend to dislike reading long passages of ALL CAPS text.

    None of this means you can’t use ALL CAPS in your UI designs. But it does mean you should use it sparingly, and in places where there won’t be chunks of text for you users to read.

    Body text (article text, product descriptions, etc.) should obviously not be displayed in all uppercase. However, tab labels, button labels, and the like are supposed to be concise, so ALL CAPS is certainly an option for those elements.

    Further, elements that tend to be as long as medium-length sentences or phrases—such as certain heading types—may warrant an ALL CAPS treatment in your design. For example, ALL CAPS might help you establish visual contrast for one heading type versus other headings and body text, without having to otherwise exaggerate size, weight, or color differences. (This is not a recommendation, it’s just one way to go. It’s up to you what works for your overall design and brand aesthetic.)

    But again, the thing to watch out for is long blocks of text. Let’s say, for example, your H3 headings are styled in ALL CAPS. But if some pages of your website might use H3s for potentially long lines of text (e.g., the title + subtitle of non-fiction books), you may want to change the styling of your H3s, at least in those contexts.

    2a. Use CSS or string functions to convert text to ALL CAPS for display

    You don’t want to store your display text strings (see below) in ALL CAPS and just display them. Instead, you’ll want to use CSS or string transform functions to convert text to ALL CAPS for display only.

    CSS Example

    h3 {
    text-transform: uppercase;
    }

    Reasons:

    • Future flexibility – You’ll be able to change your styling later with just a few changes to your CSS or presentation code, without having to hunt down and rewrite a bunch of text labels.
    • Reusability – There may be some instances of text labels you wish to reuse in different places throughout your site or app. In different contexts, the styling of the same text might be different.

    2b. Store text strings with normal (appropriate) capitalization

    Whether you’re keeping your UI text strings in a database, in text resource files, in your source code (I won’t tell anyone!), or a mix of these, you’ll want to store those text strings with appropriate capitalization, not in ALL CAPS.

    Ask yourself: if this piece of text wasn’t going to be styled in ALL CAPS, what kind of capitalization would it have? However you answered, that’s how that text should be stored.

    Most text strings should be stored using either:

    • Sentence-style capitalization – e.g., “Tools, resources, and help files”
    • OR Book-title capitalization – e.g., “Tools, Resources, and Help Files”

    …even if it will wind up being displayed as all uppercase (e.g., “TOOLS, RESOURCES, AND HELP FILES”) in the user interface.

    3. Tell your devs and writers what’s up!

    Make sure to inform your team that text strings are not to be stored in ALL CAPS.

    Depending on the project, UI text may originate from visual specs, prototypes, word docs, etc. UI text might initially be typed up by developers or by copywriters. Later on, UI text additions and modifications may come from change requests, bug reports, etc.—and perhaps handled by entirely different team members. You likely won’t be in the position to review every change.

    Everyone is busy and focused on getting their own work done. Writers might not know what implementation is possible; developers might not think about how best to handle text strings from your perspective. And neither is likely to automatically have your best-practice plans in mind when they are doing their work. It helps to let them know.

    Further, your style guide should include which UI elements should use sentence capitalization and which should use book-title capitalization.

    4. Double-check your text resources before you have them translated!

    Allowing ALL CAPS text to go out to translators could be an expensive mistake.

    Different languages have different capitalization rules. If you discover you’re storing ALL CAPS source text after it’s already been translated, you won’t be able to properly fix those instances yourself without sending them back to translators.

    That’s time and money you didn’t anticipate spending!

    Note: You might be able to check this yourself without having to pore over all your text resource files or poke through your CMS database. If you can temporarily turn off uppercase styling, you can run through your site or app and look out for labels that still appear in ALL CAPS.

    For example, you might be able to use your browser’s inspection tools to change text-transform: uppercase; to text-transform: none; for all buttons on the page, and then inspect the result.

    5. Don’t trick your users to into entering data in ALL CAPS

    One last weird consideration.

    If your application supports user-entered content, make sure not to use ALL CAPS styling on the same kind of data your users will be entering into a form.

    For example, if you display message titles in uppercase in your UI, then users might naturally follow suit and enter their message titles in ALL CAPS to match. That is not desirable.

    Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.

    , ,
    , , , ,

  • Beta Testing a New Feature: When to Use the "Beta" Label

    When a new product is in the beta phase, it’s normal to clearly identify this. But what about when beta testing a new feature in an already public product? Should you tell users that this is a “beta” feature?

    First, let’s quickly define what “Beta” means:

    “Beta” is the phase in software development between the alpha phase and the actual public release. In the beta stage, development is largely complete and the product has undergone some amount of initial alpha testing (usually with an internal QA team, or using emulators or online labs). However, the product is not ready for public release yet as it has not been thoroughly tested in the real world – that is what the “beta” phase is for. Apps, websites and new product features are often said to be in “beta” at some point in the development cycle.

    When a new product (as a whole) is in the beta phase, it’s common to clearly identify this, and recruit users to participate in “beta testing”. But what about when launching a new feature in an already public product? Should you tell users that this is a “beta” feature?

    Is it always a good idea to label a new product feature as “beta” when testing it? The answer, as you guessed, is “it depends”.

    Different reasons you may want to use the “beta” label when beta testing a new feature:

    • Identifying bugs – To warn users that there may be bugs / issues so that you can manage expectations. You could also incentivize users to identify any outstanding bugs. You can let them explore the feature on their own and report any issue they find, or give them specific tasks and processes to complete and report any issues within those tasks / processes.
    • Getting feedback – To let users know up front that you are actively building and improving this feature, in order to get more feedback from the community. To get the highest quality of feedback / engagement, make sure that you’re making the process as easy and rewarding as possible – for example, by making it easy for the users to provide feedback, communicating regularly with them, helping them gain easy access to the new feature, and most importantly being thankful and respectful to them.
    • Marketing – “Beta” features are exciting and new. You could label a feature as “beta” as a marketing tactic to attract new interest. When you release the beta to a certain group and encourage them to provide feedback, they feel a certain amount of privilege and “buy-in” in your product. They feel like they are an active part of the improvement process and this can encourage them to spread the word amongst their friends and families. Just make sure that the beta version is presentable and doesn’t have any major bugs.
    • Testing – Beta testing a new feature by having users “test drive” it is a great way to test your product in the real world and get a feel for how it will be received by a larger audience when it is released. At BetaTesting we can help you get an in-depth understanding of the user experience, as well as organic feedback  / engagement in a real world setting.

    The reasons you may not want to use the beta label on something:

    • Credibility – You don’t want to disclose to potential customers that you’re beta testing a new feature. A product in beta may still be fixing bugs or just generally be more difficult to use and less valuable. Advertising a product is “beta” definitely won’t help sell it to Enterprises that want stable and reliable software.
    • Organic engagement – You want organic engagement from the users for your new feature, without additional messaging or hype around the fact that it exists.
    • Continued development – You might be building software quickly, and don’t see any reason to publicly indicate where a particular feature exists in the development lifecycle. You may, after all, be continually refining all your features.

    Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.

    , , , ,

  • TVCO: Beta Testing Case Study

    TVCO Tests Live Broadcast Functionality And Builds a Community of TV Lovers.

    Since the Golden Age of Television in the 1950’s, nothing has brought the family together quite like gathering around the living room TV.  But today, this pastime is changing. With limitless personalized entertainment options at our fingertips, more and more people are watching exactly what they want, when they want, and no longer fighting over the remote. While this is a welcome change for our hectic lives, watching TV just isn’t as much fun without sharing the experience with someone else.

    Startup TVCO, based in New York, is a new social network (iOS and Android) seeking to reshape this experience and build a community of TV fans and celebrities so you never need to watch TV alone again. Through the app, TV lovers can participate in communities built around their favorite shows: join chat rooms, watch live video broadcasts to hear what someone else has to say, or host their own TVCO.

    Since the early beta stages, TVCO has been working with BetaTesting to test key app functionality with each major release and collect feedback directly from their target audience. Broadcasting technology is complex, and presents a unique challenge during the testing phase, according to Co-founder Tyler Korff.

    “Our mobile application allows any user to broadcast live from within the app, and it was particularly challenging to find a good number of testers who could all be available to test live at the same time,” said Mr. Korff. “We also required a flexible test that allowed for dynamic instructions- with testers alternating between broadcasting and watching. The BetaTesting platform supports such a complex testing environment. BetaTesting was able to recruit testers and coordinate a live test with over a hundred testers on short notice. The feedback allowed us to refine our processes and continue scaling.”

    Through the flexible BetaTesting platform, TVCO found an ideal solution for both technical bug testing and user feedback. While initially searching for a company to help conduct a single beta test, TVCO instead found a partner for continued iterative and agile testing into the future with each major release.

    “We were looking for a cost-efficient way to simultaneously test our app for bugs and obtain user feedback. BetaTesting’s nifty user interface provides the perfect combination of testing and user feedback, and allowed us to achieve our goals,” said Korff.

    “We were looking for a testing company and we were happy when we found a testing partner.” said Korff. “With BetaTesting, we found a company that felt like an extension of our in-house team. The most important factors, for us, were responsiveness, collaboration, and flexibility. We spoke with a couple other testing platforms before finding BetaTesting, but as soon as we met the BetaTesting team, we knew we had found our partner.”

    BetaTesting’s approach to beta testing and customer feedback is never hands-off, but instead is a collaborative effort with each client that includes planning, execution, and feedback analysis.

    “Our BetaTesting project lead, Michael, was tremendously helpful in shaping our campaigns,  providing valuable guidance on survey questions and tasks as well as tweaking our language to make the test clearer,” said Korff. “BetaTesting KNOWS the testing community – even little changes to our proposed test, improvements we never would have otherwise considered, made a HUGE difference both in terms of clarity and efficacy. From the very beginning, the BetaTesting team was quick to respond when we had questions about the process or structure of the tests or the BetaTesting platform; we greatly appreciated the quick turnaround time. I can’t imagine what testing would have looked like without BetaTesting.”

    “One’s never quite sure what to expect with respect to the quality of beta testers, but any doubts we had about beta testing were immediately put to rest when we reviewed the results of our BetaTesting campaigns. BetaTesting found us testers who intuitively grasped our product and what we are trying to accomplish. Having such early adopters on board gave us the confidence to move forward with build releases and further development. BetaTesting testers are smart and sophisticated – and it was fun working with them. They provided us with all the detailed information we needed in order to pinpoint bugs and improve user experience.”

    Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.

    ,
    ,

  • User Experience Article Roundup – Alternative User Research and Growing as a Designer

    In this edition of User Experience Article Roundup: free user research alternatives, inspiration from a subway map, what happens when robots sound human, and more.

    Cheap and free under-the-radar alternatives to field visits

    It’s vital to understand your users, particularly when it comes to the context in which they use your product. Site visits with users (ethnography and contextual inquiry) are a great way to accomplish this.

    But what if you are not given time or resources to do site visits? David Travis offers up some “under the radar” user research alternatives you can do on your own, quickly and cheaply.

    DO Make Me Think

    There may be a time and place in your application to intentionally make the user slow down and consider what they are doing. In fact, the negative consequences of “oversimplifying” important workflows might be huge.

    What London’s Underground Map Can Teach You About Design

    Sometimes you have to know when to turn a map into a diagram, so to speak.

    So you’re the only designer at your company

    It’s common for startups to have only one designer on staff. If that’s you, this article offers you “a guide to surviving—and prospering—as a one-person design team.”

    A 25-Step Program for Becoming a Great Designer

    Good generalized advice for being a good designer, presented as 25 “steps”. You may have already internalized some of these principles, but revisiting good ideas can be beneficial.

    Google Translate as a case study for improving user experience

    While the article initially looks like an advertisement for Google Translate, it’s actually a case study about testing UI designs to improve user experience.

    Perhaps you can relate: your product already has the features your users want, but your users don’t seem to realize it. In this article, a UX manager at Google discusses successes and failures in refining a user interface in order to get users to notice and use features they would actually find useful.

    Also, this

    Page Flows

    This service provides an archive of videos and screenshots capturing a variety of user flows from a number of web sites and mobile apps. The service says it aims to reduce UI designers’ research time, or to “to inspire you when you’re stuck.”

    Note: There are a few free videos on the homepage, but otherwise it’s a paid service. I haven’t subscribed to it, nor can I vouch for it. Just pointing it out as a resource.

    When robots sound human

    Last month, Google unveiled an AI system called Google Duplex on stage at the Google I/O 2018 conference. In the presentation, two audio recordings demonstrated how an extension of Google Assistant could make phone calls and interact with (seemingly) unwitting human beings to make haircut appointments and dinner reservations.

    I’ll admit that, while I found it interesting, my reaction was mostly skepticism that this functionality would actually work well and be available anytime soon. The internet, on the other hand, immediately started discussing the moral and ethical implications of Duplex.

    Sure, it was interesting to witness a debate about whether Google was purposely moving toward making Blade Runner a reality. But even better, the discussion reminded me of an article from last year that thoughtfully discussed the implications of making digital assistants (particularly Amazon’s Alexa) sound more human:

    The Surprising Repercussions of Making AI Assistants Sound Human

    The way our digital assistants communicate with us influences what we expect from them, how we feel about them, and the way we communicate back to them. You won’t be surprised to discover there are pros and cons abound.

    Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.

    ,
    , , , ,

  • MORE Reasons to Use a Longitudinal Study to Test Your App

    Here are more examples of insights that a longitudinal study can provide about your web or mobile application and its users, to help you improve your user experience and increase profitability.

    Earlier this month, I revisited longitudinal studies and provided a number of specific-ish examples of valuable insights you might gain from running one.

    To refresh your memory: the longitudinal study is a testing method whose defining characteristic is collecting data from the same users multiple times over a period longer than a typical user test. How much longer? Well, there’s no set duration for longitudinal studies. You might plan one to last three days, three weeks, or three months. Whatever it takes to fit your purpose. And, again, your purpose is to gain insights about your product and your users that you just can’t achieve with regular testing.

    In that previous article on longitudinal studies, the examples spanned four categories:

    • How users’ attitudes toward your product change over time
    • Natural use and usage patterns over time
    • How users’ own data affects their behavior
    • How users handle long-term tasks

    Below are four MORE categories of reasons of why you might want to use longitudinal testing to test your app. These examples of target insights might not fit your exact situation. They are to inspire you to think of all the ways you might use longitudinal testing for your own your product.

    MORE reasons to use a longitudinal study

    You might want to use a longitudinal study to test your app and help you to learn about things like:

    Long-term learnability and forgettability issues

    Regular user testing will do a good job testing the initial learnability of your user interface when it comes to the tasks you give to your participants. Longitudinal tests can inform you about: long-term learnability and forgettability; how interfaces optimized for short-term learnability affect experienced users; and more.

    Example insight goals:

    • Are users still experiencing the same problems with the same tasks over time? Do new usability issues arise?
    • Do users forget how to perform common tasks over time, or after some time away from the using the product?
    • Does your highly learnable tool still satisfy users after they become “power users”?
    • Will your users forget how to use (or simply forget about) rarely-used features in your application?

    The impact and effectiveness of your onboarding techniques

    You can focus your testing to learn more about how your onboarding techniques, tutorials, and hint systems are engaged by users, and what long-term effect they have on product use.

    Example insight goals:

    • Do users who skip tutorials have a worse experience using the app? If so, do those users ever overcome it?
    • Do external prompts—such as follow-up emails that explain app features and encourage their use—have the expected positive impact on the user?
    • Do specialized first-time-use flows help the user understand the purpose/usefulness of the app? Does this translate into increased account creation?

    How users handle expert / unlockable functionality

    Sometimes functionality doesn’t apply to new users. This may be due to a user’s level of ability, or because your product can unlock features over time. With a longitudinal study you can see the evolution.

    Example insight goals:

    • When do your users feel comfortable tackling advanced tasks?
    • Are users overwhelmed or confused when advanced tasks are available to them from the outset?
    • What keeps users interested longer: unlocking features as they go, or starting with everything available?
    • Does your mobile game’s progression system continue to keep your players engaged through to the end? If not, where and why do they lose interest?
    • Does the availability of paid downloadable content keep users engaged with your app longer?

    Other validation and discovery

    With longitudinal testing you can validate your assumptions, and also just be open to discovering things about your users that you wouldn’t know to specifically target.

    You have the opportunity to receive a ton of raw data and feedback from your participants. You can turn this data into insights, some of which you’ll be looking for, some of which you’ll simply stumble upon.

    Example insights (as goals or happy accidents):

    • What actually motivates your users to use your application?
    • What is your user’s impression of your product before they use it? Does it match their understanding of the product after they use it?
    • What influences how a user makes a decision in your app?
    • What is most important to your users? Does that match your prior research and assumptions?
    • What is a sustainable level of use in the long term? Does that meet your business goals?

    Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.

    , , ,

  • How to Get More Beta Users to Test Your App or Website

    “If we could get more beta users to sign up for our app test, we would be heroes!” said every startup founder.

    It’s important to keep in mind that signups are only useful to the extent that they lead to engagement, feedback, referrals, or some other positive outcome. It isn’t just about getting more beta users to test your app. In the beta testing phase, your ultimate goal should be to improve some other key metric, for example active users or revenue, or simply to collect feedback so you can continue to improve. As you build your app, be sure you keep that end goal in mind, because signups are only the first step. Great products are usually born through iteration and customer feedback, which is something that we can help deliver with our beta testing packages.

    With that said, we encourage every startup to hustle and make use of every free resource and proven marketing strategy to get more beta users to test your app.

    Here are some proven ways to get more beta users to test your app:

    1. Free online exposure – Take as much advantage of free online exposure as possible. Some great options:
        • BetaList – Great resource to get pre-launch signups
        • ProductHunt – Once you’ve launched
        • Facebook groups – There are most likely numerous Facebook groups that include your target audience. Joining these groups and actively engaging in conversation with members and adding value to the group can be a great way to directly engage with your audience and adding users to your beta list.
        • Reddit – Reddit has a large number of very active audiences spread across many different areas of interest. There might be sub-reddits that are relevant to your product where you can introduce your product and get feedback. This is a another great way to engage your target market and get the word out.
    2. Get press – This website has an awesome database of tech journalists, guests blogs and influencers: http://tech-blogs-list.com/
    3. Blogging – Start blogging about your product even before you launch. Content marketing can be a great strategy to attract interest for your product launch. You can also add a link to your landing page on your blog posts where users can sign up for your beta email list.
    4. Email List – Start building an email list and keep your audience engaged by sending them valuable / interesting content. You should get started as you are building your product (not once you finish). That way, by the time you do launch you will have an audience that is already receptive to you and your product.
    5. Quora – Another great website to gain credibility with your audience and get exposure. You can search for questions that are relevant for your target audience and provide helpful answers and solutions.
    6. Advertise – Advertise using Google Adwords or Facebook – While you might be able to get some users for free, if you’re looking for a significant number of beta signups you’ll need to invest in user acquisition.
    7. Get help – There are several companies that specialize in beta testing and can help with this.

    Things to watch out for during the Beta period:

    • Don’t make users sit on your waiting list for too long. The longer they have to wait, more likely that they will forget about you or lose interest, resulting in a smaller % of them actually engaging when you do eventually launch.
    • Don’t expect everyone on your list to be anxiously anticipating your launch. Most likely, only around 25–50% of the users on your list will actually engage.
      Not communicating regularly with your list will also result in lack of interest. Be sure to invite them to be a part of building your product. You can keep them up-to-date on your launch date, send surveys and collect feedback.
    • To get the highest quality and engagement and feedback, make sure your beta signups are a part of your target market. It’s not very effective to just have people on your list just for the sake of having a list. If they are the right people, it is more likely that they will be more interested and engaged with the product.
    • Do your best to remove any and all road blocks. Every difficulty your users face will result in fewer users engaging and providing feedback. Some things to watch out for: – Do testers need an invite code? Do they need to install a profile on their iOS device so you can collect their UDID? Do they need to confirm their email (or phone number) prior to access? Do they need to install TestFlight? Do they need to wait days or months to get access?

    Some good techniques to increase engagement during the beta testing process:

    • Keep users engaged and give them a reason to come back. Communicate with them via email and app notifications.
    • Make it extremely easy for people to test and give feedback. Don’t make people jump through hoops.
    • Create a formal testing process with deadlines, surveys, incentives, and regular communications. Users should know what they are testing, what you need from them, how they can help, and what is in it for them.

    Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.

    , , , ,