Facebook and the downsides of software as a service
The tizzy created by Facebook's page design changes point out some valuable lessons that we should keep in mind as we head more into a SaaS and cloud-based world.
1. Choosing when to change
There are many differences between how shrink-wrapped applications and software as a service (SaaS) work, but one of them is that customers of shrink-wrapped software choose when, and if, they upgrade. They kick the tires to look around at the changes beforehand, download a trial, poll other users, wait for the .1 rev and the kinks to get worked out.
With SaaS, changes get pushed out without those wait-and-see possibilities. Facebook is discovering that this can lead to unpleasant surprises for customers, who have no say in whether they want to adopt them right then.
When something is embedded into the flow of everyday life in the way that Facebook (or Twitter) is for many people, any change, whether it's ultimately better or worse, is going to cause complaint. People get used to patterns of doing things. Even when you change their work-arounds, sometimes they don't like it.
2. Conversation is a double-edged sword
Having said that, on the flip side, SaaS is more responsive when there is feedback. It can turn around updates based on input more quickly, and obviously more universally. But do this too often and you whiplash your users with multiple changes that set and unset particular features, preferences, design decisions, and so on.
Facebook is going to have to tread carefully in the coming weeks as it decides how to respond to the considerable complaining about the new layout. Facebook is quite different from most "applications" because there are such a variety of ways that people use it, and the experiences that each user has are going to be quite different. (All the more so because of the openness of the platform.) That makes it hard to design for, and all the more important to check one's assumptions at the door about what people want to do with it, and what features will support those needs.
On a more macro scale, Facebook (and SaaS in general) are emblematic of the substantially two-way relationship that now exists between companies and customers. The real-time nature of the conversation--and with something like Facebook, the ability of customers to vocalize and organize--is a precursor to what the majority of companies will have to deal with in the future. As the "Cluetrain Manifesto" presciently argued, all markets are going to be more conversational in the future.
3. Don't design by committee
But that doesn't mean everything should turn into a design by (user) committee, or tyranny of the majority. That's not how excellent products get made. There has to be a balance between responding to feedback, and recognizing when you see possibilities that your users, for the time being, do not. Your job as a designer and a company is to create capabilities on their behalf, and not just implement exactly what users ask for. (Not in a high-handed way; users' needs and best interests should always be the focus.)
(It so happens that we had a very lively e-mail thread running around the frog offices about this exact topic recently. Do you stick to the vision or respond to feedback by changing the vision? The answer: "It depends." Not very satisfactory perhaps, but unfortunately basically true. There are well-known examples of hits and flops based on both approaches.)
Watch what happens...
We should all be watching very carefully how Facebook acts in the coming weeks as it responds to the conversation. It will undoubtedly provide lessons for the future for all of us.
Adam Richardson is the director of product strategy at Frog Design, where he guides strategy engagements for Frog's international roster of clients, envisioning and creating new products, consumer electronics, and digital experiences. Adam combines a background in industrial design, interaction design, and sociology, and he spends most of his time on convergent designs that combine hardware, software, service, brand, and retail. He writes and speaks extensively on design, business, culture, and technology, and he runs his own Richardsona blog. Adam is a member of the CNET Blog Network and is not an employee of CNET. 



This sounds like good practice for major re-designs, they could roll out the new design as a suggestion to users. More and more users will slowly adopt the new design by their own choice, when most have adopted it, then force the new design on the rest. As opposed to suddenly forcing a major design change on everybody at once.
As Facebook gets bigger I'm sure it gets technically more difficult to support old/new designs in parallel, but for a short amount of time it may help cushion the blow. I assume they must have an ability to do random bucket-testing also, like Yahoo and other large sites do. Though the lack of chatter ahead of the switch indicates that either they don't or they did not do it widely ahead of the change.
Keep all the ifs, buts and elses in line is a challenge, to say the least.
When you develop and deploy a single version, soliciting feedback and refining your design is a ton easier.
Lots of stuff has just been taken off that was once easy to find. The "random" stuff that appears on the right side is just dumb and has no relevance to anything. The "Home" page used to be nice with all kidns of stories and things your friend's were doing, now it just looks like twitter.
This facebook update was horrible. And it came after only a short time using the old one. I know a lot of people are getting tired of facebook and all this. Last night the vote for the new layout was 1+million against and 60k for the new layout, how can you ignore that?
- by Calvert_Dayton March 23, 2009 1:47 PM PDT
- Something that seems to get lost in this discussion is that Facebook (et al) isn't simply a software solution <i>or</i> a service. In fact, it's a community. The people using it aren't really just software users in the traditional sense. By joining up, they become citizens of a virtual society.
- Like this Reply to this comment
-
(5 Comments)The difference between a social networking site and SaaS in general is that if I do my taxes online or use a web app to write a document, create a spreadsheet or mind my appointments calendar, my user experience has little if anything to do with how many other people are using that application or who they are. The application/service succeeds or fails based on virtually the same factors that apply to any other software solution, regardless of how it was delivered or whether the code runs on my local PC, a remote server or some combination of the two.
With a social networking site however, the lion's share of the user experience depends almost entirely on the other users. The specific collection of scripts and hardware that provide the infrastructure for interaction between users becomes almost incidental in that context, really notable only to the extent that it may enable or impede / degrade that interaction.
I've seen it mentioned with more of a whiff of condescension in some recent articles, that users of a social networking service may come to feel a certain sense of propriety about it. I don't happen to feel that sense is in any way misplaced in that the users themselves are, in fact, the star attraction in this case. People tend to feel much the same about the brick and mortar communities they live in and their public works. An important difference though is that a brick and mortar community can't build a new street right through the back yard of every single one of it's citizens on the same day.
On a side note, I wonder if any of the social networking have devoted any significant research to the social dynamics of online communities in designing those infrastructures. You could insert an engineer joke here, but I think that any really competent system designer or project director might consider that an important part of requirements gathering for building such a thing.