Today I am attending the WebGuild Silicon Valley Annual Conference in Santa Clara, CA. One of the keynote speakers was Marissa Mayer. Marissa is the VP of User Experience at Google. The format of the talk was a directed Q&A session, and then they opened it up to the audience at the end of her talk.
Marissa had some really interesting things to say, and I think that it is worth noting a few of my key takeaways. They are nothing but common user experience sense; Product managers everywhere should take notice.
On Google’s homepage/search simplicity
Google’s simple UI went like this: Sergei was an engineer, and didn’t want to build a “better” page. He just wanted to test his search engine. Initially Sergei didn’t even have a Search button. He figured the search field was enough, since the Return keyboard key worked well enough.
On Designing, Developing, and Launching products
Don’t overinvest upfront. Don’t overthink a product. Think lean from the getgo - not about everything it could do. Get it out there early, change it often. Getting it out there will determine if it’s going to take off; getting out there early will also beat the competition.
Google often walks away from revenue for the sake of the user experience. They believe that if they nail the user experience first, the revenue will come. Never compromise the user experience for the sake of immediate revenue. User experience is the best investment they can make.
Speed is at least important in user experience as any other factor. Don’t forget about speed.
On Social/Knowledge Search
Google is focused on social/knowledge search, and they’re looking at companies in Asian countries who have done a great job with the concept.
On advertising
No ads on the homepage. Why? There’s no content, so how could ads be well-targeted? It simply makes no sense. And if there is content, it still isn’t well-targeted, so ads might still not make sense. Wait until the user gives you explicit input about their interests; you can always target ads better that way.
– END NOTES –
You might hear people say that Google is a cold, machine-driven company that is solely focused on technology; that they don’t have any user experience representation or focus. Don’t believe the hype. They’re a big company that still operates its product teams as lean, mean, aggressive-as-hell user experience and business and engineering monsters.
As they spread themselves thinner, and become involved across more and more disparate verticals it will be interesting to see if Google can maintain their momentum.
I was unfortunately unable to attend BayCHI this week when Peter, Tim and Larry spoke on designing systems with emergent behavior. Lucky for me, Peter posted some of his thoughts and takeaways from the evening.
A couple of things Peter wrote struck a nerve:
Peter first says:
“There are no good user research methods of emergent behavior
The standard tools that a user researcher has tend to focus on an individual’s interaction with the system. Or, if we do engage with groups, we’re limited to the scope of groups we can interact with. So, how can user research inform the design of systems with emergent behavior? We need new methods and approaches that allow us to work with a crowd.”
Peter also goes on to say:
“Embrace the chaos
…I’m surprised that most companies don’t take the Amazon.com approach of testing designs with small percentages of the users and gauging behavior before unleashing it on the world at large.”
Companies do embrace the chaos.
I don’t know if most companies do it, but I know that all the big companies with massive user bases do it. At Yahoo and elsewhere, it’s called bucket testing. Based on any number of factors, including but not limited to revenue risk, research goals and time/budget constraints, a new rev of the product will be launched to a tiny percentage of the population. So when you have 400,000,000 users and you let 5% of them see the new product, you get a rich and reliable data set, as well as a wealth of information on how the product will be used, and how it will perform when you do open the flood gates 100%.
Bucket testing is constantly happening at Yahoo, Google, MSN, Amazon and others. Have you ever seen a new feature for a week or two, and then it vanishes into thin air? You were in a bucket test.
A Strong Statement
I know I’m going to get heat for stating that bucket testing is a user research tool, but I’m going to say it anyway: Bucket testing is a great tool for designing emergent systems. It is not the typical lab-based, or field-based “user research” that we all think of, especially because it happens after the system is designed. However, because of the limitations of human beings’ abilities to predict (unless there are clairvoyant UE people out there) what other people are going to do, bucket testing is the best tool to date that I’ve seen for informing my design decisions in SWEBs (Systems with Emergent Behavior).
As designing emergent systems become increasingly complex, bucket testing is possibly the best user research tool available; something that no amount of up front research can provide, and something that no design firm or user experience strategy firm can account for unless they are embedded in your company for a long-term relationship. I hated to say that last sentence given my consulting history, but it seems to be more and more often the case. It’s time for consultancies to innovate on how to provide this service in a long-term valuable way.
A confession
When I was first exposed to bucket testing, I hated the idea; I was also from a user experience consulting background. I loathed putting my hard work and Fantastic Design Decisions in front of a small piece of the population, just to observe and then tweak and change my minor failures in near-real time. But over time, I have actually learned to embrace The Bucket Test Methodology as a key tool in researching how users respond to the emergent systems I design, and making those systems or products better.
The other tool I should mention, which only few products and companies are lucky to have, is the loud-mouthed users themselves. If you design a product/system that people are passionate about, they will constantly give you, ahem, advice on how the system should emerge to meet their needs. For every five you hear from there are 50,000 that feel the same way. In this case it is your job to be the bullshit filter and improve your product accordingly.
Not the be all end all choice
Bucket testing isn’t The Best Way, or the only way to gain insight into a SWEB. In fact, in many cases, such as games, I don’t see how it has a ton of applicability. However, for large content-driven and transaction-driven and user-driven and recommendation-driven and algorithm-driven online ecosystems, bucket testing might well be one of the best tools at our disposal.
The key is being sure to make bucket testing not just a Product Management-driven exercise; involve User Experience folks from the get go. Otherwise, your bucket tests will be too heavily focused on numbers, and not on evolving based on behavior.
Oh, one last comment on Peter’s post. Many contemporary systems do seem to live in perpetual beta, and I think it’s fantastic. It is a clear philosophical shift from the engineering/shrink-wrapped wait-to-pay-for-the-next-release software model of Yore, and evidence that companies are trying harder to evolve their products at a rate which keeps up with our behavior. And I welcome that. It forces designers and engineers to work more closely; that historical separation are why products have sucked for so long.
It was only a matter of time before designers would start misusing the tag cloud form factor to represent an information architecture. Two that come to mind as I write this are CollectiveX and Yahoo Tech.
There is an inherent problem in using tags (or tag clouds) to make up for your IA laziness. Tags were born from a need to add findability value, insight, and delight to the giant mountains of information that pile up in online communities - they are the Library Science antithesis of a Taxonomy. They are sloppy. They aren’t controlled. They aren’t top-down. They are generated by the people for other people to discover - or not. I hate to say the words, but they go hand in hand with User-Generated Content. They are the DNA of folksonomies.
When designers or companies come along, and take something that, for the past few years has been The User-Generated Lighthouse at the Point of Information Overload, and turn it into a cheap way to navigate a controlled corporate vocabulary, we have to question their intent, or perhaps their lack of intent.
I especially wonder about the decision to place a tag cloud form factor in web sites/apps where there is a huge amount of comingled editorial and user-generated content - for the purpose of navigation of the designer’s Information Architecture. Was it done for the sake of being Web2.0? Was it done because structured navigation has become passé? Was it simply done without an argument for why it should be there? In the case of Yahoo! Tech the purpose of the tag cloud changes depending on your context. On the home page it is top level categories. Inside a category it represents popular searches withtin that category. Eh?
I certainly believe that editorial content and authentic media can coexist in the same information space. In fact I would say that they are symbiotic in many ways - a system of checks and balances. But designers need to question harder their motives to use certain form factors in user interfaces. And in the case of tags, tag clouds, and tagging, keep your Information Architecture out of my tags.
The conversation about what contributes to the success of online entities such as MySpace, del.icio.us, and YouTube, continues with Paul Boutin’s article ‘A grand unified theory of YouTube and MySpace’.
If its the only piece you read about this conversation, then I think it’s an appropriate argument - though I’m obviously trying to make this very post the only one worth looking at, if for nothing else, for it’s brevity.
Two key things to pull out is where in one place Boutin disagrees with the common opinion on the success factor of these sites, in that they have seen such success because of their “collaborative nature” and Boutin posits that it is because “They’re easy to use, and they don’t tell you what to do.”
The other is where Boutin suggests MySpace’s immense traffic numbers have something to do with its “puppylike accessibility”, and he agrees and quotes JJG (who wrote in BusinessWeek here) who said that the undesigned layout/format of the pages “sends a “we’re just like you” message to newcomers”. Boutin adds:
If tech builders want to hand the controls over to their users, shouldn’t they presume they haven’t thought of everything?
And he wraps up the article by giving us the secret to success:
The secret to success is to make everything one-button easy, then get out of the way.
Now I’m inclined to agree with Boutin, where he pulls together two very good points about design: Make it as easy as possible to use: no friction between the user and product. And 2, make it extremely accessible: completely relevant and meaningful to the user.
But his rules are only applicable to a certain kind of online entity, and so far limited to ones that have no hint of a business model. Besides selling ad space. So while the success of these sites has an immense amount to do with these things Boutin explains - what is going to happen when the need to create a profitable and sustainable revenue stream is forced upon these organic and overnight successes?
Flickr may have peaked in it’s numbers/traffic for now, but it has the advantage of a revenue stream paid by subscriptions (as well as advertising) that will fund further feature and product development to encourage new waves of adoption. Sure it’s not bootleg TV or homemade videos - but it already has a paying subscriber base and as we have all seen (in 2000) switching on pay-for services to what was once free, dramatically reduces further adoption and can drive all traffic to the next free and maybe even not-so-easy-to-use online entity.
So I’d like to add, that MySpace and YouTube’s success in maturing as online entities, now relies in their deliberate yet extremely sensitive integration of monetizing their services if they want to last anywhere nearly as long as Flickr or even Slate has.
Jason Kottke weighed in also here.