First Week Playbook for Designers: Design System Audit, Stakeholder Map

Designers fail at new jobs in one of two ways. They spend three weeks redesigning a screen nobody asked them to touch and get labeled precious. Or they ship pixel-perfect Figma files with no understanding of what the business actually needs and get labeled decorative. The designers who succeed in their first 90 days do something different in week one: they audit the design system they inherited, they map the humans who will sign off on their work, and they produce one visible artifact that proves they understand the product.

This is the sequence I have watched work at Linear, Figma itself, Ramp, Vercel, Arc, and plenty of Series A and B startups since 2023. It applies to product designers, brand designers adjacent to product, and the new breed of design engineers who ship code. The specifics differ, the shape does not.

Day 1 Is For Tools And One Working Prototype

Before you try to do design work, make sure you can actually do design work. On day one, confirm:

• Figma access with edit permission on your team's files, plus view on the company-wide libraries
• Your design system library is accessible and published to your account
• Slack, Linear or Jira, Notion or Confluence, and whatever research tool the company uses (Dovetail, UserTesting, Maze)
• GitHub read access if your company treats the codebase as source-of-truth for UI (Stripe, Linear, and most design-engineer-heavy teams do)
• Local access to the deployed product in every environment you need — staging, production, any internal tools

Then do one thing before end of day: duplicate a file your predecessor made, change a single component, and publish it to a dev or staging preview if your company has one. If you cannot, file a ticket or DM your manager. You are not ready to contribute until you can.

Audit The Design System Before You Audit The Product

This is the single most important week-one task and the one new designers skip. Open the design system library and spend four hours on Tuesday morning going through every component. You are looking for:

1. Coverage — what components exist, what are missing, what are duplicated
2. Consistency — same component rendered three different ways across product areas
3. Drift — components in production that do not exist in the library at all
4. Governance — who publishes, who reviews, how new components get added
5. Adoption — which teams use it, which teams forked it, which teams gave up and built their own

Write a one-page audit. Be specific. "The Button component has three variants in the library but eight in production" is useful. "The design system needs work" is not.

The design system tells you more about the company's design maturity than the portfolio of shipped screens. A tidy library with gaps means the team is disciplined but under-resourced. A sprawling library nobody follows means design has lost political capital and your real job is to earn it back.

Do not propose fixes yet. You do not have permission. You have observations, and observations are a gift you will cash in during week three when you have standing.

Map The Stakeholders Who Will Kill Your Work

Designers underestimate how much of the job is political. The beautiful mockup that never ships was killed by a PM who felt excluded, an engineer who thought it was infeasible, or a founder who had a different aesthetic opinion. Your job in week one is to identify those people before they become surprises.

Build a stakeholder map. Actually draw it. A shared Figma file with four concentric rings is fine:

• Inner ring: people whose approval is required for anything you ship (your design manager, your PM, your tech lead, sometimes the founder)
• Second ring: people whose input you need but who do not block (adjacent designers, senior engineers, research, marketing)
• Third ring: people who will be affected by your work (support, sales, CS, the designers on other teams)
• Outer ring: customers and their advocates

For each name in the inner two rings, write down: what they care about most, what they are tired of hearing about, and how they prefer to give design feedback (async Figma comments, live review, written doc, Slack thread). Get this from your manager or from asking the person directly.

This sounds cynical. It is not. Design is a team sport and designers who ignore the political topology ship slower and less often than designers who respect it.

Do 10 Conversations In Five Days

Book 30-minute 1:1s in your first week with:

• Your design manager
• Your PM or PMs
• Your tech lead and at least one frontend engineer
• One peer designer on your team
• One peer designer on an adjacent team (if your company has multiple design teams)
• The design system owner, if that is a specific person
• One researcher or data analyst who works on your product
• One customer support lead
• One customer, if you can get it on the calendar (you usually can in week two, so settle for week two)
• Your skip-level design leader (director, head of design, VP)

Use three questions in every meeting:

1. What is the last thing design shipped that you were genuinely happy about, and why?
2. What is the last thing design shipped that missed, and what went wrong?
3. If you were me, what would you work on first?

Take notes. The pattern of the first question tells you what "good" looks like here. The pattern of the second tells you where the landmines are. The pattern of the third tells you what the team already agrees on — and that is where your quick win lives.

Read The Product Like A User, Then Like A Designer

Spend half a day on Wednesday being a user. Sign up fresh. Go through every core flow. Take screenshots at every friction point. Notice every inconsistency. Do not fix anything, do not propose anything, just feel it.

Then spend half a day on Thursday being a designer. Open Figma and find the most-used screen in your product area. Look at:

• When was it last touched and by whom?
• How many variants exist — is there a mobile version, empty states, error states, loading states?
• How close is the Figma file to what production actually renders? (Hint: it is never as close as you think.)
• What components are being overridden or detached?

If the Figma file is badly out of date with production, that is quietly a huge problem and it is also a quick-win opportunity — updating one high-traffic screen's Figma to match production is a half-day task that earns you credit with every designer and every PM who has to reference that file.

Ship One Visible Artifact By Friday

By end of week one, produce one deliverable that the team can see and react to. Options that work:

• A written design system audit with a prioritized list of gaps (3-5 pages, plainly written, no hedging)
• A stakeholder map, published in your team's Figma or Notion
• A "what I noticed about the product in week one" document — one page, specific, with screenshots, annotated inconsistencies, no proposed solutions
• A cleaned-up Figma file that reflects one high-traffic screen's current production state

The goal is to demonstrate that you see clearly and communicate precisely. Do not propose a redesign. Do not pitch a rebrand. Do not write a strategy doc. Designers who do those things in week one look inexperienced. Designers who document what they see with precision look like seniors.

What To Avoid In Week One

A short list of mistakes I have watched designers make:

• Opening a blank Figma file on day three and starting to "explore a redesign" of something nobody asked about. Waste of a week. Nobody will thank you.
• Offering strong opinions in critique before you have context. Your aesthetic preferences are not calibrated to this product yet. Wait.
• Ignoring the engineers. A designer who has not watched the frontend team work cannot ship. Your tech lead is your closest collaborator; act like it.
• Proposing a new design system from scratch. Every new designer thinks this and it is almost always wrong. The existing system has scars you do not understand yet.
• Skipping research. If there is a research team, be in their weekly sync. If there is not, you are the research team and act accordingly.

Next Steps

1. Before end of day Monday, confirm Figma access with edit and publish permissions, plus view access to every company-wide library. Duplicate a file, modify a component, and verify you can publish.
2. By Tuesday afternoon, complete a written design system audit — coverage, consistency, drift, governance, adoption. One page. Share with your manager Friday, not earlier.
3. By end of day Wednesday, have your stakeholder map drawn in Figma or Notion. Name every person, note their preferred feedback style, and book recurring 1:1s with your inner ring.
4. On Thursday, spend one block being a user (sign up fresh, go through core flows, screenshot friction) and one block being a designer (compare Figma to production on your team's three most-used screens).
5. By Friday end of day, ship one visible artifact — audit, map, product-notice doc, or a high-traffic screen brought up to date with production. Email or Slack it to your manager with one sentence: "Here is what I saw in week one, happy to walk through it in our 1:1."

Related guides

• First Week Playbook for Data Scientists: Access, Baselines, Stakeholders — A concrete first-week plan for data scientists in 2026: get data access on day one, establish baselines, and map the stakeholders who will act on your work.
• First Week Playbook for Engineers: Read, Ask, Ship in 7 Days — A concrete day-by-day plan for engineers starting a new job in 2026: what to read, the questions to ask, and what to ship before Friday.
• First Week Playbook for Product Managers: Listening Tour, Quick Wins — How new PMs should spend their first five days in 2026: structured listening tour, roadmap archaeology, and two credibility-building quick wins.
• New-Manager Onboarding Playbook — First 90 Days as an EM — The first 90 days as an EM at a new company determine the next two years. Here's the week-by-week playbook for listening, shipping, and earning trust.
• What to Do Between Accepting an Offer and Starting — The 2-Week Prep Playbook — The two weeks between acceptance and start date should protect the offer, close out your old role cleanly, and set up a fast ramp. Use this practical checklist for paperwork, resignation, onboarding, manager alignment, and first-week preparation.