Taking Ownership As a New Grad Designer at Google

I recently had a conversation with my teammate about how to effectively present work to engineers. For my project, I originally had plans of scaffolding a few key screens in high fidelity based on the dire need on the engineering side to start implementing. If I could provide part of the design right away, they could get started on building. Before our conversation, this sounded reasonable. We have pretty tight deadlines. Engineers have the backend ready. I provide the engineers some of the design to start building on. We finish quickly.

When I told my teammate this, she asked these two key questions any designer should think about before presenting high fidelity mockups to engineering:

  • Is this part (the design) the engineering team is asking of you for really central to the UI you are building?
  • Would you get locked into a design?

From my perspective, high fidelity deliverables can bring up the assumption that designers have already thought through how the design works from a systematic and/or user perspective. From the engineer perspective, they start building on it, expecting the designer to continue delivering to that standard.

Ever since I started working at Google, I have been having a small predicament with load balancing. This means trying to prioritize my needs over someone else’s without losing myself and how I work. I had been giving myself pressure to make something quick for the engineering and PM teams, trying to make sure they are both happy, that it almost made me forget to ensure I satisfy my own design process first.

In a sea of engineers and PMs, it can feel a bit stifling to communicate my point of view as a designer, but it also makes me realize that I hold a big responsibility because I am one of the only designers that can own the design space within the product we are making. Here are tips to help me remember what I need to do within my design process to ensure success from the design end of product. Hopefully they can help other designers too.

Before designing mocks, define the workflow

A concern I didn’t realize from the beginning was that I could end being locked into a design. I am in charge of designing the whole framework of the project I am building and if I pass off designs without too much thought of how the experience meets the needs of what my team is thinking of, there will be more back and forth to change things. This would require more time for the engineers even though the intention is to build something asap which, ideally, requires least amount of time for engineers. I don’t want to hand off a design that the engineering team starts building only to realize there are holes with the design that we failed to address in the beginning.

Taking a step back from all the noise, I realized I needed to define workflows and while I did that, make them TANGIBLE. This made it easier to define critical user journeys and map out an organizational flow for the product experience and to communicate my process through the beginning stages of my project. This helps make sure we address potential issues we might otherwise overlook.

It’s okay to push back

If you need more time to figure out things, don’t be afraid to push back despite engineers saying they need it. At Google, lots of engineering teams want to build something quickly, and as a designer, it can be easy to get lost between the back and forth of people wanting you to design fast vs. you making that decision for yourself based on how you feel and whether or not engineers really need the designs now.

Take a step back to think about what you design first before creating anything.

You don’t want to get locked too early into a design. Also, as a designer, you are the expert in your space. At Google, it is very easy to create high-quality mocks with Material Design components, but these can bring up a lot of questions and concerns that would need to be addressed before dialing-in the details of the design. I also personally did not feel too comfortable designing high fidelity before trying something more rough and loose, so I had to push back and address my own design process. When I let the engineering team know my plans changed—presenting rough mocks over high fidelity designs—they were 100% okay with it. I’m lucky to work with a team that values design and supports the work I do.

Don’t let pressure affect your design decisions

When you feel too pressured, you can forget certain things. Because I felt like there was a lot of pressure on the engineering team to quickly create something, I almost forgot to do standard things that are part of my design process—ensuring I document well and develop my rationale. I was telling my PM about my issue, and he suggested that instead of thinking about hitting the big goal right away (kickoff meeting, getting my set of mocks approved), which isn’t feasible for me at the moment, I should take a step back and address the main milestone I want to hit—creating iterations of mocks.

Engineers will always want UX stuff.

Before handing off any design, it’s important to understand how the engineering side works. Do the engineers really need this? Do we have more time? Is the engineer blocked? These are considerations that a PM would be able to provide more insight on.

When you first start out at Google, it can feel as though you have a lot of pressure to quickly make things, but a lot of my co-workers told me to just chill out and take things slowly—making sure I develop a strong understanding of everything and ask a lot of questions. Everyone understands what it’s like to be new and that you won’t be able to learn everything all at once, so embrace knowing nothing!

Over-communicate early and often

This is where taking ownership of your space can happen. Use any framework or model to illustrate your understanding of the space and use it to guide design and engineering work. Before producing any high-quality work, I typically show sketches and rough mocks to communicate my process and share my design direction. This is helpful in bringing about discussion of requirements and what my stakeholders are looking for.

It is ultimately up you in owning your process, allowing it to guide you, not just what people tell you to do.

Lots of people respond better to visual things. Though lots of designers at Google will jump to high fidelity because we have Material Design, rough mocks or less refined deliverables can generate a discussion where design is more involved and have everyone aligned before we start to decide on what/where we should invest our time in.

Conclusion

At Google, everyone appreciates being part of the process and wants to do good work where everyone is supported and feels good together.

I learned that before handing anything over to engineers, it’s crucial to share whatever thoughts/early mocks I have with my stakeholders (manager, PM) and engineering team to get feedback. I also use the design process to communicate my rationale. This is to ensure everyone is on the same page with where the design is going and how it will come to fruition during and after the building phase.


Follow me on Medium to keep yourself updated with the cool things I will be working on at Google in the near future!

Check out my Skillshare Course on UX research and learn something new!

Like what you read? Give Tiffany Eaton a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.