Gmail: Designed to be joyfully simple
A behind-the-scenes look at how Gmail's first UX designer thoughtfully shaped Gmail into a product for the people.
I first met Kevin Fox in 2004 when he visited Carnegie Mellon University on a Google recruiting trip. At the time, he told me about an email product he was working on that had just launched in beta. I somewhat reluctantly signed up for a Gmail account (that I still use 20 years later) and joined Kevin at Google the following year. I recently sat down with him for a long chat about what went into the initial designs of Gmail. This is a long one, but there are so many gems of wisdom in here. Enjoy!
In 2001, most of the world was enjoying the novelty of email for daily life, work, and school. But an engineer at Google, Paul Buchheit, was fed up with how slow email was. So he set out to build a better email client.
The project started out with a technical challenge: to make email fast. But it ended up becoming something more — a far superior email client that was easy to use and loved by many, thanks in part, to the efforts of Gmail’s first UX designer, Kevin Fox.
Issues with Email
Email had been around since the 1970s and gradually expanded until the 1990s, when it started to take off. By the early 2000s, 500 million people were using email. Email was still novel for most people and it was far better than the alternatives of sending letters by mail, making expensive long distance phone calls, or managing piles of physical papers.
But Paul saw several issues with the existing email products. Email was slow, it had limited storage and functionality, and spam was a growing problem. So he assembled a small team of engineers to start building a better email application. The team had several product goals:
Email should be fast.
Nothing should need to be deleted.
Email conversations should live together.
Email should be searchable.
Spam shouldn’t be an issue.
The Gmail engineering team made good headway on speed, conversation grouping, and search indexing. They built a rudimentary interface to facilitate their back-end work and to test the viability of using dynamic HTML (DHTML) and Javascript.
The initial interface looked like this:
Around this same time, Kevin Fox left his role as a UX Designer at Yahoo to get his master’s degree in Human-Computer Interaction at Carnegie Mellon University. When Kevin graduated in 2003, he joined Google as the 8th UX designer.
Kevin was assigned to Gmail, as its first UX designer, and was tasked with designing a better user interface. To Kevin, Gmail (or Troutboard as it was initially called) looked like a bug-tracking system. It was all utility, no aesthetic, and nothing about it said “email.”
The team had focused on building the core functionality. But it was Kevin’s job to shape it into an email product that worked well for people and felt like Google.
Initial Designs
At the time, Google had only launched a handful of consumer products including Web Search, Image Search, Groups, News, and Froogle (shopping search). Initially, Kevin tried to apply the design and architecture models from these existing Google products, drawing heavily from Search, Groups, and News.
Kevin started by designing pragmatic solutions. His first designs to be implemented were loosely based on Google Search's layout, with a later version incorporating the left-hand navigation from Google News.
But nothing felt quite right.
Kevin eventually realized that Gmail, as an “application,” would require its own unique information architecture and interaction models that didn't yet exist in other Google products.
To inform his design process, Kevin also studied other webmail apps. Gmail would need to attract people away from existing webmail clients, so it had to feel familiar and immediately comfortable to existing webmail users.
He examined the interaction patterns of popular webmail applications like Hotmail, Yahoo Mail and SquirrelMail. He stripped the concept of email down to its essentials, using common interaction patterns as a foundation that he could then expand upon and enhance.
Kevin explains:
“I had been a user of Pine and Outlook, but I focused more on users migrating from other webmail clients like Hotmail, Yahoo Mail or SquirrelMail. I thought it would be an easier sell to get webmail users to switch to Gmail than to get people to move from command line interfaces (like Pine) or desktop apps (like Outlook).
I also thought desktop clients had over the years become crowded with too many controls and options, and trying to make an Outlook user happy on day one could only happen by sacrificing Gmail’s product’s ‘clean sheet’ design advantage.”
Explorations
Kevin then took the liberty to explore radically different approaches. He set aside his preconceived notions of email and considered questions like…what was email?
What if email was in 3D? What if email was organized around contacts (including all past context with that person)? What if email was merged with instant messaging (and emails were like IM responses)? What if email was more of a Star-Trek-like experience?
Kevin designed conceptual interfaces for these ideas, like this Star-Trek LCARS inspired UI (that actually referenced a person’s real email content):
He also considered how an existing webmail user would find their way around this UI. How could he translate their knowledge, skills, and habits into a new UI so they could find the familiar handholds and be able to use it right away?
With each outlandish idea, Kevin selected a few elements and dialed them back to something practical. He repeated this cycle of broadening and contracting several times, each time building a stronger foundation of which UI elements he was confident would work.
“Each time that I let go of a restriction and broadened my exploration, I had a stronger foundation of things that I knew would work. So I could keep those elements and then put the rest in a cup and roll the dice again and see how it worked and felt. Like playing the game of Yahtzee — until I finally got something where all of it was cohesive and enjoyable.”
Bit by bit, Kevin began to solidify elements on the UI. In the iteration below, Kevin merged elements from the earlier “Googley” designs with some of the visual cues from the Star Trek UI concept, like the “fork” element, rounded corners, and a softer color palette.
Kevin felt the colored fork element visually connected the left-hand navigation tab with the content being viewed (like the inbox, in the example above). It showed a clearer information hierarchy than simply highlighting the selected tab on the left.
At the time, other Google products used fully saturated primary colors. Kevin introduced a lighter, more pastel color palette, so that he had more visual range to indicate the hierarchy of different elements without them clashing on the page.
In 2004, rounded corners were not common on the web (they required using images and Javascript). But in a web application, Google’s typical sharp, angular corners felt more like generic supporting structure. Kevin wanted something visually friendlier that conveyed the relationships between the different UI elements. So Kevin introduced rounded corners into Gmail’s UI.
“This was especially important when designing the ‘conversation cards’. A flat, angular design didn’t adequately convey that they were individual stacked objects, so I tried a more skeuomorphic design, adding roundedness, a bit of shading on the card itself for depth, and a bit of drop shadow for showing that they’re stacked on other cards.
Once the card design was dialed in, they felt too organic and out of place with an angular UI, so the roundedness of the UI elements helped unify the site’s character.”
Kevin was strategic about how he introduced the idea of rounded corners. In leadership reviews, an entire design could be tossed because of a small design decision an exec didn’t like. So he made a mid-fidelity mockup with corner radii that could be easily adjusted to four or five different amounts of roundedness.
This changed the discussion from “should we do rounded corners?” to “how rounded of a corner do we want?” “None” could have still been an answer. But by providing a few options, Kevin gave stakeholders the ability to weigh in on a specific design detail rather than just reacting negatively to one element and discarding the whole idea.
User Research
While Kevin was designing — whether brainstorming, sketching, or building his designs in Photoshop or HTML — he constantly thought about how people would experience the product. He put himself in the mindset of someone who used existing webmail products. Then, using a user research technique called cognitive walkthrough, he stepped through key tasks asking:
Would the user try to achieve the result?
Would they notice that the correct action is available?
Would they associate the correct action with the result they're trying to achieve?
Once the action is performed, would the user recognize that it has progressed them to their goal?
Kevin’s design decisions were heavily influenced by these cognitive walk throughs. He felt they allowed him to freely experiment with novel solutions, while also ensuring he didn’t stray too far and alienate users.
“Prior to testing that brings in actual users, cognitive walkthroughs are the most effective tool I know of that will let a designer experiment with novel solutions to already established needs while helping prevent the designer from moving their solutions so far away from those that already exist as to alienate the users of products that meet similar needs.”
Kevin also did plenty more formal and informal research. One limitation of trying to user test a product like Gmail was that it was just a simulation if people weren’t interacting with real email content. So Kevin asked a colleague if he could have access to their personal email inbox. He copied all of their messages and coded them into his HTML demos, so he could observe them interacting with real content dynamically. With their permission, he modified and then used this content with other research participants as well, so that the content resembled a “real” inbox.
“So I actually had real content, which is a lot messier, but feels much more authentic to the user. I think there's an element there of things actually being real versus being made for a ‘best case’ scenario. The best case looks pretty. But then when you start plugging in real data or hitting different building constraints you can see more clearly what design decisions work in the real world and what problems only show up when the data is real and messy.”
Kevin and the team did a lot of internal usability testing as well. Several people within Google started to use the in-progress builds of Gmail. This was known as “dogfooding” and was a great way to collect a lot of feedback quickly and easily. Quantitatively, dogfooding allowed the engineering team to analyze how fast the system was working when handling high email loads.
Qualitatively, dogfooding allowed Kevin to understand how people experienced the product. In additional to traditional usability testing, the team also conducted longitudinal research studies. They closely followed a small group of first-time users for six weeks to better understand people’s initial interactions and how they adapted and used the product as they transitioned into expert users. Most importantly, these “dogfooders” were experiencing using Gmail with their own, imperfect data.
“While many googlers dogfooded Gmail with their work email, a smaller number of googlers and ‘friends and family’ users were invited to use it for their personal email. This was especially useful because the behaviors were very different. The average conversation length in personal email consisted of 1.2 messages while in work email it was closer to 8 messages. Thankfully the interface seemed well-suited for both.”
Building in HTML
Kevin didn’t just design a fancier front end in Photoshop and hand it over to the engineering team to build. Instead, he recognized that the first audience for his design concepts was the Gmail engineering team. The engineers had worked hard on building Gmail for years, cared a great deal about the product, and wanted to see it work as well as possible.
If Kevin had just designed a static front end, the engineers would have had off-the-cuff reactions to it and likely would have dismissed many of the elements that Kevin thought were important. So Kevin coded his designs in HTML and shared those working versions with the engineers. This allowed the engineers to interact with the UI in an unscripted way and experience the differences that Kevin was proposing.
“If front-end developers just see the mocks, they don't feel like it's their thing. It’s too far removed. But when they can actually bounce around in the UI with some bits of interactivity, so it feels like it's actually their thing, the thing that they have built, it gives them a much stronger connection and feeling of co-ownership in the design, and they end up more excited to incorporate the design into their code.”
Feature Details
Gmail was the first email application to truly leverage the electronic aspect of email. Before Gmail, email was just a digital copy of physical mail. There were folders, an inbox, and a trash can. Just like you would process physical mail, you could read an email message and then toss it in the trash or file it away in a folder. Gmail was the first email app to create new, digital-native metaphors, rather than just translating physical forms into a digital medium.
When Gmail launched with 1GB of storage space, it turned the very idea of email on it’s head. Other email accounts offered 2-5MB of storage; Gmail launched with 200-500 times more space. No longer was email a small inbox where people processed messages and either moved them into folders or deleted them. With Gmail, email became a digital archive where you could hold onto things for safekeeping.
A key feature of any digital archive was re-finding content. Gmail leveraged Google’s search capabilities, allowing people to search their email by keyword (like SFO or Delta). This truly began to leverage the E in electronic mail and spawned new features that had not been possible with physical mail, like conversation threading, starring, and labels. These features required significant attention to craft a great user experience.
Conversation Threading
The Gmail team believed strongly in the idea of conversation threading — clustering all emails from a single “conversation” into one, sequential group. Before Gmail, every email lived as a completely separate message, whether you were replying to another message or writing a brand new message.
For most people, this wasn’t a problem — they just didn’t have that much email. But because the engineers working on Gmail were using email frequently with groups of people, this was a growing problem. It was clunky and cumbersome to try to have a progressive conversation with multiple people via email.
The idea of conversation threading wasn’t new. Academics had been pondering and debating the topic for years, mostly concluding it was impossible. There were so many edge cases, like someone replying to an earlier message or a conversation forking, which made it impossible to precisely capture the thread of the conversation.
However, the Gmail team believed conversation threading was not only possible, but necessary. As Kevin read the academic research studies, he realized everyone had tried too hard to expose the exact hierarchy of messages — prioritizing precision over usability. Kevin and the engineers prototyped many options for how conversation threading could work.
Through these explorations, Kevin realized one fundamental truth:
The value of having a whole conversation in one place far outweighed any minor confusion from edge cases.
Additionally, Kevin concluded that two things always needed to be visible:
The newest unread message
A reference to the other messages in the thread
Kevin explored and iterated on how threaded messages could be displayed. Eventually, he turned to physical index cards. Playing with these physical cards gave him the idea to stack messages on top of each other with peeks for each message in the conversation stack and the most recent message on top (as is shown in the UI below).
Starring
With a huge amount of email, the team believed people needed a way to indicate something was important. The concept of “importance” was vague. Kevin explored many ways people could indicate importance, including thumb tacks, flags, and hearts. But conceptually all of these failed.
A thumb tack indicated you were “tacking” an email to get back to it later. A flag felt more like you were flagging it as an issue or to review later. Hearts or favorites conveyed positive emotion and didn’t work with the spectrum of content people would want to mark as important.
Finally Kevin arrived at the idea of stars (which weren’t common in apps before Gmail). Conceptually, a star indicated importance, but neutrally so. Starring an email didn’t prescribe how a person would interact with it and supported different people’s unique workflows. Stars were just a lightweight way to elevate or prioritize an email above others.
“Starring is just a gesture that gives the message some level of increased importance, but doesn't prescribe what makes it important or how you're going to interact with it later. There are several ways you can interact with starred things. A starred thing can catch your eye later, especially in search results, or you can see a list of just your starred things. It doesn’t have to be a ‘to-do’ list. It doesn't have the weight of ‘I'm making a decision about this.’ It's just a more lightweight gesture. Also the star is friendlier.”
Labels
Labels have been, and continue to be, one of the most contentious features of gmail — even twenty years later. Prior to Gmail, email applications used the concept of folders for you to organize your email. This was modeled after physical mail, which you could organize inside of literal folders in a filing cabinet.
People understood the concept of folders and used them for things like vacation planning, receipts, etc. But folders had one big shortcoming. Like physical pieces of mail, emails could only live in one folder at a time. So for example, if your purchased a flight, that email confirmation had to live either in your vacation folder or in your receipts folder. There was no search capability, so this could require some hunting and pecking to re-find content.
So the Gmail team invented a new conceptual model of labels instead of folders to organize emails. Labels didn’t put emails in any one fixed place. Emails just existed and any one email could have multiple labels applied to it. This meant that your flight receipt could be grouped with both your Florida vacation and your receipts.
The idea of categorizing emails into folders was deeply engrained for people. This was likely especially so since it mirrored processing mail in real life. It was challenging for people to make the conceptual shift to labels. This feature was iterated on for years after Gmail’s launch.
Ultimately, because search worked so well, it largely made labels moot for many. Rather than having to be organized and label incoming messages, people could generally just archive everything and search for anything like “SFO JFK” or “kitten immunizations” to easily find what they were looking for.
Selling the Idea of Gmail to People
Gmail was ahead of its time. Like most early products at Google, the team was building Gmail for themselves — for well educated, tech-savvy, affluent engineers who used email for work frequently and who had a lot of messages. This was really different from how everyday people used email at the time.
Most people were content with 2MB of storage. They communicated with email more casually and didn’t have a lot of content or contacts. The shift from physical to digital mail satisfied most people. And being able to use Yahoo! or Hotmail provided people with a permanent email address (instead of being tied to their university or ISP).
So Google had to position Gmail as a far better email solution, and Kevin had to make it frictionless for people to get started using Gmail.
“I could have designed an entirely different UX/UI than those of existing email clients. At best, some users would have given it a shot alongside their existing email client. Maybe some of them would have eventually switched to that Gmail. But to be successful we needed a solution that most users would be so comfortable with that they wouldn't miss their old client in any way. Switching to Gmail meant changing their email address, and that wasn’t something that users would do lightly, so they had to be very comfortable with the product very early on.”
Designing for Joy
Most people would think of email as a utilitarian application and optimize the UI around the efficiency of completing key tasks. But Kevin took an unexpected approach: he designed for joy. Not joy in the playful, whimsical sense. But joy in the sense of simplicity, approachability, and efficiency.
At the time, Kevin believed any website fell into one of three categories: reference, tool, or experiential. e.g., Google Search was reference, Yahoo Mail was a tool, and there were a lot of “just art experience” sites at the time. But while he was working on Gmail, Kevin started to soften his view of these distinctions. While primarily existing in one of these categories, any website could have influences from the others. So while Gmail was at its core a tool, its search functionality also made it a reference site, and there was also the opportunity to add experiential joy.
Kevin wanted to design Gmail to be a well functioning tool whose UI was so simple that the interface got out of the way. People could just simply do what they came to do, and this would bring them joy.
“I'm talking about the joy of confidence. You know how to use something — it’s frictionless in how the user interacts with it. The user doesn’t have to think about how to use the tool and instead their reflexes do the work, and the UI gets out of the way. But at the same time it has a visual setting that puts them at ease, and it helps them down the path when they're doing something novel they haven't done before, so they hit the right thing without having to work hard to figure it out. That makes for a joyful experience.”
A product for the people
Gmail reshaped how people thought about and interacted with email. The combined features of speed, unlimited storage, search, spam prevention, and conversation threading were ground-breaking. By the time it launched, Gmail was a thoughtfully designed product with an incredibly well-engineered front and back end.
Kevin thoughtfully designed, tested, and iterated each feature. But more importantly, he stitched all of the features together into one coherent product. He designed the information architecture, interactions, flows, and pixels. He provided the right hand-holds for people to quickly on ramp to Gmail and have a joyfully simple experience (that was exponentially better than other email products).
Between designing for joy, pushing the boundaries of what email could be, returning to pragmatism, and coding up his own ideas, Kevin designed a product for the people.
“Gmail definitely wouldn't have been a success if it didn't have a good UX design, but a good UX design doesn't necessarily require a UX designer.
A year after Gmail launched Google Maps came out and blindsided Google’s UX team because the product was developed without a 'UX designer' and it was amazing.
They produced a tremendous design, without being 'UX designers'. The truth was that the UX skills existed within their team without anyone holding that job title, and it worked very well for them and the product.
Bonus material: When the project was a few weeks from launch, Kevin wrote the following document on the six different types of Gmail users he had observed and designed Gmail for. Which type of Gmail user are you?
Using data gathered from the internal testers and the three rounds of usability tests, I've made a list of the six general Gmail user behavior types. Not everyone takes advantage of all the features that Gmail has to offer, but most people end up using a subset of the functionality to meet their needs.
Caveat #1: While I've made six groups, I don't have much data on the distribution of users across these groups, since the 'real world' is so different than our current user base. Caveat #2: These personas focus on use of the Inbox, archive, labels, and stars. It doesn't try to categorize the lower-level reading behavior (e.g. archive, archive+next).
Sally the Archivist
Sally sees the Inbox as a literal 'in-box'. Things in the Inbox are to be dealt with and moved out, either archived or trashed. Sally judges how much work she has to do by how many items are sitting in her inbox. If Sally uses stars, it's only to mark something as 'special' so it'll catch her attention as important when someone replies to a starred thread, or when it comes up later in search results.
Irene the Inboxer
Irene spends all her time in the Inbox. She doesn't use labels much, if at all. Irene leaves things in the Inbox after reading them. When she reads her mail, she'll either start from the top and keep moving down until she gets to the messages she's already read, or will start at the oldest unread message and work her way up. To Irene, messages that have fallen off the first page of the inbox are effectively archived. If Irene uses stars, they're to mark a message for follow-up, and the 'Starred' view is Irene's to-do list.
Dan and Stan the Multiple Inboxers
Dan and Stan are like Sally but they get email that falls into easily-identifiable categories (e.g. mailing lists or mail from small specific groups of people). They both set up filters to automatically route their email from various mailing lists or people into specific labels, bypassing the Inbox. They see each label as other inboxes to go through. To them the 'inbox' is just the 'general inbox' full of the message that didn't automatically fall into one of the category inboxes (labels).
The difference between Dan and Stan is that Dan removes labels from messages when he's done with the message, 'tossing them from the category' the same way Sally does with her inbox. Stan, on the other hand, is more like Irene; he lets messages stay in whatever label-folder they land in, and uses either stars or read-unread status to tell what hasn't been addressed yet.
Harry the Hand-sorter
All of Harry's mail lands in his Inbox. When Harry reads his messages he decides their personal fate, whether it's to be deleted or to be put in to a label. Harry has a bunch of labels, but not many (or possibly any) filters. When Harry needs to find a specific email he'll turn first to the appropriate label and page to the right time period.
Tonya the Trasher
Tonya equates email with voicemail. Her Inbox is her list of new messages, and she throws them away as soon as she's done with them. When she has a message that contains information she's certain she'll need later, she'll save it as a text or word file on to her computer. Tonya doesn't use labels or filters.