Tester agreements. Many of us use them, but for the uninitiated, they're the list of tick-box conditions included at the bottom of the tester application form that we ask test applicants to agree to.
We ask applicants to respect deadlines, not alter the pattern without consent, and to stay in regular communication with us, amongst other things.
I mentioned these recently in my article series on
How to Choose the Right Testers since they're part of the arsenal of tools that help us curate our test group. However, tester agreements serve a much larger purpose.
Not a contract
Contrary to popular belief, they are not a contract. Or rather, they're not an enforceable one.
A contract's strength lies in its enforcement, thereby allowing the levying of sanctions as a deterrent against breaching said contract.
Bit of a mouthful there, so let me quickly break it down: whether tester agreements are legally binding or not is dubious at best, for various reasons all of which are way beyond the scope of this article. That is, however, a moot point because how would you enforce such a contract anyway?
Are you going to enter into arbitration or open some kind of lawsuit to force a random stranger from the internet to send you that missing photo of something they knitted? While picking that logic apart can fill an entire book, the infeasibility is quite plain to see.
Also, I won't even get started on monetary recompense for the pattern itself. That's a whole other can of worms, and I'll save the pleasure of opening that for a future article.
So if tester agreements are not binding in a practical way, nor are they an adequate deterrent for undesirable behaviour, then why should we have them in the first place?
Setting expectations
Tester agreements set expectations.
First of all, they set the general tone for the test and send the message that there is structure to it: we're serious about ensuring the quality of our patterns; we want to run a good test; we're not just playing around; and we expect the same from our testers.
Not that people shouldn't have fun making the item. After all, having something new to make and enjoying the process is a big part of the appeal. It's just making it clear that there is a further scope to participating in the test besides whiling away the time.
Secondly, through them you can articulate the specifics of what you're after. For example, that you expect 3 well-lit, quality photos by the end of the test.
These requirements could indeed be communicated elsewhere, rather than as tester agreements. You could include them in the test description, for example. However, they might then be lost amongst all the other, more germane pieces of information, and vice-versa.
Furthermore, these agreements tend to be process-specific and don't change much from one test to another. So having them in their own little section will help the testers to compartmentalise information, especially those that test for you often. It also makes it easier for you to reuse them from one test to another, while sending the message that this is your process, and that it's a system you adopt in all of your tests. It lends weight to the requests.
Send me the Challenges of Running Pattern Tests eBook
Learn how successful designers are dealing with the top five problems of running pattern tests.
Discover a novel solution to make the process simpler and more effective.
Thank you!
Your copy of Challenges of Running Pattern Tests should automatically download.
If it doesn't, you can get it by clicking this download link instead.
Recommended agreements
The conditions you ask your (potential) testers to agree to can be whatever you'd like them to be. You can choose to not include any at all, but that would be counterproductive. Of course, the other extreme of really articulating every minutia is equally as bad.
All you need is a standard set of basic stipulations, customised to suit your own process and preferences as needed. If there's anything specific you feel like you absolutely must include, or exclude, then you should feel comfortable doing that. As long as you're not asking anything unreasonable, you'll be just fine.
Below is a list of suggested tester conditions.
We've found that these cover you for most situations, are flexible enough to not really impose anything on your testers besides some basic reporting expectations, and set an adequate tone.
Do you agree to complete projects and submit good, clear feedback on time, or give reasonable advance notice if you are unable to meet a deadline?
Do you agree to provide at least 1 (one) progress photo and 2 (two) finished project photos?
Photos need to be clear and of good quality.
Do you agree to regularly communicate with the designer and actively participate in any tester group communication?
Do you agree to follow the pattern without altering it in any way unless given consent from the designer?
Do you agree to create at least one [platform of choice, eg. Instagram] post showcasing the completed project you have just tested?
Do you agree to respect any communication embargoes which will be made clear to you for each pattern being tested?
An embargo is a date or condition until which you cannot publicly speak about, or share photos of, the project or your involvement in it.
Do you agree to allow us to use your project photos for reposting on our website, social media and other platforms for content and advertising purposes?
You will be fully credited in all photos whenever the medium allows for it.
Do you agree to not reproduce, repackage, distribute or resell (in any form or by any means) the pattern or any project-related assets sent to you?
Feel free to use these, as-is, in your own tester applications, but I recommend you make appropriate changes to suit your tone, style and requirements.
Are there any other conditions you ask your testers to agree to when applying to your tests? Leave a comment below and let me know!
Stephen 
Comments powered by Talkyard.