PEOPLE

Guide #028: What to expect when joining a new company as a product designer

As a product designer joining a new company, you’ll need to be proactive at getting to know the right people and mastering your product domain.


Gain a high level understanding of the UX team

Once you’ve emerged from company onboarding (IT setup, HR, organizational culture, security training, etc.), which can take anywhere from a day to a week, your next step should be to get to know the UX team. Your hiring manager should have prepared a document that includes a list of teammates and key stakeholders. If an internal employee directory exists, access it to gain a sense of who your peers and leaders are. Ideally, you should be partnered with an onboarding buddy—an experienced peer, or a level slightly senior. You should feel comfortable asking them questions and connecting with them in a weekly one on one (1:1) for the first 2 to 3 months.


Get to know your team dynamics and cross-functional partners

Starting with a conversation with your onboarding buddy, gain an understanding of how your team functions. Get to know your design manager, peer designer(s), content strategist(s), and UX researcher(s). Additionally, learn the dynamics of your cross-functional team, likely product managers and engineers, as well as any other disciplines like data scientists that you’ll need to partner with. Schedule 1:1 informal “coffee chats” and use your time to talk through recent work/projects, the latest product requirements, customer research and details on how to access supporting systems like the design system, research database, relevant Figma/Sketch files, etc. Also, each company has a different process for usability testing, or conducting user interviews. Ask your peer designers or researchers how research is managed, and what guidelines you’ll need to follow.


Discuss the culture and expectations around meetings

Meeting culture will vary from company to company and even from team to team. Make sure to ask when your team meetings are, the purpose of the meeting, and what the expectations of participants are. For example, housekeeping items, team bonding, or discussion about company policies might be reserved for a different meeting than your weekly design review where peers and a design manager provide feedback on design work.


Learn the preferences of your primary stakeholder

As a product designer, your main stakeholder will likely be a product manager (PM), product owner or a program manager. There are PMs, especially on enterprise software products, who have little or no experience working with a designer. What experience does your PM have working with others in your role? Ask them to describe their collaboration style and how they like to communicate. Find out how they prefer to give feedback on design projects. Are they used to having a weekly design review with a designer? Do they have experience using Figma to leave their comments and feedback? Determine what worked well in previous design-PM partnerships so that you can bring that into your process. And alternately, ask what didn’t work so you’ll know what to avoid.


Learn how to best communicate with your manager

During the first few weeks you will establish a cadence for weekly or bi-weekly 1:1s with your reporting manager. Good managers will share documentation of their management philosophy, work styles, and any preferences or boundaries regarding communication. At this time, you should also share your communication style, and what modes of feedback and recognition are most effective for you. You should also discuss your strengths and opportunity areas, the types of projects you’re looking for, and where you’re looking to grow and level up.


Develop your product ecosystem and domain expertise

The team you join will be responsible for a specific product area; however, it operates within a connected ecosystem. Learn what the interdependencies are, both from a technical and systems perspective but also from a user flow perspective. You’ll also need to master the domain in which your product operates. To do this, study existing user research to understand your user’s persona(s) and pain points. Learn the context in which they’re using your product. What are the external factors that affect how/when/where/why your product is used?


Use your fresh perspective to document the existing product experience

As a new product designer, your fresh eyes can offer valuable insights to the team. If the team you’re joining has an existing product, go through it as a user and document each step. Take screenshots and comment on any gaps or frictions you encounter. During this exercise you’ll likely generate a lot of questions. Document them and share them with your onboarding buddy. Since you're new, you can offer to share your findings without the pressure of developing solutions. However, if you have suggestions for improvements, don’t hold them back. Share them as a basis for deeper discussion.


Learn your team’s design process and how reviews are managed

During your first months, observe how other designers share progress or project updates. Attend as many reviews/critiques as possible, even if you’re not part of a project, and learn the structure and cadence of design reviews. Other reviews include a weekly design team meeting with UX colleagues (usually this meeting is for project updates and design critique), and a weekly design review with cross-functional partners (PM, lead engineer) to review technical feasibility, dependencies and implications. The designer should take the initiative to schedule this weekly design review with cross-functional partners. There will also be monthly or quarterly all-hands where your product team will share updates more broadly.


Utilize internal mentorship programs

If an internal mentorship program exists, consider utilizing it to grow your network and to gain a better understanding of how the organization works. If you have workplace concerns or maybe need advice on how to better collaborate with your team or manager, finding a mentor outside your team can be very useful. Additionally, in the future you might want to switch teams, so building your internal network will help give you access to opportunities that you might not be aware of.

Similar posts