Web App Masters: Design Lessons from 350 Million

by Luke Wroblewski March 22, 2010

At the Web App Masters Tour in San Diego, Julie Zhuo described Design Lessons From 350 Million that outline how the Facebook design team creates experiences for Facebook's users.

The Facebook team is 15 product designers, 10 UI engineers, 5 user researchers, 4 communication designers, and one content strategists. How does a team of 35 design for 400 million users? Dive right in and try a lot of things.

1) Get your hands dirty.

  • At Facebook, designers write code.
  • Helps ease potential tension between designers and engineers. Technical designers help bridge the transition from design to development.
  • Mockups lie. They lack content and context. You need to use real content and page designs to understand how the design will work.
  • The more time you spend in Photoshop, the less time you are seeing interactions work.
  • Understanding the medium in which you work, informs your designs.

2) Design for the system not for the individual

  • It's not about any specific user, it is about the network
  • Facebook always get asked for a "recent visitors to profile" feature. But this feature doesn't just go out to one person, it goes out to the Facebook system and may negatively impact sharing.
  • People asked for a way to message all friends at once. Launched the feature but saw too many people sending irrelevant messages -not engaging. These messages began to clutter Inboxes so the feature was taken away.
  • Some features help make the network stronger. Friend suggestions focus on people new to Facebook so new arrivals have a good experience. They don't necessarily benefit long term Facebook users.
  • The most important thing for new users to do on Facebook is connect to friends.

3) Be data informed.

  • Focus on core goals. For Facebook the primary goal has been growth.
  • Growth team focused on optimizing the site to get new users
  • Example: looked at deactivation page and adjusted it convince people to stay by adding pictures of friends. Had a big impact, kept 1 million people a year on the site.
  • Being data informed does not mean you are data driven. Need to ensure you don't loose sight of the big picture.
  • People were not finding the Applications bar at the bottom of the page. Tried increasing the visual weight of the menu and 5x more people clicked on the button. But did not launch the feature because it did not fit with the rest of the Facebook UI
  • Reactivation emails are designed to bring people back to the site after a period of inactivity. Tried a few variations with people, notification teases, and news feeds. The version which teased people performed the best.
  • To understand the full picture of design decisions, you need to know how they perform.

4) Make bold moves.

  • Launched a number of features that did not go over well.
  • Many features had a negative reactions to site changes.
  • Big changes always elicit strong feedback
  • Small feature changes will only take you so far, you need to do bigger things.
  • Small changes can help optimize but won't change the landscape.
  • Instead of trying to bring more attention to the navigation at the bottom of the page, Facebook rethought the problem and exposed the navigation in the left column.
  • When the news feed reactions came out, the team realized they had something powerful on their hands. Decided to tweak the feature instead of removing it.
  • Beacon launch did not go well but it had a good idea at its core. That idea is now Facebook Connect and very successful
  • The greatest risk is taking no risk. Your product will go stale.
  • The light switch model no longer works. Facebook now uses A/B testing to test features before launching.
  • At the end of the day, even if users hate a feature. If it adds a lot of value for the Facebook system -will keep it.

5) Don’t fall in love.

  • Many features are no longer available on Facebook -things get removed.
  • In many cases it is painful to remove a feature both for users and design/dev teams.
  • Software is impermanent -always evolving. More than ever, our work is never over.
  • Example: share dialog went through many iterations (in 3 years, 11 versions). The feature had to evolve with the site and people's behaviors. Times changed and people began to share more publicly, so the feature needed to change.
  • There is no dislike button because you want to focus people on the positive and more options complicate things. Even small features end up with “death by a thousand cuts.”