Impressing the socks off of new UX hires

The gist

Getting a google doc checklist on your first day of a new job is nice... but I knew we could do better than "nice." I cooked us up a wow-inducing Coda doc that saved us time, maximized automations, and impressed new every single hire who has used it so far.

Especially proud of
  • Time we now save managers, ops, and new-hire buddies
  • Reactions from new hires
My role

Doc engineer


About 3 weeks

An error-prone onboarding process.

My onboarding task checklist was one of the very first document I opened when I joined Gartner Digital Markets in 2019. The content was strong, but it wasn't until our next hire joined that I saw how much repetitive, error-prone work it required of each hiring manager. Here's what the process of prepping an onboarding doc used to look like for hiring managers:

  1. They'd make a copy of our kitchen-sink onboarding Google Doc template. This was a catch-all that had items for both product designers and UX researchers.
  2. They would read through every item, personalizing and fine-tuning it for their new hire's role, seniority level, location, resources, tools they need access to, what project's they'd be working on first, etc.
  3. Eventually they'd find outdated information. "Oh, this links to an old template we don't use anymore" or, "whoops, that teammate isn't with the business anymore." They'd update the stale info in their new hire's onboarding doc, and (hopefully) make a note to update the base template at a later time. Or just do it in the moment. Often this means ⌘+Fing around to hunt down potentially stale keywords and then correct them.
  4. They'd update the sharing settings of the now-personalized onboarding doc so the new hire has access on their first day.
  5. They would send a private message to the new hire over Slack with a link to the onboarding doc explaining that this is their one-stop-shop for all things onboarding.

I saw that every single part of this process could be improved using a more appropriate tool for the job: Coda.

What was working VS what wasn't

Let's start with the good:

  • The "kitchen sink" concept was helpful. It ensured that where roles did have overlap (eg. everyone needs to complete security compliance training) were always consistent.
  • The doc format made asking questions and getting help easy. If a new hire needed something clarified, they could start a comment thread directly on the item they needed help with and @ their manager for help.
  • Progress was clear both for the new hire, and their manager.

And the clunky:

  • Personalizing the doc took a lot of time.
  • A lot of the personalization was ripe for systematizing. Location, Seniority level, Discipline, Contract type, Manager, Onboarding buddy... all these things could be defined as single "variables" and referenced in the appropriate places.
  • No consideration for the existing team's experience of onboarding a new hire! Of course we'd automate as much as possible, but a lot still needed to be done by hand.
  • Google docs are pretty limited formatting wise. You just get one big, linear canvas. This put a lot of constraint on the design of the doc when we wanted to reference something that came up a page or two ago.
  • Lots many of the tasks we originally assigned to our new hires were more appropriate for operations, their manager, or buddy to take care of! Things like: getting access to the right Slack channels, getting invites to all the right software,

The new experience


To make personalizing go as smoothly as possible I needed to identify what criteria we could use to match tasks to new hires. I landed on the following:

  • Role: designer, researcher, or operations
  • IC vs Manager
  • Seniority: junior, mid, senior, staff
  • Product specific: true/false
  • ↳ if true, which products: product 1, product 2, product 3, etc
  • Location: DC, Maryland, Virginia, Barcelona, Austin TX
  • Contract type: full time, contractor, intern

That list would not only apply to the new hire, but every task in our kitchen-sink onboarding checklist. By doing this we filter out anything that wasn't a match.

For example, if you're a Design Manager overseeing designers contributing to Product-1, we'd have you meet with Product Managers who are also focused on that Product before we introduce you to PMs, Design managers, and other folks from other products. This seems sort of obvious, but when you're new to a team you shouldn't need to try and reverse engineer the org chart and team compositions to figure out the best order to meet folks in. That's what this doc does: shows new hires exactly what they should be doing for their first couple of months with us, in a thoughtful sequence.

What's great is hiring managers still had full control over the task list. If they needed to make an exception and remove a task that technically applied for a new teammate, but wasn't appropriate for some reason we couldn't cover in our personalization criteria, they could remove it. Same goes for adding tasks back in that the criteria filtered out. This drastically cut down the time it took to spin up a highly personalized onboarding doc.


The checklist has a total of 87 tasks for new teammates (after personalization, they tend to only see around 60). To help new hires pace themselves, we chunk them into timeframes: first 3 days, first two weeks, through their first three months with us. There's also a "when you have down time" set of tasks that are meatier and more on the educational side (demo videos, UX research studies, etc). The doc uses pages that represent their first 30, 60, and 90 days. We want those "when you have down time" items to always be visible and in sync across those pages.

And it's not all about the checklist! We also have pages that introduce the new hire's manager, their "buddy" (usually someone in the same role as them who can answer nitty-gritty questions), and an operations contact (me!) for all things logistics.

The "back end"

Of course for all of this to impress the pants off of new hires, me, their manager, and their buddy have our own space in their onboarding doc to coordinate our own checklist and to-do's. Again, depending on who is in which of those 3 roles, they'll have different tasks assigned and windows of time they should aim to complete them. Here's some examples:

Before new hire's first day:

  • Operations: add them to Figma, Miro, UserTesting
  • Manager: schedule a first-day welcome coffee meeting

On new hire's first day:

  • Operations: invite them to all relevant Slack channels (yep, this is based on the personalization criteria)
  • Manager: DM them with a link to the onboarding doc and brief welcome message
  • Buddy: warmly announce their arrival in the all-team channel, encourage others to book 20m coffee chats with the new hire, and ask folks to thread with silly welcome-GIFs

By end of new hire's first week:

  • Manager: schedule recurring 1-1s
  • (if the new hire is a product designer) Operations: Design system tour

What new hires have to say

Alice created the most amazing Coda docs with new team member checklists, resources, and even inside jokes. She immediately incorporated me into team rituals and made sure I had access to everything I could possibly need.

- Ryan Weisser

There's more to this story

🔒 But it's reserved for interviews 🔒

Invite me for an interview