What do you get when you cross user needs with legal needs? Sometimes, it can result in a big explosion! In my experience, legal needs quickly overshadow user needs because we all put in place safeguards against possible future legal action by customers / users. The ‘legalese‘ that we see on the web is just a simple progression from print. The Internet is pretty young compared to centuries of print history. How the legal jargon is presented on the web has not evolved much from its printed cousin to cater to the fleeting attention span of the web user.
We, in the User Experience industry see this as a hindrance to the experience of the user. If information is difficult to understand, there is more potential for errors by the reader / user. This then starts a blame game between the user and the provider. It’s a long-standing war where many battles have been fought and many have been left bruised on both sides. There are no winners in this war when it comes to long-term customer relationships.
There have been several initiatives such as the Plain Language Movement to make the legal stuff easier to understand. However, this blog is not about language because I’m no linguist, although simpler language is crucial. I believe, we, as designers of technology, have the responsibility to reduce this bloodshed from a design point of view and come up with designs that not only fulfill the needs of the users but also those of the lawyers who’re only doing their job.
I recently came off a usability testing project for a client that we have had a good relationship with for the past couple of years. This time, we were commissioned to test a confidential feature within their website. Let’s just say the purpose of the website was to let its users perform a search and receive results.
One of the major issues that we uncovered during the tests was that the users were finding it very difficult to get to the search results. This was mainly due to the huge amount of legal text on every page of the search tool. Before you can use the tool, it shows you a massive disclaimer lightbox which you need to have agreed to have read and understood.
After closing the lightbox, the actual search page has another screen length disclaimer and you’re left wondering where the search fields actually are. They are actually all the way down the page.
And then after you put in your search terms and get to the results page, again, another long disclaimer before you get to the results at the bottom of the page.
The participants were definitely getting frustrated having to trawl through all that text. Web users want to get to their final goal as quickly as possible and anything that does not help them get to their goal can be perceived to be a roadblock causing immense frustration.
It’s totally understandable why the system was designed like this – because the client did not want members of the general public to use that information inappropriately in ways that could harm their wellbeing and take legal action against the client. But the problem is that if users do not understand the information presented to them, they are more likely to use it incorrectly. Sure, legally, organisations might be able to save themselves from lawsuits by dumping information on the webpages and shifting the blame on the users for not reading it carefully. But wouldn’t it be better to make the information easier to read and understand in the first place?
Some might argue, ‘Well, if the customer reads and understands the fine print, they might not want to use our product.’ Well, if your business model runs with that assumption, then you shouldn’t be running a business at all. And then there will always be a minority of individuals who, regardless, of all the information, whether legibly presented or not, still would want to sue the pants off any organisation they deal with. But our goal is to make lives easier for the majority of users out there who are genuinely seeking solutions and also save the backside of organisations providing these solutions. So can we kill two birds with one stone?
I believe we can. I don’t claim to be any linguist or a legal expert. All I did was follow some conventional design principles and stated my case that they are good for both sides – users and organisations. This is what we did:
First, we talked to the legal team and explained to them what the issues were. You might find that they are open to your ideas if it makes sense to them. Understand the need for the legal text and ask whether it can be removed, reduced or moved. You might be surprised to find that they’re willing to negotiate.
2. Break up the text with headings and subheadings
A lot of times though, the legal text cannot be changed. If the text on the disclaimer page looked like a boring essay in Latin, then we can at least make it a scannable and readable boring essay.
As a general rule, web users do not read, they scan. During the tests, we found a lot of participants preferred to scan the text but the way the text was presented made it difficult for them to read it. So we just broke up the text to make it more readable:
. Use visual hierarchy
If you try to make everything on the page look important, then nothing becomes important. Hence, use:
Big text for important things
Smaller text for less important things
Even smaller text for even less important text
Bold text for sub-headings
Indenting to break the monotonous flow of the user’s eye gaze along the left hand edge of the text from top to bottom
- Bullet points for list
- Bullet points for list
4. Show clear call to action
After reading the disclaimer, make it clear what the
is. Reading the fine print is hard enough, looking around trying to figure out what to do next can be more frustrating.
5. Keep the fine print easily accessible
Instead of filling the entire page with fine print which not many people read anyways, show links to the detailed information and keep it above the fold for users who would like to read that information. We used the headings of the sub-sections of the fine print text as the links so that it was easier for the users to scan down the list to see what the fine print contained.
After the initial resistance from the legal team, we finally managed to convince them of the value of these design principles and how they can help achieve goals on both sides – legal needs and user needs.
All I’ve done here is to barely scratch the surface. What is your experience in trying to keep the both users and the legal team happy? Share your stories in the comments below.