Working at Google / a Large Company

1. Design != Product Design

The mindset of doing design at school vs. at a large company is different. At school, you follow the user-centered design process, creating sketches, wireframes, high-fidelity designs, and interactive prototypes for rounds of testings. It’s an iterative process, but it’s relatively clean. Your small team owns the entire product, and progress in a somewhat linear path at a set pace, not to be disturbed by anything/anyone else.

Product design at a large company, however, becomes much more complicated. There is a division of labor that happens at a project level, a product level, and across the company.

First, to get your project done, you now have to work with your cross-functional partners, including your PM, engineers, UX researcher, UX writer, legal, marketing, etc. I definitely knew about this before joining Google, and I think almost every designer knows that collaboration is an integral part of our job. But what does this actually entail?

In such a team, each partner contributing to the project would definitely want to see the project succeed; however, they all have several non-overlapping projects on their hands at the same time. This means, for example, you might never get to conduct in-depth user interviews or rounds of usability studies on your design because your researcher is swamped with 8 other projects. Or you might have an ideal experience you want for your users, but because of your PM and Engineer’s priority and bandwidths, you’ll need to make a compromise and settle for a not-so-perfect alternative that is quick to build and test.

Second, instead of designing an entire product from scratch, you’ll almost always work on a couple of features within the larger product. At the same time, other designers are working on other features for your product, and there might be overlaps between projects you are working on. For example, you might be working on a tutorial for an important feature, while your teammate is exploring an onboarding tutorial for the app as a whole. If you each approach the tutorial in radically different ways, your users will be confused, and your engineers will need to do repeated work. In this case, you’ll need to think through those overlaps in advance, communicate with each other often, and align on how to approach different problems so that the changes you both make fit together within the larger picture of the product.

Finally, at such a large company as Google, the product you work on will probably share components or patterns with other products as well. For example, if you look at all the vertical apps under Google Play (Books, Movies & TV, Games), you’ll notice that they all share similar detail pages and purchase flows with the Google Play Store; all apps under Google Play, together with apps in other product areas at Google, would all share the same top bar and profile page managed by a dedicated team; they would almost definitely follow the material design guidelines as well. The sharing of components ensures consistency and eliminates repeated work, but it also creates a lot of dependencies. For example:

When the needs of different teams diverge, there needs to be lots of discussions and approvals on where and how each team can customize the page/components for their own needs.

Different teams have different timelines and priorities. When the team responsible for implementing the shared component is occupied with other priorities, all the teams that need this component would have to wait.

This division of labor is fundamental to how a large company manages to create and deliver consistent yet diverse experiences for its users. These concerns are not necessarily part of the user-centered design process we learn at school, but they are essential for product designers to understand in order to succeed at a large company.

So, what should you do to survive this new context?

2. Communicate, communicate, communicate

This is an essential part of the solution to all 3 problems I described above (3 problems… see how I said ‘communicate’ 3 times as well?). Talk with your cross-functional partners early to know their expectations for the project, their priorities and timelines, so that you can make the collaboration process smooth and easy for everyone. Talk with other designers on your team to know what project each person is working on, and plan to work on problems together if your work overlap. Talk with other product teams early if you believe that things you are exploring might influence or contribute to their products as well. Start the conversation early, so that you can set everyone’s expectations upfront, and avoid the situation when you spend weeks working on something, only to find out that it won’t work because of other team’s constraints, or that someone else has already created the same thing.

These are all easier said than done, and I’m still struggling to find the best ways to collaborate with everyone efficiently. I’d love to hear about your experience and your insights as well!

3. Be Clear and Concise in Meetings

Any project within a large company usually has a lot of stakeholders involved. Because of everyone’s busy schedules, it’s hard to get everyone into the same room, or even to find a 30-minute slot that works for everyone. Therefore, it’s highly important to be crystal clear and concise during meetings with them, and be super goal oriented.

Our stakeholders usually come from different backgrounds (Engineers, PM, UX, Marketing, etc.) and view the same project from different angles. The challenge with communicating with people with different background information on the project is that we tend to always imagine things and make assumptions on our own.

Imagine you ask 5 directors to read different parts of a book, and let them adapt the book into a film. You’ll probably get 5 radically different films with different settings, different styles, and different casts that hardly fit together.

That’s what we do as human beings. We create our own versions of reality in our mind based on what we hear during the meeting, what we care about, and what we know in advance. We use the same terms, and assume that everyone else know exactly what we mean by them, while in reality, a slightly different interpretation might totally lead the conversation astray. We come to the same meeting, with slightly different things to accomplish in mind, and end up leaving the meeting frustrated because of all the unexpected turns the meeting took.

Never assume that everyone else knows exactly what you are referring to. They don’t.

That’s why clear and concise communication is crucial. When you set up a meeting, begin with a clear agenda. Set expectations on what you are going to talk about in the meeting, and what you are not talking about. When referring to your ideas, draw them out, put a rough mock out there, and clearly pinpoint what you are referring to. Never assume that everyone else knows exactly what you are referring to. They don’t.

Being concise also means being super goal oriented. Since it’s difficult to have different stakeholders in the same room, you should probably skip the discussions that do not require them to be in the room. You should also consider how to frame the problem, and only provide the right amount of detail, so that everyone understands the problem, but is not caught up in minor details that are not relevant to the central topic of the discussion.

4. Plan Design in Phases

In school, you might be used to coming up with the best possible solution after several iterations, and show off the “ final” design. At large companies, however, it’s important to plan and think in phases. What should we include for our Minimal Viable Product (MVP)? Phase 1? Phase 2?

For a product with millions of users, conducting experiments and gathering data becomes really important, because a small change in style might result in a huge change in engagement and conversion at a large scale. It’s also important to isolate the changes, so that you know exactly what’s influencing the data.

For example, I’m working on recreating a page in our app (Product A) based on a similar page in a related product (Product B), and make some modifications to meet our users’ needs. I initially proposed a design that would change the whole structure of half of the page. Even though our team liked it, we were not able to proceed with it immediately. This is because for the next launch, realistically our immediate goal is to replicate the existing page in Product B and bring it to our product, and some bugs will inevitably be introduced during that process. Proceeding with a radical redesign of half of the page when those bugs are still there would confound our data. Suppose we see a decline in user engagement, we won’t know whether it is because of the bugs, or because of the new design.

That’s why I took a step back, and proposed 2 versions of the design for 2 phases. There’s an ideal version, which is what I want the page to eventually look like. Then there’s the temporary version that still improves the user experience a little, but doesn’t require a radical reorganization of the page. Since we know that we’re eventually redesigning the page, I also made sure that the temporary version was as easy to implement as possible, so that our engineers won’t spend a ton of time implementing changes that we know we are going to discard in our future redesign.

5. Don’t Lose the Process

Since joining Google, I’ve been working in a completely different context compared to where I normally do design at school. Sometimes, I was so focused on learning how to work within the company that I forgot the design process that I was so familiar with previously.

Therefore, I need to constantly remind myself that I am the expert on user experience. The context in which we work as designers might change, but the essence of the design process and designer’s mindset shouldn’t change. It’s still important to start with low-fidelity ideas, to quickly gather feedback from people, and to iterate on things. It’s still important to generate a ton of wild ideas initially, without being limited by timelines and engineering needs, so that quantity would lead to quality. It’s still important to ask why, to dig into the root of the problem, and to solve it elegantly through design.

I’m still learning every day and trying to figure out how to best do design in this new context. Would love to chat more about this and learn more about your experience on it.