Uncategorized

Hiring a Design Contractor or Vendor

We highly recommend your product team be a balanced team made up of a product manager, designer, and some number of engineers. Sometimes, however, your team may not have a dedicated designer who is able to design in an agile environment, think through user experiences, facilitate and synthesize research, and develop designs for the team to implement—but it may want one. This guide will help teams who’d like to bring on a design contractor or vendor and need help interviewing, evaluating, and onboarding a designer but aren’t sure how to go about doing that.

If you need help convincing your team or leadership to contract with a designer on a time-and-materials basis vs. a fixed-deliverable basis, check back soon for our upcoming blog post on Advocating for Outcome-Oriented Vendor Contracts with tips on how to approach this conversation.

Preparing for and running interviews ?

Key hiring considerations

These key hiring considerations are intended to help support any hiring conversations with prospective design contractors but could easily be repurposed to help with hiring a full-time designer. The list includes areas to investigate and, where appropriate, some sample questions that are rooted in asking about what the designer has done as opposed to asking them to speculate on the future.

Things to look for and ask about

  1. Values collaboration across disciplines (e.g., wants to pair with developers to implement designs)

    “Tell me a bit about how you worked with [PM/engineer] on this project?”

    “Tell me a bit about your favorite [PM/engineer] working style? What do you like about it?”

  2. Gets excited about shipping software vs. “just making designs”

    “What are your strategies for balancing between building ideal features and shipping production software?”

  3. Is able to start small and iterate vs. doing “big design up front” (i.e., solving for all things at once)

    “Walk me through the process you took to reach this design.”

  4. Advocates for getting user feedback on design decisions and is confident leading user research

    “Can you elaborate more on the research you did [on feature/in phase]?

    “Can you provide some examples of things you learned in research that you did not expect? How did this impact your design strategy or the product plan?”

  5. Has strong, but loosely held, opinions (i.e., is willing to push for things they think are right but is just as willing to compromise in the face of new information)

    “Tell me about a time when you had a different opinion about [a feature/a direction] than others on your team. How did you navigate that?”

  6. Has familiarity with the design tools that the team is using

Possible hiring logistics/flow

This set of hiring logistics is intended to give one possible fast approach to hiring a design contractor into a team that does not have a designer but does have a product manager-like role and/or at least one engineer. Naturally this will vary based on how much recruiting/sourcing is done by you vs. by a partner agency, and it can always be adjusted to fit the parameters of your existing hiring processes. A general flow might include these touch-points with the option to simplify further as time and availability require:

  1. Initial screening by you OR partner agency locates a potential candidate
    • Decision (move forward or end)
  2. Portfolio review AND cross-discipline chat OR hands-on activity
    • Decision (extend offer or end)

Additional explanations of each of the activities can be found below.

Before interviewing

Goal Clarify the type of work you’re looking for this designer to do
Flow Define (loosely) the areas you want your design contractor to help explore.

Review the road map; has anything changed?

Suggest writing down answers to these questions for use in screening and portfolio review either as guidelines or as guardrails.

  • Where is the product in its lifecycle? (e.g., pre-launch, launched, etc.)
  • What are the major things this contractor will help the team solve?
  • What would a successful hire look like? An unsuccessful one?

Initial screening

30 minutes if run by a product manager; N/A if run by partner agency

Note: If done by a partner agency, prep the agency with a high-level overview of the desired designer

Goal Determine if a candidate is worth interviewing at length
Flow Quick overview of project/product (5 minutes)

Questions for them (20 minutes)

  • Suggest using questions from #1 and #2 above, but can certainly use others as appropriate
  • Would aim for 2–4 questions total

Questions from candidate (5 minutes)
Decision moment Indicators to proceed to portfolio review and activity

  • Talks about users and research
  • Mentions working in a lean way
  • Can describe their design process as it relates to successful product outcomes rather than artifacts and outputs
  • Mentions collaborating with various disciplines

Indicators to stop

  • No discussion of users
  • Can’t describe their process or it is waterfall (big design with long feedback loops)
  • Little desire to work in a balanced team

Portfolio review

30 minutes run by a product manager (or similar)

Goal Get a sense of work the candidate has done and how well they can explain their process
Flow Quick intros/re-intros

Portfolio review (20–25 minutes)

  • Prompt them first then ask follow-up questions from the things to look for and ask about section above.
  • Prompt: “For the portfolio review, I’m looking for you to show one, at most two projects that show your process as a designer. Ideally I’d like to see projects that have made it to production and are being used by users. If you need two projects in order to speak to your whole process, that’s OK.”

Wrap up and Q&A (5 minutes)
Look for ✅ Green flags (i.e., good things)

  • Has conducted and advocates for research
  • Is collaborative across disciplines, including engineering
  • Has experience working with other stakeholders and subject matter experts
  • Demonstrates an ability to stay lean
  • Has worked with a design system before

❌ Red flags (i.e., bad things)

  • Difficult to follow their thinking
  • Designs based on requirements (i.e., looking to be told what to make)
  • Users either not involved or an afterthought

Option 1: Cross-discipline chat

20–30 minutes run by an engineer (ideally)

Goal Give the candidate a sense of how the client approaches cross-discipline work while getting a read on their collaboration skills
Flow Quick intros (5 minutes) Questions for them (15–20 minutes)

  • Suggest using questions from #1 above, but can certainly use others as appropriate
  • May want to see if the engineer has some questions they might want to ask

Questions from candidate (5 minutes)
Look for ✅ Green flags (i.e., good things)

  • Is able to hold strong to design while supporting engineering
  • Is willing to compromise where appropriate
  • Is interested (and/or eager) to get engineering input on their designs
  • Has good listening skills

❌ Red flags (i.e., bad things)

  • Has little to no experience working with engineers
  • Isn’t sure how to engage with an engineer
  • Isn’t willing to get engineering feedback; prefers to dictate/hand off designs to be implemented exactly as made

Option 2: Hands-on activity

30–45 minutes run by a product manager (or similar)

Goal Get a sense of how the candidate approaches tackling a real problem
Flow Set stage for the discussion (5 minutes)

  • Intros if needed
  • Set up the goal of the discussion: “For this session, we’re going to collaborate on solving a real user problem. We may not get all the way to a solution, but that’s OK. I’m mostly looking to get a sense of how you approach the problem.”

Collaboratively work through the problem (20 minutes; longer if doing 45-minute session)

  • Ask about a problem that is top of mind for the team (especially if it’s one that has recently been discussed or even solved; it doesn’t have to be brand new).

    For example, if you are working on a tool that helps visualize data and you want to extend the existing visualizations to add additional data, you could give a bit of context about that then ask “Where do you think we should start?”

  • If appropriate, share a link to artifacts (a QA site, a design mock, etc.) so candidate can get context
  • Go as far as you’re able in the time available toward a lean solution

Questions from candidate (5 minutes or as needed)
Look for ✅ Green flags (i.e., good things)

  • Collaborates effectively and builds rapport
  • Asks good context-setting questions and gathers evidence (and/or calls out assumptions that aren’t supported with evidence yet)
  • Willing to push back and defend decisions without being aggressive but also compromise in the face of new information
  • Strives for simplicity in their approach and/or mentions wanting engineering input

❌ Red flags (i.e., bad things)

  • Is not an effective collaborator and/or has trouble building rapport
  • Makes a lot of decisions based on implicit assumptions
  • Unwilling to compromise or pushes back aggressively/condescendingly
  • Introduces a lot of complexity either knowingly or unknowingly

Final decision

Goal Determine whether or not to give the candidate an offer
Decision moment Indicators to offer contract

  • Positive takeaways from portfolio review and activity (see the green flags for each)
  • Other positive aspects (timeline, hourly rate, start date, etc.)

Indicators to stop

  • Negative takeaways from portfolio review and/or activity (see the red flags for each)
  • Up to you how many negative takeaways to look for

After hiring: Onboarding a new designer ??

Goal Get new hire onboarded smoothly and quickly

Keep an eye out for any signs that the hire is not a great fit
Flow Onboard them to appropriate tools (e.g., Figma, Miro, Pivotal Tracker, etc.)

Do an overview of the project/product, including road map and areas for design exploration

Share with them any key design artifacts the team has made (below in this article)

Schedule recurring 1-on-1s to make space for feedback (both directions)

Key design artifacts for new hires

Once you’ve hired a design contractor or vendor, it’s critical to get them up-to-speed on your work. This is a non-comprehensive list of design and team artifacts that a new designer would likely appreciate having access to as they onboard.

  • Overview and access to the team’s road map and backlog of work
  • Location of the team’s collaborative visual work (e.g., Miro, Mural, etc.), pointing out anything that is specifically design-oriented (e.g., design critiques or brainstorming activities)
  • Location where any existing designs live (e.g., Figma, Sketch, etc.)
  • Overview, if possible, of how those designs are laid out (e.g., if there are multiple pages, what is the purpose of each?) so the design contractor can get up to speed quickly
  • Location, if any, where any existing research notes or synthesis has taken place
  • Location of a shared team drive (e.g., Google Drive, Sharepoint, etc.), pointing out any design-oriented folders they should know about
  • Location of any special fonts or other design artifacts (e.g., videos, stock images, logos, etc.) that the designer may need to use

Areas for design exploration

Here are a few questions the team can ask to help identify upcoming work that could benefit from dedicated design thinking. The goal is to point the designer in the right direction—and/or, if you’re early in the process, to help justify why you need a design contractor in the first place.

  • Is there a problem or solution you identified during a Discovery and Framing that wasn’t a priority then but is quickly becoming the next priority now?
  • Is there a feature set you’ve already implemented in a lean way that you need to extend to make even more impactful?
  • Were there any recent research learnings that the team has found particularly compelling but which have taken a back seat to other in-flight priorities?
  • Is there another persona whose experience the team is ready to investigate further?
  • Are there mobile/tablet considerations that the team is ready to optimize for?
  • Is there anything lingering in the “unprioritized” section of the team road map that is worth digging into via some sort of research?

Related Articles