UI/UX Invalidated your Contract

Startup and video game law, from a Canadian and U.S. perspective

Online contracts are only effective if implemented correctly. I’ve written on different processes for implementing online contracts, which is often easier to accomplish in the web context. In the mobile context, implementation is challenging given the need to balance user experience with contract formation.

How you structure contract formation in your mobile application involves negotiation between the UI/UX team and legal counsel and a balancing of user experience against the risks of the contract unenforceability. With millions of DAU, the risks are enormous.

A recent case illustrates this risk and shows that even sophisticated startups can run the risk of a weaker contract formation process and be burned. Lyft presented users with this acceptance screen:

It includes the typical web approach to contract acceptance, with a check box stating: [I agree] to the Terms of Service (link). Recently, a NY court determined that this process did not clearly indicate to users that a contract was being agreed to. The combination of a series of “Next” screens, the small size of the contract formation text (relative to the large, pink “Next” button) and that the contract was presented in the context of an unrelated phone number request all contributed to the court’s conclusion that users were not sufficiently notified of what they were agreeing to and, as a result, did not accept the Lyft Terms of Service.

Luckily for lyft, prior to the lawsuit, a new contract formation process was implemented, one I’ve advocated for myself:

One mobile approach is to present the agreement to the user, require that they scroll through the agreement and, once scrolled through, the user is presented with the following button at the bottom of the page: [I agree] to the Terms and Conditions.

Take away:

At a minimum, mobile applications should have prominent language indicating that a contract is being presented to users (ideally as a separate screen labeled “Terms of Service” or similar).
Contract language should be noticeable and not blend into the background as a user registers for the application. Try to alter the flow of the registration process so the user recognizes that something new is occurring.
Any button on the contract page should state “I agree” or “I accept”, rather than “Next” and this button should not overwhelm the contract link.

In my opinion, the scrolling process described above is one of the better approaches for implementing a contract into a mobile application. Other approaches are available but your UI/UX team needs to work with legal counsel to ensure that design considerations do not overwhelm contract enforceability.