SLAs often end up causing more confusion than clarification - Marie Potel-Saville explains how legal design could help to create a user-friendly process.
We’re sponsoring the Legal Design Geek conference in London this October. Legal design is all about putting users first: as Margaret Hagan says, “focusing on the humans within the legal system.” We asked design gurus to take a look at some user-unfriendly legal processes - and how a design approach might improve them. This is the second in a series - stay tuned for more.
Hi! Who are you?
Marie Potel-Saville, founder and CEO of Dot's Paris Office.
What is an example of a legal document or process that isn’t user-friendly?
A Service Level Agreement, or “SLA”.
What’s wrong with it?
The whole idea of an SLA is to ensure that a given product or service will work up to the level of performance it’s supposed to deliver – and also what happens if it does not work that way. As a matter of principle, it should be an efficiency tool. The problem is that most SLAs are full of legal jargon which may be meaningful for the tech guys involved when setting up/integrating the service, but not the people using the service, who may have a limited tech background.
"We want it to be an ally, fast and problem-solving, so they can get back to work"
And what does that mean for the user?
Precisely, it means they can’t actually rely on the SLA at the time they need it the most: when the service is down. They feel it is just an admin document, or a tech-driven thing that’s not for them to use. It usually results in the SLA sitting in a database once signed, and problems being solved based on commercial relationships.
That could be fine – we don’t necessarily need a contract for everything, but if you think cloud services hosting for example, the most precious asset of a given company, e.g. its clients data, the way the cloud performs and what happens if it’s down really matters and cannot just be left to business talks.
That doesn’t sound good. How would we want them to feel?
We’d want them to feel that the information contained in the SLA is intuitive for them, that it fits well into their own tasks, that it’s clear and transparent as to how service levels can impact efficiency.
We want it to be painless when they’re at a time when they are already dealing with a pain point: that the service is down. It’s bad enough if the service is critical for their activity, they don’t need more complexity or hassle. We want it to be an ally, fast and problem-solving, so they can get back to work.
Check out the first post in this series on privacy notices.
So in an ideal world, how would we start if we built it from scratch?
We’d start with what the document is supposed to achieve: performance. Starting with the uptime, and describing clearly the steps if the service falls below that uptime, until it’s back to normal.
How might it look different?
Imagine an SLA that actually guides the user through the various steps, bringing to light what’s usually hidden behind technical acronyms. It could be a path, with milestones and meters: performance-oriented.
And how would the experience be different for the user?
In that path, the user would instantly understand which action he’s supposed to take, and what the provider will do. In terms of experience, it would be a relief, a seamless problem resolution journey.
What would we need to make it a reality?
Starting from the users in a legal design sprint where the user journey and in particular its pain points would be mapped out, on the basis of which a prototype would be created, then refined based on users’ feedback.
Thank you Marie! We are really excited to be putting all the above into practice with our own SLA, which is undergoing a design sprint led by Dot. Stay tuned for the results!