Onboard yourself to a new UX job/gig

A while ago, I had this idea to write myself some instructions about onboarding* as a UX designer… collecting the I did well and noting what I should do next time. (Onboarding = to a new job, new project, new environment). It’s hard to stay aware in the moment, so I thought: “Why not get my smart past-self to help my current self?”

“Why not get my smart past-self to help my current self?”

I hope this list works for starting a new job or getting a new (longish term) contract gig — this article leans in the ‘established product’ direction but lots of points can be considered in other situations too.

Active action

This list describes ‘active’ things to do, to take control of your learning, instead of waiting for others to onboard you, or for osmosis to kick in.

Taking an active role in your own onboarding is a sign of professionalism and commitment — and a practical necessity because it’s not always something that is carefully considered by the group you may be joining.

I also acknowledge that I may be missing stuff due to my assumptions or because I have a lens of my own experiences. So please write comments and help me flesh this out further and this guide can improve and become a living thing!

Ok here goes (a brief version is available at the bottom).

Onboarding To Do List

Navigating the organization

• Get the who’s who overview: aside from my outward disdain for org charts, they are at least a starting point to understand who is who — but you’ll need to flesh these out by adding more relevant contextual design (ok, so-and-so is the lead of this team, but what are they working on now? What is their overall remit? Goals for the year? Interconnectivity with other teams, how would you work or interact with them with them?)
• Get or make a desk map with names (if you’re onsite or offsite really — you gotta know who the people are, maybe you’ve been awkwardly walked around the office, maybe not. Either way, you won’t remember any of them really, so get a cheat sheet — draw it if needed)
• When you receive recommendations of people you should talk to about X,Y,Z, write them down immediately because you’re not going to remember anything (sensory overload alert)…don’t be stingy on the context you include to your future self.
• On that note, write down pretty much everything you possibly can. Again, it’s hard to remember things — also, I’ve learned to clarify points in the moment as much as possible, rather than feeling like you’ll figure it out later magically.
• Arrange for 1:1’s with people (ere on the side of more) — one from each functional area if possible. UX is all about unlikely brain connections (technical, psychological, creative, emotional, practical) and people connections (collaborating with groups you would not expect AND facilitating collaboration between groups that don’t normally work together).

Ask them:

• About their experience with UX
• What their goals are — their personal/professional/team goals
• What in the way they work or see things might facilitate collaboration (may or may not be applicable to working together right now, but might be great context nonetheless)
• Be relentlessly curious/inquisitive. Remember that this beginning is a great chance to give yourself that curiosity mindset and ask whichever dumb of questions you like (I think that asking questions and challenging people’s assumptions is always useful, but especially when you’re starting off you can feel totally open at first, so you might as well establish this habit/pattern now)

Learning the product(s)

• Get your paws on user-facing documentation that is as up-to-date as possible then comb through it, noting questions or ‘design smells’ as you go along (your fresh eyes are incredibly valuable, being so new that you may not be able to contribute ‘deliverables’ right away, but your sensitivity to the content is a great thing to help others challenge assumptions. You don’t have to get into people’s facing with your perspective yet, but certainly capture it while you’re still fresh)
• Ask for internal documentation — this can be all over the place, but if you can find key docs people use for:
• Reference (ex. glossary, personas, client list, architecture diagrams, personas)
• Project tracking documents (what release is it on? What’s coming? Is there a ‘roadmap’)
• Style guides (marketing/brand versions — look at the brand messages being communicated in them, look at how that plays out in real life assets like the website and printed doco, even swag)
• QA documentation (ex. Consistently tested scenarios (including edge case scenarios) docs on expected behavior, this will help you ‘be’ someone as you really dig and explore the software)
• Access to Zendesk (or equivalent) and/or the support team: this is a treasure trove of UX info, but it could be hard to navigate, so asking to be connected with support might be your best bet. Zendesk might be your only source of ‘design intel’ from the standpoint of sore spots in the product. Specifically try to find out:
• If feature requests are collated, if not look at some
• If support tickets are quantified, reported (also look at some)
• Get the temperature on supportability and how removed or connected the support team is with the rest of the teams
• Find out how/where to login to the product(s) and how to get the right data into the system for the product to make sense (harder than it sounds sometimes — worth asking about accessing a complete list of products and find out the supported versions)

UX-specific intell

• Find out who advocates design, be friends with them and meet them, get to know where your philosophies intersect.
• Find out who talks to users in the company (field team, support, sales, client relationship people of all kinds) Then be friends with them.
• Talk to devs/dev team leads and get the temperature for UX maturity by asking things like: What’s your impression of UX design overall? How have you worked with designers previously? How would you like to work with designers now? What are grey areas that you want to know more about? What do the dev teams care about the most (in terms of doing good work)?
• Ask (everyone): what keeps you up at night about your product?
• Ask: Who are the UX personas? Which features do they use? How were the personas arrived at? Are there scenarios built around the personas?
• Ask: what role does user-testing play? What part do users play in the grand scheme of things
• Ask: how does the design team work together?

Business context

• Find out who are the main competitors
• What share of the market does this product/service have?

In Conclusion

This isn’t everything about doing good design and doing your job well. It’s more oriented around paving the way for getting things done in a new environment. As I see it, your relationships are the most valuable thing to doing good work. Secondly, showing professionalism by leading the initiative in your own learning is powerful thing.

Again — if you wonder why I included something and not something else, I’d love to hear from your fresh perspective!

— — — — — — — — — here’s the LIST version — — — — — — — — — — — -

Navigating the organization

• Write everything down
• Be relentlessly curious/inquisitive
• Get the who’s who overview
• Draw or get a desk map with names
• Arrange 1:1’s

Learning the product(s)

• Get user-facing documentation (make notes)
• Ask for internal documentation (make notes)
• Reference (ex. glossary, personas, client list, architecture diagrams, personas)
• Project tracking documents
• Style guides
• QA documentation
• Access to Zendesk
• If feature requests are collated, if not look at some
• If support tickets are quantified, reported (also look at some)
• Find out how/where to login to the product (with data)

UX-specific intell

• Find out who advocates design?
• Find out who talks to users in the company (field team, support, sales, client relationship people of all kinds) Then be friends with them.
• Talk to devs/dev team leads and get the temperature for UX maturity
• Ask (everyone): what keeps you up at night about your product?
• Ask: Who are the UX personas
• Ask: what role does user-testing play
• Ask: how does the design team work together

Business context

• Find out who are the main competitors?
• What share of the market does this product/service have?

Download a pdf here