I have been working as a growth designer at Pinterest for about half a year. Prior to this role, I had no idea growth design even existed. Even though I still have plenty to learn, I'd love to share what it's been like so far. Before I continue, I want to quickly clarify that company probably operates their growth design team slightly differently, depending on their product, culture, etc; everything I've learned about growth is at Pinterest specifically (although I believe these learnings are definitely applicable to anything I do in the future too!).

What it's like working in growth at Pinterest

I'll first quickly describe what I do as a growth designer at Pinterest. (Also, this article does a great job at explaining the purpose and role of a growth designer, if you are interested.) The skills that I use aren't too different from those of regular product design, but I'd say that a big part of the role is balancing good user experience with achieving business goals in concrete, quantitative forms (i.e. metrics). A simple example illustrating this is: how can we encourage users to sign up (hitting the business goal) without bombarding them with sign-up buttons or pop-ups (ensuring good user experience)?

In terms of work, we often run fast, iterative experiments. We begin each experiment with a clear user problem - to make sure we are really placing ourselves in the mindset, intention and moment - and a hypothesis with the outcome we anticipate will happen (metrics we hope to move, any secondary metrics that would potentially be affected, etc). The teams have high level goals and OKRs, but we have a lot of flexibility determining how exactly we want to approach these problems and what we want to solve for. I work closely with my design lead and engineers to work on these experiments, and typically I completely own the design of a couple individual experiments. The culture is very bottoms up, and the members on each team have a lot of say in how we want to experiment and what features or changes should be implemented. The interesting part about growth at Pinterest is that we also own parts of the product (instead of only trying to grow features that other teams own), similar to more traditional product design.

A couple learnings so far

Balancing good user experience and business needs

When I first joined Pinterest and started having 1:1s with my immediate teammates and other designers in the company, I remember feeling excited and a bit intimidated from the one thing that kept coming up in these conversations: That I would be caught in a "tug of war between good UX and driving metrics". The former usually comes from design, the latter from engineering. While I don't believe that good design and hitting business goals are mutually exclusive (in fact, I think that they should feed into each other), after a few months of working here, I now see what they mean.

One of the experiments I worked on particularly exemplified this. I had created two design options: variant #1 replaces an existing action with a similar new one, and variant #2 adds the new action alongside the existing one. Design preferred #1, as two similar actions could confuse users or be too redundant, while engineering was inclined to #2 because the current action is used so regularly that they were concerned about engagement levels dropping if we removed it. I decided to reframe the variants not as a solution for which option is the best, but as an opportunity to learn what our users preferred and then decide from there which option might be better suited for what our users wanted and our experiment goal. By explaining the designs as such to my engineers and PM, I was able to gain approval to include both variants to test in the experiment. I learned it's not always necessary to try and narrow down on the one "best" variant to test, but that even options that are unlikely to be chosen to move forward with could be tested simply to learn and confirm (or debunk) any assumptions we might have. It didn't cost a lot of engineering resources, and I believe the learnings would be valuable to inform future experiment ideas as well. (I currently don't have the outcome of this experiment yet; it is still running at the time I'm writing this!)

If you are interested in learning more about balancing UX and business needs, Julie Zhuo's very insightful article, Metrics versus Experience, was a recommended reading for me when I first joined the team that I found super helpful as a beginner in growth design.

Know exactly what you are testing and why

When you are working with metrics, it is very important to know what exactly is affecting them. This means being very clear on what exactly you are testing for each design variant.

I remember when designing variants for a few experiments, I tried to test too many design changes at once. I wanted to learn too many things in one shot: which copy was the most understandable; where placing an action would render the most engagement; whether a modal or a pop-up would be more well received; ... This resulted in me making too many changes in each design, compared to what's live. This is problematic because when the experiment is shipped and data starts rolling in, it would be very difficult to tell which exact change I made is affecting the numbers, and whether the impact is being made by one change only or multiple changes working together.

Instead of cramming all design variants into one experiment and guessing at which part of the designs affected metrics and why, a better approach is to break what I want to learn into multiple phases, based on priority of what is most important to learn or the goals set for the experiment. Returning to the primary user problem often helps answer this question. Let's say the main problem, proven by user research interviews, is that users are currently not taking a specific action because their understanding of a it is very low due to copy that is very vague or irrelevant. For the first phase of the experiment, I can test only copy changes. Once I learn what copy drives comprehension best, I can then proceed to test other designs informed by this initial learning to help drive further understanding (e.g. testing when and where this copy appears, the hierarchy of the copy alongside other elements on the page, etc).

Start simple with new surfaces

This was a very interesting learning that came out of one of my projects - as part of a larger project, I was designing a "pre-profile" page (a profile page for users with no account). We envisioned the purpose of this page to build comprehension of what Pinterest is about for new users, e.g. previewing to users what their profile could possibly look like if they had an account.

Instead of diving straight into polished, complex designs trying to woo the user, I created two sets of designs:
1. A barebones mockup to start with: only a sign-up prompt
2. Conceptual mockups; the possible "vision" we want to move toward: pin previews, board previews, etc

By implementing #1 first, we can get a sense of whether users are even tapping into this profile page. (If they're not, no matter how beautiful the page is designed, getting users to this page is a whole new problem that needs to be addressed.)

Another important consideration is that if we jump ahead using a design with a purpose that is too "certain", it could actually be very difficult to make changes in the future because it could result in metrics losses and could be seen as taking steps back. For example, if I had implemented a polished design that actually increased conversion but did little to help build long-term comprehension for new users, it could be more difficult to argue to change the page instead of leaving it as is, since changes could mean sacrificing these conversion gains.

When implementing a new surface, I would suggest starting simple - it's great to have an ideal vision for the designs, but it's also important to go step by step and track the impact of each step to really understand how the designs are affecting user experience and metrics.

Context is key

This is something I realized a few months into the job, and applies to not just growth design specifically. Having onboarded remotely into a company that previously worked in the office and switching teams 3 months in, I often struggled with the feeling of lacking knowledge about the team, past projects, current projects, and what other teams were working on. (By the way, this is totally normal for anyone starting a new job, and it could take months or even a year to feel fully integrated!) Unlike in the office where you could tap on someone's shoulder easily or overhear what people were working on, in a remote setting I kept up via video calls (e.g. team meetings, crits, all-hands), Slack channels (async stand-ups, team chats, project chats), and online documentation in multiple areas.

I noticed during critiques that I often felt like I had little to nothing constructive to offer. This led me to question my design abilities - am I even qualified enough to be here? But one day, I realized that the more experienced designers are able to offer such great feedback not only because they have very good product and interaction design skills, but also because they have so much knowledge relevant to the project. They offered suggestions and could anticipate something working (or not) based on past experiments or experiments running on other teams; they had strong relationships with their team members (engineers, PMs, etc) so they knew how to communicate and work with them best; they were willing to and pushed for breaking rules (e.g. design system standards) based on both first hand and second-hand knowledge from experiments or research. And even if they didn't have the answer, they knew who to reach out to to get it.

After this realization, I sought to work harder on gathering information. I paid more attention to Slack channels seemed less relevant to me, took on optional projects that required more cross-functional work, and always made sure to ask for an invite to any optional meetings. Although I still feel like there is quite some ways ahead, I believe this focus set me in the right direction.

Conclusion

Thank you for reading my ramblings if you got this far! I am very excited to continue working in growth design, growing my skills, and sharing my learnings here. Since this is a longer piece of writing for not just sharing my learnings but also formalizing them for myself, please don't hesitate to reach out with any feedback!