Terms of Service — An opportunity in UX Design?

“I’ve read, understand and agree to the Terms of Service” … is the biggest lie on the internet. We opt for ToS which are designed for people, not lawyers. But would it work?

Railslove
The Railslove Blog
6 min readNov 15, 2018

--

They are among the most common, yet least recognized elements on the internet: Terms of Service. Everyone has confirmed hundreds, if not thousands of the legalese text blocks without understanding what they agreed to.

When diving into the topic, I was curious about how many accounts I had really signed up for in the past without reading even a single ToS text. A glance into my eleven-year old 1Password account revealed the truth: one thousand two hundred and eighty three accounts. 1,283! Equalling (roughly) the same amount of terms of services I had ignored.

Congratulations to me. Am I an idiot for not knowing what I was actually agreeing to all these times?

Well no. I can recall feeling a little uncomfortable with skipping ToS texts in the distant past. Today I am totally fine with skipping to the end of ToS, checking the box and going about my business — and that’s okay. Ain’t nobody got time for that, anyway.

A guy once tried reading all the small print he encountered on the internet and for services he had been using for years (including those of his iPhone) and came to the following conclusion:

„[…] my advice is: carry on not reading the terms and conditions. Hope someone with more time, a better legal education, or a weird fetish for huge chunks of block capitals, does it instead.”

ToS structure and language are intentionally misleading

For most services, the people behind it don’t actually want you to read and understand their ToS because what they contain would terrify you. And that would be bad for conversions. Therefore they hide them, design them as confusing as possible and use a shit-ton of legalese. And we don’t just perceive it that way, people have actually put some work into the topic:

Irene Pollach, a professor from the Danish Aarhus business school, did some research on structure and language of Privacy Policies (which are in its nature very similar to ToS despite being more standardized compared to the highly individual content of ToS). Upon examining 50 websites from a “broad spectrum of business models”, she found different linguistic patterns that aim at confusing the average reader.

  • When sharing data with third parties, qualities are over-emphasised using terms like trustworthy or carefully selected, spam is described as being “of interest/value to you”.
  • Hedging and obscuring claims like “we reserve the right to, inlcuding but not limited to, might, (not) with(out) your consent / permission / knopwledge” are very common, just as removing agents from actions described: “the sharing of (rather than we share), you receive (rather than we send)”.

She concludes that the texts deliberately leave us puzzled and are written to fulfil legal obligations, not to be fair towards the users.

The Levels of not wanting you to read the ToS

So, unsurprisingly no one fights their way all the way down to the “accept” button but jumps there right away — if even required to do so. There are a few common ways of “informing” the user about the ToS. Some are more honest than others but virtually all lack user-friendly access to those chunks of information that actually matter to the users.

Level 1

You need to actively check a box, then register. This is becoming rare.

Level 2

Approval via clicking the register button. That’s the most common solution.

Level X

No sign of ToS or Privacy Policy anywhere. This is becoming acceptable.

Here’s another example (in German language) from Apple that perfectly displays how badly they want you to NOT read the ToS.

  1. You receive a notice that the ToS have changed
  2. You face a 20-pages-long wall of text (through which you cannot scroll and navigate properly, it’s broken and they don’t care — or broke it on purpose?)
  3. If you really do want to receive the ToS document, you need to type in your email — on your iPhone where they could easily fetch your Apple ID mail from anywhere
  4. Finally, you receive a poorly formatted piece of text
Jumping through hoops to read the ToS

Is it worth fixing, anyway?

Let’s be honest: ToS are broken and they need to evolve. But how can we change them from being intransparent and ignoring the user’s need to achieving an honest way of communicating to the user? Do ToS really need to be designed for the people using the service, not exclusively to meet legal requirements?

Chances are it will not actually help improve user trust but will both unsettle and annoy the users. No one gives a damn about which service does what with their data, people have come to the conclusion that they don’t actually need to know as it takes too much effort. That’s sad. To turn it around someday, ToS need to be visibly integrated into processes without harming the UX. Easier said than done, but there’s already a solution…

Forget “one click to rule them all”.

We need a fine-grained, contextual way of consenting. Modular feature-on/off-switching — just like on mobile!

Wouldn’t it be much more transparent to authorize a feature like “may access your location when using the app” (which everyone has authorized at least once in their life) every now and then? Trade some tiny fractions of your time for the knowledge of how your information is actually being used.

Take Twitter or LinkedIn as an example. When signing up, you most probably have agreed to them accessing and storing your contacts, somewhere in between the 10k words ToS. It would however make much more sense to only ask you to consent once you actually decide to upload your phone’s contacts to boost your follower figures.

The holy grail: Conversion + Transparency = Happy Businesses & Happy Users

This way the user will stay informed on how the app uses information through actually using the features that requires their consent. This establishes an understanding for why it’s crucial to even give consent to all those shady practices and unreasonable requirements. Which, after all may not even be so impertinent.

Here comes the “but”. There’s a huge “but” up there: The majority of things cannot be displayed like that. Yes, it would contribute to shorten the typical ToS text, establish some trust and keep conversions up. But would it really fix the underlying problem? It would, at most, lay a foundation to establish awareness and acceptance.

When talking to users, product designers and UX people at meetups, conferences and when holding talks about the topic, feedback was both supportive and hostile. From triggering the ambition in many UX experts to viewing it as a economic suicide for companies that rely on conversions, we heard many controversial opinions.

It will be a tough job for UX designers to turn intransparency and ignorance into an honest communication that has the goal to inform. We need to find more ways to embed ToS in visible processes without messing with the user experience.

How? ¯\_(ツ)_/¯ Don’t know yet. Do you even think it’s worth working on? Which side are you on? Let us know!

--

--

Railslove
The Railslove Blog

We're a team of hackers and thinkers from Cologne. We craft web applications and, well, we're kinda good at it.