Safari is used by millions of people from computer novices to experts. My responsibility on the Safari UI team was to improve the web-browsing experience for all types of users.Ever since I joined Apple in 2009, I’ve learned a lot about usability, software architecture, and even how to be an engaging speaker.

My Responsibilities

  • Create concept mockups and prototypes for new features
  • Work with designers to polish features throughout the release
  • Deliver implementation of new features
  • Improve and maintain existing features
  • Present new WebKit features at WWDC

Features I have worked on

  • Safari 7+ and iOS (released after I left): Unified Toolbar, Bookmarks Sidebar, 3D Tab Browsing
  • Safari 6: Tab View, Smart Search Field, Bookmarks Bar Editing, Tab Bar Improvements
  • Safari 5.1: Full Screen, Multi-touch Gestures, Reading List, Error Pages, Downloads Popover, Privacy Preference Pane, Internet Account Setup
  • Safari 5: Reader, Top Sites, Cover Flow
  • Safari 6: Tab View, Bookmarks Editing

Challenges, Lessons, Thoughts

With a mature product like Safari, it’s hard to make new functionality discoverable without cluttering up the main UI. When proposing new features, our director always asks us:

What’s the story?

In order to be discoverable, a new feature needs to be accessible from the user’s existing workflow, and every step of using the feature should be part of the story that convinces the user that this feature is useful.

The story is also a reflector of the usefulness of a feature. During one release, we spent months working on a feature that was technologically advanced, visually pleasing, and solved a problem no browser has ever solved. However, we could not come up with a convincing story of how anyone would discover this feature, and had to scrap the feature. In retrospect, the reason we couldn’t come up with a story was that it wasn’t a part of any user’s workflow: most people would not be engaging in an action that this feature would have improved.

The most important thing I learned from Apple’s WWDC presenter training is:

Don’t make your audience try.

As the presenter, I should be loud enough that the audience can’t help but hear me and slow enough that they can understand me even if they’ve zoned out. Most importantly, I should show them how show them how my presentation solves their problems. Every audience comes with a set of preconceptions, concerns, and ideas, and a good speaker always addresses the audience’s thoughts first, otherwise the audience will be too busy holding onto their thoughts to absorb anything the speaker is saying. This knowledge has helped me tremendously in getting buy-in for new feature ideas.

Meeting the audience where they are is also very important to interaction design. Instead of introducing a feature as “did you know you can do this cool thing?”, users are much more receptive features that say “I know you want to do x, this feature will make x easier!”

I find it very interesting how good code design and good interaction design are so similar to each other: the product should be well-designed enough that the user can use it without trying to learn it. The only difference for code design is that the users are my fellow engineers, and the product is my code.