<acronym id="60qqi"></acronym>
Showing posts with label eula. Show all posts
Showing posts with label eula. Show all posts

Tuesday, July 5, 2011

Designing Terms Of Service Is As Important As Designing A Product

Dropbox revised their Terms of Service (TOS) over the long weekend. That triggered a flurry of activities on Twitter. Dave Winer even deleted his Dropbox account saying that he would revisit it once the dust settles. A lot of people concluded that there's nothing wrong in the new TOS and that people are simply overreacting. And then Dropbox updated their blog post, twice, explaining that there is nothing wrong with new TOS and cleared some confusion. I would let you be the judge of the situation and the new TOS. This post is not about analyzing the new TOS of Dropbox, but it's about looking at more basic issue in product design. What we witnessed was just a symptom.

Let me be very clear - your product design includes getting the TOS and End User License Agreement (EULA) right before you open up the service. The way the most TOS and EULA are worded, an average user can't even fathom what the service actually does, what information it collects, what it shares, and most importantly what's that it absolutely won't do. It's ironic that the simplicity element of Dropbox's design — there will be a folder and that will sync — made it extremely popular and when they designed the TOS, they had to publish a blog post with two updates and 3000+ comments to explain and clarify the new TOS to the very same users. There's something wrong here.

For a product or a service to have a great experiential design, it's absolutely important to get the TOS and EULA right upfront and even validated by end users. People release their product in beta and go to a great length to conduct usability study to improve the product design. Why exclude TOS?

I have worked with some great lawyers, but they don't make a good product designer. I'm a big fan of constraints-based design. Lawyers are great at giving you constraints - the things that you can and cannot do. Start there. Get a clear understanding of legal ramifications, ask someone other than a lawyer to write a TOS, get it signed off by a lawyer, and most importantly validate by end users. Then, start the product design using those constraints. If you feel too constrained, go back and iterate on TOS. Drafting a TOS is not different than prototyping a product.

I would rather have bloggers, thought leaders, and end users critique the product design on my blog instead of TOS. I would love to work on that feedback as against getting into a reactive mode to stop the bad PR and legal consequences. Thomas Otter involve them early on. The lawyers are paid to be risk-averse. As an entrepreneur, you need to do the right thing and challenge the status quo to innovate without jeopardizing the end users. It's a tough job, but it can be accomplished.

I don't want to single out Dropbox. There are other companies who have gone through the same cycle and yet I don't see entrepreneurs doing things differently. In this process, the cloud gets a bad rep. What happened to Dropbox has got nothing to do with what people should and should not do in the cloud. That would be a knee-jerk response. The fundamental issue is a different one. Treating symptoms won't fix the underlying chronic issue.
<acronym id="60qqi"></acronym>