Most everybody would agree that website terms and policies are incredibly cumbersome. And of course - they're not designed to impart information in a user-friendly manner as much as protect the web-service from all manner of possible litigation. It's a defensive, necessary evil.
It's why sites like TermsFeed exist. Like many types of insurance, by law, everybody must have it.
The idealist in me thinks there is a better way. Some services are very good at making human-readable (as opposed to lawyer-readable) terms and policies. While it may not be possible to reduce the required legalese it should be possible to impart that knowledge in a more user-friendly manner.
At Kanshuu, when we do our workshops we often run exercises designed to craft the best User Experience (UX). One of these exercises is identifying all the all the interaction points a product has with its user.
To give a practical example, an airline has many interaction points: browsing the website, receiving an e-ticket, checking in, making an in-flight purchase, disembarking etc. The point of this exercise is to think not just about the most obvious, but also the often overlooked interaction points.
For web services, agreeing to terms and policies is one of these overlooked interaction points. Most people just click agree without ever looking at the document itself. It's just a necessity. Another box to tick.
But services that are serious about crafting the best user experience should be optimising this opportunity to stand out from the competition.
Imparting critical information to the user in an easy to understand format.
Understanding the Problem, Reducing the Scope
While making human-readable terms and policies is a worthy goal, the genesis of the idea really came from a change in such terms and policies.
With such a tight time frame with which to launch a service from this idea required a laser-like focus on one problem only. Focusing only on the changes in terms and policies was critical in this regard.
While it's subtly different, the requirements for the user are the same: understand what the terms and policies mean for them.
Again, most users will simply click 'agree' without looking at the terms or policies. Even if you want to see what's changed, it's often impossible to figure out what has changed; the old version may no longer be available and even if it is, it's far too long a document to reasonably identify what's changed.
So we knew that the solution should focus on changes to terms and policies and help users understand what has changed.
Luckily machines are very good at parsing large volumes of texts and comparing them. So the trick is figuring out how best impart this information to the user.
One of the early ideas was to have a web-app that allowed users to go through all versions of terms and policies for the services they used. User-defined version-control if you will.
However, such an app takes a lot of time to build. Time we don't have. So we thought, is there a better way to solve the same problem but with less engineering?
While reviled and scorned email is still a critical part of our modern business world. It's often how web services notify users that the terms have changed in the first place so users won't feel their inbox is violated if we send them an email to tell them what has changed too.
And so the idea of the product was shaped - a web application with no real user interface. The only output would be email notifications whenever there was a change to terms or policies that you were monitoring.
We achieved this by setting up a crawler that pings websites on a daily basis and compares the version of terms and policies to the previous day's. If there's a change, the service sends out an email. Not fancy by any means, but effective.
Naming the Service
For the longest time, the project had a code-name 'ToS Watcher' (Terms of Service). While descriptive, it's not particularly appealing or memorable.
After brainstorming plenty of ideas one theme stuck: using the word 'Ever'
It was a nice homage to Evernote, the genesis for the idea. It also conveyed that the service was watching 24/7
Once the 'ever' motif was set it was a matter of finding another word that would add something meaningful and have an available domain name.
While there are plenty of new TLDs (Top-Level Domains; .com, .net, .org etc.) all things being equal the .com domain is still king. Trying to remember a domain name is hard enough without having to think about whether it was a .co.uk, .net, or .xyz TLD.
So we banged in the word 'ever' into a few domain search engines and created a short list of words that made sense. Each domain search engine has it's own strengths so it's worth considering what kind of domain name you're looking for. I have a preference for Agile Domain Search, largely because its interface is nice, but it's also good for conjunctive domains, which is what we're looking for.
We eventually settled on the word 'Sentinel' for the second word as it was something protective. We wanted the service to be like a silent guardian. Always watching so you don't get blindsided when something happens.
And that's how the name EverSentinel came about.
With the name sorted the next thing was to consider design. To put a caveat out there, I'm not a designer so I apologise in advance if I insult any real designers out there!
One of the challenges when considering logo design is not just how it looks by itself, but how it looks along with its logotype (the name of the product/service/company).
With a logotype that consists of two words, figuring out this balance was the major challenge.
Ultimately we knew that the design direction had to be something that conveyed strength. We need users to feel like this is a solid, defensive service that protects them.
With this in mind, the logotype was quite easy - capitalised text is much bolder than lower case. Knowing this made the second choice easier too; having space in between the two words. With lower-case text, it's possible to capitalise the first letters and have the text together but this dramatically reduces legibility in the upper-case text. We did experiment with the idea of putting a symbol in between the two words '|' but it messed up the balance with a logo, which we wanted to keep.
The minimalist / symbol design ultimately was something that emphasised the logotype. Good, but it didn't have any meaning on its own.
The other two designs were much stronger. Ultimately we went with the vault-like logo as it made the most sense as a standalone logo.
As an aside the inspiration for this logo design actually came from a musical I watched - they projected a design similar to this onto a giant, billowing sheet with a gradient light. This was meant to simulate the looking out from the inside of an old iron watchtower but it looked like a vault to me.
From early on Yellow was a pretty obvious choice given its universal use as a sign of danger. The real challenge was finding the right shade of Yellow. In the end we went with a brighter choice, depsite the worse legibility as it emphasised the 'danger' elements.
We have a preference for minimalist colour palettes and with such a strong primary colour the remaining palette became shades of grey, black, and white.
While I often use sites like Adobe Kuler to come up with colour palettes, in this case, I just added varying levels of opacity to black to come up with dark colours.
Most printed legal documents tend towards seriffed fonts as it raised legibility over long pieces of text. However, the web is much more used to sans-serif and such fonts are often less heavy. Considering we're aiming to maximise ease-of-reading going with a sans-serif font was an easy choice.
With the rise of sites like freepik and noun project it's now easier than ever to utilise stylish icons without spending ages designing them. Since we knew we wanted to use icons to aid understanding of the service we pre-selected an icon set that covered 'digital' and 'business' themes for inclusion in the brand guides.
When considering business models for EverSentinel, Software-as-a-Service (SaaS) was an easy choice.
Advertising goes against the grain of selling to privacy-conscious users so that was a no-go.
When considering SaaS vs. one-off we like to think in terms of whether the user will continue getting value in the future, or whether the value is something that decreases or disappears over time. If it's the former then a subscription makes sense as they continue to get value out of your the service/product over time. If it's the latter then as time goes by they're being charged the same amount but getting less value - a surefire way to destroy goodwill and sustainable revenues, even if it works in the short term.
As EverSentinel is an ongoing service SaaS was the default choice.
Target User Groups & Pricing
Broadly speaking we identified 3 potential user groups. We ended up building the pricing model around these groups.
1. Privacy-minded individuals
While many people willingly give up their personal data to web-services in return for a free service, it's important to know what is happening with that data. When services change their policies many individuals may want to reassess whether they're willing to continue this trade-off of data for service.
For most users in this category, they're using services such as Google or social networks like Facebook in an individual capacity. This is essentially our 'free' tier in the freemium model.
2. Businesses that rely on 3rd party services to operate
Many technology companies, especially on the web, utilise a whole host of 3rd party services to deliver their product to clients. Hosting services like AWS, marketing tools like MailChimp, and payment processing services like PayPal come to mind.
We've always been in a position where we have to rely on 3rd part services to host our services, send emails, or handle credit card payments. As such, it's critical to understand what these services can do with our, and more importantly our clients' data.
For such companies paying a small monthly fee to monitor the multitude of services they use makes sense.
3. Large Enterprises
The final category of user we identified is the large enterprise. Modern enterprises have many departments all using a whole variety of web-enabled software solutions. While it may be possible to screen service terms and policies when agreements are first made, monitoring these hundreds of services on an ongoing basis is simply not feasible.
Yet, there is a very real danger that any of the software being used to be the gateway to a class-action lawsuit or loss of critical business secrets. For firms like this, the service provides a level of screening which allows a compliance officer or legal officer to actually monitor what is being changed on an ongoing basis and catch problematic clauses before they cause any damage.
Our expectation is that these enterprises utilise the largest number of services which increases our costs. They also have the most to lose from dodgy clauses so we priced this tier the highest.
🚀 Launch 🚀
The main drive behind 12 Startups in 12 Months is to get used to launching products. The secondary drive is to practice scope reduction and focusing on problems rather than solutions - something we advocate clients at Kanshuu.
The launch itself was fairly muted. We ended up sending it out to people who had subscribed to the email-lists we'd built on MailChimp and sending it out to some people in our rolodex to whom it seemed relevant.
It's since been covered in Betanews so we're considering sending it out to other journalists and see if they find the theme of increased transparency interesting.
We've also submitted to Betalist which has a minimum one-month wait before being featured (if at all) so will see how that goes.
While it wasn't a launch to massive fanfare, it also wasn't a launch to crickets, something we've experienced plenty of times in the past. We got people sign up for the service, despite the limited offering at the moment which signals some interest.
The best thing launching to an audience was getting instant feedback. We had people tell us it was a good idea and people tell us that they would get no value out of the service. Ultimately this is the value of launching sooner rather than later - getting real validation.
Follow the next startup