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.
Marie Potel-Saville, founder and CEO of Dot's Paris Office.
A Service Level Agreement, or “SLA”.
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
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 contract 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.
We’d want them to feel that the information contained in the SLA template 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.
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.
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.
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.
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!