What I've Learned at Google as a Designer

I joined Google back in October. Joining a company of Google’s size and scale has been quite a revelatory experience.

Friends and old colleagues often ask how working at Google is different after having worked at a series of startups — in trying to answer this question, I came up with several instances of learnings through my own experiences the months. I feel sharing these can help many others in similar situations, but I did this in a way that it is an advice to my own self so I can read and re-read these as a reference.

So here we go in no particular order —

All your teammates have great ideas on what a good user experience is and this is why you should consult as many people as you can and involve them in the design process: Consult your PMs, Eng, Front-end devs, fellow designers and more. This is often tiring but rewarding. By bouncing off early ideas on paper with the engineers, I’ve often successfully narrowed down explore-worthy approaches to 1 or 2 good ones and saved myself time and energy. This also helps build great relationships with engineers as they are rightfully included in the process.
Learn to stay quiet and listen intently and do not just listen to respond: Oftentimes I’ve saved myself them embarrassing moments by staying quiet the extra 10 seconds. While it’s true that there are no stupid questions, there are definitely mistimed ones that could’ve waited for the right moment or context.
Share your work early and ask for feedback often: Internal culture really values sharing ideas and approaches early and often. Share from day 1, call it work in progress and highlight the areas that you want feedback on. Early requests for feedback are welcomed and appreciated (so much so that this is pretty much a norm) and also help you get the inputs sooner than later. Why do this often, you ask? Course correction in a design project is extremely valuable and necessary. By sharing often you efficiently keep yourself and the work in check — it saves time and effort.
Refrain from committing to a solution early (a.k.a. Don’t get married to a solution): You already know this one but it’s easier said than done. Most aversion from designers, when faced with critical feedback, comes due to the amount of effort it takes to make large-scale fundamental changes to designs in advanced stages of a project. One way to circumvent this trap of Sunk Cost Fallacy is to set up your own malleable design system that helps you iterate quickly and iterate a lot — for me this has been a Sketch template with a collection of nested symbols (it helps me multiply a small effort into large and quick variations in designs that help propagate a discussion). When you explicitly make an effort to remain preoccupied with the problem by not seeking quick closure with the next reasonable solution you find, you increase your odds of coming up with a more formidable outcome.

Most aversion from designers, when faced with critical feedback, comes due to the amount of effort it takes to make large-scale fundamental changes to designs in advanced stages of a project.

Don’t speak for other people: If a discussion is at a point where someone will have to chip in with their inputs, always say so and mark an action item in their name so they know things are waiting on them. Do not respond on someone’s behalf.
Be willing to say ‘I don’t know the answer but I am going to find out’ or ‘I don’t know if this is the right solution but it’s the one we should go ahead with and test it out.’: You aren’t paid to have all the answers, you are paid to find the answers.
Do not discount the value of ultimately getting things done: Ideas float around and evaporate; only tangible outcomes survive time and people.
Do not sit on things without putting down an end date estimate and communicate delays in advance to your team: Be accountable and give your team the heads up early especially when things are waiting on you. Garner trust and reliance by delivering on your word.
You can judge leadership by how they handle conflict: I’ve realised that the inability of leaders to deal with conflict and a healthy difference of opinions can hinder progress of the team and product tremendously. If carried on for long, it can even debilitate mutual reverence between your team members. Inviting constructive conflict and having a process to still move forward is a mark of good leadership and this is one of the core tenets of the Google culture — a welcome change.
Have awkward communication fast and as soon as the situation demands it: Procrastinating on speaking up will only make it worse and make discussing it more difficult later on.
No help goes unnoticed: Be helpful to your teammates and colleagues. But more importantly, proactively inform them that they can reach out to you when in need of help. Many people shy away from asking for help until probed and made comfortable to do so.
Be mindful of the ‘thousand feet view’ of your product and journeys when you’re designing: Don’t lose sight of systems thinking and the larger and complete picture. Being able to zoom into the pixel-perfect details and zoom out to the complete user journey and the holistic user experience is what elevates your value as a designer and truly maximises your impact.
Your Product Manager is your best friend and if you are as lucky as I have been to have a chance to work with a great one, leverage the opportunity of forming a great relationship with them: Set up a regular feedback loop with the product manager and build a relationship where you are both invested in the success of the product. I can walk up to my product manager and have a discussion on a feature or an approach and he’d entertain it, the same goes for me when he comes up with the ‘Hey, what if we…’ conversations. Having an always-open line of communication with your manager, driven by mutual respect and an assurance that something good will come of it at the end of it is a luxury. I really wouldn’t be half as good a designer if it weren’t for the great product managers I’ve had a chance to work with.
Even a little user research and insights you derive from a small sample of users go a long way into establishing a common ground amongst multiple stakeholders: The research findings and the report gets talked about and referred by people on your team every now and then during ideation and brainstorming phases. Designers and researchers owe the rest of the team this visibility into the user’s world through extracting and sharing the insights.
As much as time permits, all functions participate actively in research studies: Although UX researchers conduct the research studies and prepare reports, it is strongly encouraged that all functions of the product team participate in the studies. As a designer, my takeaway from the studies is to understand the user as much as possible and form meaningful connections between micro & macro design interactions and real-life user situations (whole or part user journeys). Design discussions start manifesting into decisions as you form these connections that are grounded in the user’s reality.

Design discussions start manifesting into decisions as you form these connections [between design interactions and real-life user situations] that are grounded in the user’s reality.

Be a respectful and free-flowing verbal communicator: Be respectful (and mindful) of other people’s opinions and let them complete their train of thought or a point before you respond with yours.
Cultivate a disciplined meeting etiquette: If you set up a meeting, you have to drive that meeting. Right from setting and sending out the agenda beforehand, sending out the questions/points of discussion in advance to give people time to digest and prepare to using the meeting time to efficiently get through that agenda. Leave ~10 mins for ad-hoc and unforeseen discussions. Use this time to do a quick round-table check for extracting any points anyone may have had but didn’t have a chance to share yet. If there are none, end the meeting early and give people their time back — I cannot overstate how much this is appreciated.
Schedule meetings well in advance to be able to have the best shot at getting time on people’s calendars: If you foresee that you need people’s time for something, place a [Hold] time on their calendars which lets them know that this is tentative and could be cancelled later. Remove [Hold] as soon as you’re sure you want that time to make it official.

The closer you get to the day of the meeting without booking a time, the harder it is to book as people’s calendars have been already filled up.

Set up recurring 1:1s with your closest team members: These are very helpful in the early days of a project (or even when you are new to the company). In the early days of a project, a lot of the project scope is being defined, the timelines are being planned and the approaches are discussed. The recurring meetings help you get focused face-time with the team members and have your early doubts cleared. I scheduled these with my PM, UX researcher, UX lead and my UX skip manager (manager’s manager). In my early days in the company, scheduling these and carrying these on for about 2 months helped me understand pretty much everything to get prepared tactically for the project. Meeting etiquette pointers still apply here — prepare questions and discussion points in advance, send them out if possible, keep meetings short and focused (30 mins is all you need) and cancel if things can be resolved over asynchronous chat or email.
When you are new to a team/company, try to absorb more instead of surmising process optimisations based on ‘perceived inefficiencies’: It has been a common pitfall I’ve fallen into a couple of times in past where whenever I started a new job in a new environment, my first reaction was to see all the ways the team could improve collaboration and communication through optimising processes. But as I talked to more folks on the team, I realised that more often than not, the processes were optimised as much as they could be and whatever I possibly could’ve offered as improvements was already tried in past and had failed or hadn’t worked. So the lesson here is to accept the fact that the ideas and optimisations that occur to you have most likely already occurred to other folks just as smart (or smarter) as you are. The learning here is — Wait a little, be patient and absorb as much as you can from the team to internalise the past learnings, experiments and outcomes. Use the above-mentioned 1:1s for these discussions.
Be so exhaustive in your process that at the end of a decision, you’re confident you’ve mulled over all reasonable possibilities (with the information you’ve had) and had very good arguments (for and against) for what you kept and didn’t keep from what was tabled: When you are at the divergence stage, accept every single idea, critique and arguments with humility to inform yourself more and more. If you’re on a ‘1 to 2’ project, you’d be wise to even go through the entire history of the project that precedes you and internalise the learnings and decisions made by folks before you arrived. This goes on to build confidence in you and the team as you converge later on.
Learn to write — document meetings, processes and decisions: These become the foundation of a project so much so that it is a living history of what the project has gone through. Documenting decisions means you have a foundation to point people to or refer yourself in the moments of doubt or confusion in future. At Google, we maintain a tracker document that contains meeting notes from every single meeting on the project, debates around design approaches and final decision with constraints and scope demarcated for reference. Every stakeholder can see this document. The first page of the document contains all links for the project — the PRD, research studies and reports, mocks, POCs and more so the document takes care of people moving in/out of project as well.
Develop a habit of taking notes: Tons and tons of notes — I start a project by taking a note, I keep a running note to list down things I accomplished every week (we call them Weekly Notes and we share a part of it internally to share what all we worked on in a week — these also come in handy at the time of performance evaluations). I take Tactical and Strategic notes — Tactical notes help me with things I have to achieve in the coming week or two (i.e. drafting an email, writing a proposal, design approach I have to explore, design changelog and weekly todos) whereas Strategic notes help me stay on course with the larger picture (i.e. outline of a talk I want to give later this year, projects I want to explore, outlining articles I want to write, vacation plans and so on). As much as possible, I prefer taking notes right when the thoughts strike and not later to not lose the authenticity.

One time I remember while walking in Kyoto I was thinking about pointers that can help scheduling meetings with a person efficient and interesting and wanted to note down the stream of thoughts. I ended up spending 45 mins in a nearby cafe to finish jotting down my thoughts in a note.

Learn to articulate ideas using vocabulary of abstraction and system design: By describing your approach in a different terminology, you can help people think about reusability and repeatability of patterns and solutions. You can help them construct a mental model that can be re-applied to different situations and not just remain limited to solving the individual problem at hand. A large part of systems thinking is coming up with these reusable mental models that help reduce maintenance overhead.
Be concise and thorough in your responses: Being a little slow and measured in responding is more important than being the first to respond. Do NOT respond if you do not know the answer yet — say ‘You will get back later’.
Develop second-order thinking: Do not take things at face value. Daniel Kahneman calls this WYSIATI — What You See Is All There Is. What it means is that in the absence of second-order thinking, you rely on appearance and what’s visible on the table. This limits your ability to understand people’s motivations and rationale behind their decisions and behaviour. When you are new, understanding the larger overarching system (that is always at play) is difficult as you are oblivious to it. But you’d be mistaken to not invest time in developing it by consciously spending time on it. You will surely fall short of tugging at the right strings in managing people and a project with first-order thinking. Being an effective team member is as much about stakeholder management, contributing to team dynamics and project mobilisation as is about being an excellent contributor. This cannot be achieved overnight but can also not be achieved purely organically. It will take conscious effort.
Be mindful of the repute capital: I am a firm believer of this mental model and having discussed it with a couple of my ex-colleagues, have found it to be consistent with their experiences as well. When you join a new team, you start with a limited but fixed reputation capital — say it’s 100. The capital required for you to become useful, trustworthy and dependable to the team is, let’s say, 200. Now in a new team, you’d be wise to spend time earning new capital to build on the 100 and get to 200 as quickly as possible. But it’s not that easy — you want to win trust of your team by impressing them so you seek out opportunities to take gambles and risky bets. That’s where it could go wrong. Your first few months is not the time for those bets, this is the time to establish a strong footing. This is not the time to bite more than you can chew and overpromise, this is the time to take slow, measured steps, take in smaller and less risky projects and acquire trust — get your team acquainted to your ways of working and familiarise yourself with the system. Once you get to 200, you have more information about the environment and the social/political dynamics of the company and that is when you can take more informed decisions and that is the time to consider bigger bets. Garner trust and inspire confidence that you have adjusted well in a new environment and on a new product by achieving small wins before you take on the big ones.
Confidence comes with exposure and exposure takes time: It feels nervously exciting to put yourself in a new territory — in a new job or in a new project. With that come the angst and anxiety of having to prove yourself all over again, do the work to win confidence and earn respect all over again in this new realm (Yes your colleagues are always respectful and they’ve hired you for a reason but you know what I mean). The only way to go about this is to gain experience in the system. Experience comes from gradual exposure to a myriad of situations, circumstances and predicaments that you can’t simulate. Exposure happens linearly and takes its own time. You can accelerate learning and accelerate your preparation but you cannot accelerate exposure. You have to be patient.

You can accelerate learning but exposure takes its own time.

Do not spend much time on getting around the specificities yourself: When you are new to a company, you are still learning how things work in a new environment — how to set up devices and accounts, organise the design assets repository, request access to the right tools and licenses and so on. Of course you could self-serve many of these but it’d just take longer. I personally feel that fussing about doing all this yourself is just futile. Get up and ask a colleague to help you out. You can totally do this when you’re new so use it to your advantage and save time (but make sure you help out in future when someone else needs the help). Don’t let this make you lazy though — you’d eventually have to learn to find answers for yourself.
Read about your team, the work done in the past, internal documentation, design system, research reports & share-outs and even the analytics: Good teams always leave an information trail for current and future team-members. In most cases, there exists a goldmine of information about your product/project and this is a great way to bring yourself up to speed. Many teams make this a part of a new-employee-onboarding flow but you should seek this material out and do this regardless.

Good teams always leave an information trail for current and future team-members. Seek it out and read as much as possible.

As Alex Roe has written, over-communicate constantly: Inform in advance and inform again. Communicate your vacation/leave plans, daily work routine, project details and ETA on your work as much as you can and as often as you can — that’s just responsible behaviour. It keeps the team in the know about progress and results in better scheduling and planning around deliverables.
Weekends and vacation should be enjoyed with a complete shut down: This is more of a note to my own self than anything else. Unlike my previous stints, pinging colleagues on weekends or outside office hours or on vacation is culturally discouraged and for good reasons — Weekends and vacations are your time and you shouldn’t think about work. Working across timezones as we do in our team, this is important for the emotional and familial well-being and is absolutely supported in the culture. It’s possible that this may already be the case with your job but it wasn’t for me —so it’s a welcome change indeed.
A company like Google can really feel like a different world of its own (it truly does), so it is important to stay in touch with the world and maintain a perspective: Keep in touch with fellow designers from other companies, regularly meet and talk with them and understand what else is happening in the world.
It is very important to grow outside as much as it is to grow within Google (or wherever you work): As you rise through levels inside Google, it’s important people outside Google (or your own company) also know what you do and how good you are. Contributing in events, conferences, meet-ups and the community in general is a great way to do so. Maintain an active and vocal persona (if you are the type 🙂) to remain relevant outside as well.

Compared to my previous stint where I had to be constantly vigilant of protecting my own interests, my time at Google has been rather cathartic — I’m enjoying every single day absorbing as much of the great culture as possible while spending time on making measurable strides towards getting better at my job.

Alex Roe (ex-Googler and former PM on Google Photos) shared similar learnings from his time at Google you should definitely read them. If you know of other resources where people have shared similar notes about their experiences, I would definitely want to read.

As they say, most advice is usually a note to self.

For a long time, these points stayed in a running note I kept for myself and it feels great to finally share them. They’ve helped me become a better designer, an effective communicator and a valuable contributor to my team, and the learning continues.

With that, back to work!

– @hvpandya