Ashby UX Technical Challenge

Why are we doing this?

We want to learn how you approach open-ended product design problems, how you make decisions on scope and user flow, and how you justify those decisions. While this take-home won't give you the time you would typically spend to "solve" a problem of this scope, it does replicate some of the speed at which we work at Ashby: our first iterations often rely on gathering some initial research (some of which we've provided below) and then using instincts, experience, and best practices/patterns to deliver artifacts that direct the final design (e.g., rough wireframes).

We do not want you to produce "polished" user interfaces or visual design!

Take-home or Live

We provide both a take-home and live-over-Zoom option for this challenge. We may communicate a preference for take-home if we can't get a signal in our prior portfolio review, but we'll offer both options when possible!

In both options, we expect artifacts but what they are is up to you. We're leaving this purposefully open-ended because you'll be dealing with this ambiguity in the role —you're our first product designer, and we have no defined process around design.

Regardless of which option you take, we'll provide detailed feedback if we decide not to move forward.

Take Home

There is no time limit on the take-home, but we ask for it back in about a week (we're happy to accommodate longer timelines). Some details:

• We should easily view your submission in Mac Preview, Figma, or some other software that doesn't need to be purchased.
• If you use any icons, frameworks, libraries, or other assets, don't worry about licenses.
• After submission, we'll schedule 45 minutes to discuss it over Zoom.

Live (2 hours)

You'll spend time with us talking through the challenge and building whatever artifacts you would have on your own (now together!). Two hours is a long time, so we've factored 5 minutes in for a short break. We ask that you read this document and think about the prompt before meeting.

We'll use the following tools to collaborate (but feel free to suggest something else if you'd prefer):

• Notion - Requires Account
• Excalidraw
• Figma - Requires Account

The Challenge

This challenge will focus on sales problems at business-to-business software companies. When a potential customer is interested in trialing a product, a salesperson builds a plan with the customer to set up and evaluate the software. This plan aims to make sure there's a mutual understanding of what the customer wants to see from the product, what steps are necessary to get the software set up and evaluated, who needs to complete those steps, and when they should be completed.

For this challenge, we want you to design a product that allows a salesperson:

• To build a plan for a customer. The plan doesn't need to be shared with the customer.
• Understand what they need to do next or who they need to follow up with
• Track progress and determine if they're falling behind schedule

If you go the take-home route, you're more than welcome to spend time with us to gather more information.

Example

We'll use Ashby as an example. We offer a two-week trial for our analytics product. The trial can be extended if the customer doesn't have time to evaluate.

Roles

We usually have to involve the following roles:

• Salesperson @ Ashby
• PM @ Ashby - If new features need to be added, they'll be involved by the salesperson to determine timelines
• Evaluator @ Customer - Uses the software during the trial and presents opinions to the decision-maker
• Decision-Maker @ Customer - Greenlights and approves budget for Ashby
• IT @ Customer - Sets up Ashby
• Security @ Customer - Reviews Ashby's security policies

The same person can fill multiple roles, and multiple people can fill one role.

Plan

A trial of Ashby unfolds in three phases: setup, evaluation, then purchase (if the customer is interested in purchasing). The phases overlap (e.g., steps can happen in parallel) but are mostly one after the other. The plan can change as a salesperson gathers more requirements and feedback from the customer (e.g., more steps are added).

Setup

1. Before trial - Salesperson and evaluator determine if security review is necessary for trial
2. Before trial - Security review (If not necessary skip to [3]):
   • Determine who is point of contact (either evaluator or security)
   • Send security documents to point of contact
   • Wait for approval from point of contact
3. Before trial - Salesperson sets up an account for the evaluator
   • Create Ashby account via internal tool
   • Ashby creates a shared slack channel and invites the user
   • Email evaluator once complete. There's an email template the salesperson can use that includes links to help documentation
4. Before trial - IT sets up Greenhouse API key and adds to Ashby
5. Before trial - Ashby completes initial ingestion of Greenhouse Data
   • Email evaluator that ingestion is complete and trial begins

Evaluation

1. Before trial - Salesperson meets with decision maker, evaluator to identify reporting needs:
   • Identify what recruiting metrics they're currently tracking
   • Identify what new questions they want to ask from their data
   • Determine 5 recruiting metrics and/or questions that, if Ashby answered, decision maker would purchase Ashby
2. At Most 1 Day After [Setup:5] and [1] - Salesperson builds an Ashby dashboard in customer's account that shows off 5 recruiting metrics
   • Share with evaluator
3. At Most 1 Day After [2] - Meet with decision maker, evaluator to explain dashboard and do initial training
   • Follow up with email template that includes help documentation
4. 2 Days After [3] - Check in with evaluator
5. 5 Days After [4] - Check in with evaluator
6. 1 Day Before Trial End - Salesperson meets with decision maker, evaluator to determine if they want to purchase
7. After trial end - Salesperson deactivates account

At any point during evaluation:

• The customer may require features that Ashby doesn't have. At that point, the salesperson would create step(s) to get a timeline from the PM.
• The evaluator may fall behind on their evaluation, and the trial can be extended.

Purchase

1. After trial end - Salesperson sends license information and pricing to decision maker, evaluator
2. After trial end - Salesperson identifies number of licenses with decision maker, evaluator
3. After trial end - Salesperson, decision maker, and evaluator agree on total contract length and price
4. After trial end - Salesperson sends purchase order to decision maker
5. After trial end, in parallel to [1-4] - If security review is necessary and wasn't done in [Setup:2], salesperson and evaluator determine if security review is necessary for trial
6. After trial end - Perform security review:
   • Determine who is point of contact (either evaluator or security)
   • Send security documents to point of contact
   • Wait for approval from point of contact