3 Essential To-dos When Starting Your First Corporate Design Job
Let’s say now finally you get your first job after the everlasting job searching process — numerous hours working on your portfolio, hundreds of coffee chats to meet other designers, many rounds of stressful interviews.
You are going to start the first day of your job. You are probably very excited and probably a little bit nervous.
But what exactly are the couple of things you should do to leave a lasting impression on your peers, your leaders, and your stakeholders to make sure you will succeed in this job in the long run?
You might say, that is simple, I just show up and do onboarding, talk to people, and get started. What is so difficult about it?
Well, I have learned “the first impression” actually lasts way longer than you think it would. You want to make the right mark when they first form opinions about you.
To-Do: Meet all important stakeholders
As much as you can, meet all your important stakeholders. Looking back, the biggest mistake I have made when I started my first job was that I did not set up enough 1:1s to meet people.
Your important stakeholders can include:
- All designers on the team reporting to the same manager (not just your direct team)
- All product managers
- Engineering managers
- Lead engineers or architects
- UX writers
- UX researchers
- Design system ambassadors
- Accessibility specialists
- All your design management chain up to 3 levels
The above list is all your important stakeholders when working on a design job in a corporate. You can add and delete from the list but the idea here is these are the people I need to interact with at some point one way or the other.
Each product manager either owns a specific product area or a specific scrum team. As a UX person, even if you are only assigned to one product manager, you will still benefit from meeting other product managers and knowing which areas they are focused on.
Surprisingly enough, when the team gets bigger, the product managers don’t talk among themselves enough. More often than not, in order to push one design vision forward, you need to function like a glue getting inputs from multiple product managers who are siloed in their own world. Starting to build that relationship early will only benefit you.
If you never talked to a product manager for like 6 months after you start your role, now you came across a project that needs input from him/her, you will find yourself in an awkward position. So milk that new hire title and put time on all your PM’s calendars to meet them in a 1:1.
For engineering managers and lead engineers, it is not a must, but I find it valuable to meet them early on.
When you are working on larger-scale projects, it is always good to involve engineering early on. The engineer managers can help you arrange meetings with cross-functional teams as needed while the lead engineers are often the main point of contact to check the feasibility of your design. So those are all important relationships to cultivate.
I want to quickly point out the difference between a regular engineer and a lead engineer. A regular engineer will be working on a specific piece of work for the current release. But a lead engineer will be pulled in for any vision discussions which are more relevant for you.
For UX writers and UX Researchers, you should at least have one point of contact in those areas. They are important stakeholders but often get forgotten to involve early on in a project kickoff at some companies. Be that designer who always involves them as their bandwidth allows. They have such a wealth of knowledge and inspire so many great ideas.
For design system ambassadors and accessibility specialists, you should meet them and learn to lean on them as resources. Most large companies have a design system. When you reach high fidelity design explorations, you need to figure out which components to use, how to correctly use a certain component, invent new design patterns, and figure out all the keyboard navigation as well as screen reader experience. Those are the people you want to consult with when you get to that stage.
For the last one, all your design management chain up to 3 levels, I have to be honest, this one I don’t do as good as job of myself when I first started, especially with executives many levels above me. I am always like, our paths probably never cross anyways, and they are already so busy, what are we going to talk about?
It is important to shift your mindset a little. The purpose of an initial 1:1 is not always to build a lasting relationship. You might not really cross paths with this Senior Vice President who is 3 levels above you ever again. But booking the 1:1 shows your proactivity to introduce yourself.
It is a statement of “I exist” in the middle of a big company. Otherwise, there are so many new hires every day, you might just go completely invisible.
At this point, you are probably intimidated by the number of people you will have to meet when you first start. Here are some tips for making sure you can cover the grounds more without being aggressively networking:
- Ask your manager who you should meet first. Some companies are more passive than others. Giving your manager a heads up is always good. You can also leverage your manager’s knowledge to point you to the most important stakeholders first.
- Send out an intro message or email to all important stakeholders. You might not have time to sit down and have a chat with everyone. But you can at least introduce yourself. At some companies, people will even offer coffee chat if you just reach out and say hi.
- Identify the design advocates on your team and prioritize them first. Sometimes if we are lucky, we get a few design advocates on the team who either come from a design background or are just openly passionate about design. Talking to them first can get you comfortable to start this whole mini networking journey. They can potentially give you more insights into the team structure and advice on who you should meet next. They will also probably be your biggest allies down the road every time you enter a negotiation so make sure you do build a relationship with them.
To-Do: Soak in the most essential product knowledge
I have to say this one is a struggle. You will always be learning about the product no matter how long you are on the team. You can easily get overwhelmed by the amount of information that is out there. Focus your time on the essentials and learn the rest when you start picking up design work.
The mental model I use in terms of what you need to learn about the fundamentals of your product is to know where your product is now, and where it is heading in the future.
For understanding where your product is now, the best way is to get hands-on. As a designer, you need to first build empathy with your users. Learning to use the tool as your users is key.
Ask your PM for a demo, or watch a few demo videos of your products, then try to complete a few tasks that your end-users would do. That is the most time-efficient way to learn a tool. Prioritize that. Make that a goal to complete by the end of your onboarding.
For understanding where your product is heading, the most efficient way is to know what is on the priority list.
In a big company, you might have a million different features shipping in one release cycle, some big, some small, some might affect you, some might not. How do you pick and choose which ones you want to invest your time learning?
Rule of thumb is always to ask humans first. One mistake I have made when I started my onboarding was spending way too much time reading the documentation and getting confused, but not enough with meeting people.
Most of the time documentation is not up to date, or they are ever-evolving so some parts are more understandable than others. Referring back to documentation after you have a high-level understanding of which parts matter more than others can save you a lot of time.
Even though I ask you to consult humans first, unavoidably you will read documentations and keep referring back to them.
I will first start with the designers’ main projects. Ask your teammates to walk you through their projects and explain why this design is needed. All the important initiatives that need design attention can be distilled into one piece of big design work, despite it looking like 20 line items on the engineering to-do-list. That would help you cut through a lot of noise.
Second, start with product managers’ epics or main features. When I just started, the most overwhelming moment happened when I attended the monthly PM meeting. Each PM walked through their scrum team’s priorities and updates for the release. Looking at the 10 line items on each slide and 30 slides for15 teams, my brain just completely got fried.
However, I quickly learned that a lot of that information is really not relevant to me. As a new hire designer, absorb as much as you can but focus on building a mental model of how these features fit in the direction we are heading as a product first.
Understand what each PM is in charge of, and what is on their priority list is more important than understanding what each feature we are shipping entails.
Later on, when you actually working on designs, your stakeholders will bring up the relevant features. You will have time to dive in further with an engineer or PM on those specific features.
Lastly, pick up the basic terminologies of the products. Different teams might refer to the same thing by different terminologies. When you are asking a question, if the terminology you are using is not correct, people can easily get confused.
Document the common terminologies people use to refer to various aspects of the products. For example, the current product I am working on, it is a visual programming tool for business automation called Flow Builder. You can think of it as the enterprise software version of the IFTTT or Apple Shortcuts.
We could be using “element” or “node” to refer to the building block of the tool, and “property editors” to refer to the forms you fill out within each building block. For each flow, there is “design time” and “run time” behavior. When you run a flow, a “run” is different from a “flow interview” and it is different from a “transaction”.
Make sure you document all these terminologies with relevant links and conversations with people. So when you forget, you can use them as references.
I probably have alluded to it multiple times throughout this section, but getting started with a structured resource document.
During the onboarding process, I find myself having info in all sorts of different places like 1:1 docs, project docs, and scattered resource docs. It is inevitable to some degree, but get yourself organized at first can really make your life much easier later on.
To-Do: Take Advantage of Your Fresh Eye and Start Contributing Immediately
I know it is painful to start your first design job because you are spending a good amount of time mentally and physically transitioning from an all-star contributor to I-don’t-know-anything newbie. Learning to be patient with yourself is hard but you can actually start contributing more quickly than you think.
For example, when I started my new role about 6 months ago, I did three side projects that really increased my visibility as a new designer on the team.
First, I re-organized our onboarding document with a new structure and with extra resources. Creating a new onboarding document if there isn’t one is the best way to keep yourself organized and deliver value to future new hires. Even if there is an existing one or a couple of different ones, they are probably outdated. So take the opportunity to refresh them and propose new ways to make them even better.
Second, I did a guerilla user research at our annual conference Dreamforce and present back the findings. The sharing inspired some great conversations. One of my suggestions around focusing on the adoption of our existing features even became one of the top priorities on our product's yearly goals.
Doing some baseline user research is a great way to build empathy with your users as well as make contributions to the team right away.
Take advantage of every opportunity you can get to speak to customers whether it is at upcoming conferences or reach out to customers directly. You can also reach out to other internal teams who have direct access to customers such as sales, marketing, or customer success.
Third, I started a list of UX papercuts, which are low to medium areas of improvement that would improve the usability of our product.
It originates from me just documenting areas I was confused about the product when I first started learning the tool. I realize very quickly that after I get comfortable with the product, I start to see the features as they are instead of how they should be. So I am glad that I captured all my confusion at the early stage.
I involved my team to keep adding more items to the document. Now it is the central hub where the UX team keeps pushing for incremental improvements of the product.
As you can see, you can begin contributing much quicker than you think. Take advantage of your fresh eyes. Initiating projects that both help you onboard and bring value to the team is the best way to hit the ground running.
Starting your first corporate design job in the real world is intimidating but also exciting.
“It is so fine and yet so terrible to stand in front of a blank canvas.” — Paul Cezanne
I hope these tips help and wish you the best for your new role!
