For providers of Software-as-a-Service applications, an online agreement with the product’s users is critical. Whether called a Terms of Use, End User License Agreement (EULA) or some other name, the agreement gives providers a host of benefits. It can reduce liability in the event of a lawsuit, secure intellectual property rights that providers need from users, help providers comply with privacy laws and more.
A user agreement will give the provider no benefit at all, however, if it is not designed in a way that courts will enforce. Among other things, enforceability requires specific front-end design choices when capturing users’ consent to online agreements. A provider’s failure to design those features can have catastrophic results in consumer class action lawsuits or other disputes.
This article summarizes the design choices that increase the likelihood of courts enforcing their online agreements. While referring mainly to providers of Software-as-a-Service products, this article also applies to website Terms of Service.
Design Considerations for Enforceable Agreements
1. The Capture Screen must require the user’s affirmative opt-in.
The best practices described in this article summarize rules developed by courts in hundreds of lawsuits over software. The particulars of these rules vary from state to state – a court in one state may enforce an agreement that a court in another state would not – but they reflect the most commonly applied rules today. These approaches assume that the provider posts its user agreement on a dedicated web page (which this article calls the “Agreement Page”) while using one or more separate web pages or on-screen modules (“Capture Screens”) to capture agreement to that Agreement Page. Capture Screens could include other pages of the same website that hosts the Agreement Page, or dialog boxes popping up on those pages. They could also include web forms and widgets published on third-party websites.
No single practice below will guarantee that a court enforces a user agreement. Courts take a “totality of the circumstances” view. They essentially ask whether the combined effect of the design choices makes clear that a user knew they were asked to agree to an agreement and did so unequivocally. The more a provider follows these practices, however, the more enforceable their user agreements will be.
2. Capture Screen language should record the user’s agreement to an agreement, not just agreement to begin using a service.
“I agree to the Terms of Use” is better than “Continue,” “Enroll,” “Register” or “Sign Up.” The goal is to make clear that the user is aware that her click binds her to a legal contract – not simply that she is clicking a button required for her to start using the product.
The example below shows a Capture Screen that likely creates an enforceable contract. This is a Capture Screen that appeared on an Amazon product web page when a visitor tried to begin using its AWS solution. Factor weighing in favor of enforceability include the default “un-checked” box (Rule 1 above) and the language recording the user’s “agreement” to the Agreement Page (this Rule 2).
3. Use separate consent inputs for user agreements and for other documents.
Many providers use a single input to capture consent to multiple documents at once. The example below uses one input to record agreement to a Terms of Service as well as a Privacy Policy.
Several recent court decisions, however, have suggested that the one-click input may not suffice. The ideal approach, therefore, is to have separate opt-in mechanisms. A better version of the text in the red box above would be two lines: one “By continuing, you agree to our Terms of Service” and the other “By continuing, you acknowledge our Privacy Policy.”
4. The Capture Screen should hyperlink to the Agreement Page.
Rather than simply stating “You agree to our Terms of Use,” the Capture Screen should include a hyperlink to the Agreement Page.
Some software providers, rather than linking to separate user agreements, insert “scrollwrap” features in their Capture Screens. Scrollwraps are popup boxes that require users to scroll through lengthy agreements before users can activate buttons recording their agreement to them. This approach generally suffices to create binding agreements as well, but it is not required and can create unnecessary friction for users.
5. Keep the link to the Agreement Page spatially close to the consent input.
In the Capture Screen, the text that links to the Agreement Page should be in close proximity to the registration buttons. Both examples above likely comply with this rule; the portion in the red boxes are immediately adjacent to the buttons used to continue with signup. (As noted above, however, the second example above fails a different design rule).
Above all, the link to the agreement should not be “below the fold” of the Capture Screen or require scrolling in order to find it.
6. Follow legibility best practices.
Courts have identified each of the following as either required or helpful for enforceability:
- The color of the hyperlinks in the Capture Screen should contrast with the color of the nearby font. Ideally, the hyperlinks should also be either underlined or italicized.
- Ensure that all font in the Capture Screen and Agreement Page contrasts sufficiently with its background screen. Black text on white is fine. Dark grey on light grey may not suffice.
- Legibility should apply across device types. Test all fonts and interfaces on mobile, tablet and desktop. What is clear when viewed on a laptop screen may not be clear on a compressed mobile app screen or on a mobile display of a website.
7. De-clutter the Capture Screen.
The Capture Screen should be as uncluttered as possible. Ideally, it will contain only the information and features required to capture the opt-ins (and perhaps other basic user information like username and password).
One court recently disapproved of a Capture Screen in part because it gathered payment information through the same screen that confirmed assent to the user agreement. In Sarchi, et al. v. Uber Technologies, Inc., 2022 ME 8 (Jan. 27, 2022), the court held that Uber could not enforce its user agreement against a consumer user who had sued it. The court found a host of defects in Uber’s User Experience relating to the agreement. One such defect was the clutter in the Capture Screen: “the focus on entering payment information” on that screen, in the court’s opinion, distracted the user from the import of the consent button that linked to the agreement. As a result of this and other design flaws, the court held that Uber could not compel the plaintiff to settle her dispute by arbitration.
8. Use the same degree of best practices in all relevant agreements.
Several courts, when declining to enforce an online agreement, have noted that the software provider was inconsistent in its compliance with these best practices. In the Sarchi case mentioned above, the court observed that while Uber maintained two different apps – one for drivers, another for riders – the former took more rigorous steps to put users on notice of its agreement than the latter.
Unless some compelling factors require otherwise, providers should make all of their agreement designs equally compliant with the practices described here.
9. Avoid “leaky” User Experience flows.
Software providers often use multiple inbound funnels and channels. A company might allow users to register directly on its website while also authorizing resellers to bind users through their own Capture Screens. The company may post still other Capture Screens on the company’s social media channels. There could be many paths by which a user might go from one of these channels to a Capture Screen to the provider’s Agreement Page.
All such paths should eventually lead to a Capture Screen and Agreement Page that comply with the practices described here. A “leaky” User Experience flow – one that allows some users to begin using the product without steps taken by other users – can leave some users unbound by the agreement. Designers should map all channel flows backwards from the product to all funnel entry points, to ensure that no path will allow a user to bypass the required screens.
10. Keep defensible records of document versions and user consent actions.
When a user agrees to an agreement, the provider should keep a digital record of that user’s consent. The record should indicate the date and time agreed, the version of the online agreement agreed to on that date and information sufficient to match the user later with that version of the applicable agreement. The goal should be to equip the provider’s personnel, in the event of a future lawsuit, to persuade a court that a given user on a given day agreed to a specific agreement. These records should be kept for an amount of time appropriate in light of litigation risk and other issues, such as any regulatory constraints.
Companies handle this record-keeping issue in a variety of ways, from using off-the-shelf CRM solutions that include versioning features to developing in-house databases.
Concluding Comments
The best practices described here apply generally to most consumer software products and websites. This article does not address additional considerations that can arise in the case of B2B (commercial) software, software used in regulated industries, mobile applications or software used in multiple countries. It also does not focus on Privacy Policies, which can have different design rules. In addition to the practices summarized here, some courts may require other design choices. Designing enforceable online agreements is a team effort that includes a provider’s attorneys, front-end designers and other stakeholders.
Related Content
