dobtco / gbas Goto Github PK

Outcome

• Screendoor reviewers can easily see whether an interview was conducted, scheduled, cancelled, etc. with an applicant.
• Admins and interviewers can easily access an applicant's Screendoor response when an interview takes place.

Structure

• Add interview details to the activity feed
• Add a link to the applicant's Screendoor response on everything: calendar invites, confirmation emails, the admin dashboard, etc., so it's impossible to miss

More TBD...

Outcomes

• Admins should clearly understand the difference between "regular booking" and "auto-booking"
• Admins can easily add staff who they know will be available for everything
• Admins can customize the schedule of their invited staff: for example, saying auto-booked HR monitors should have a break every other timeslot

Structure

TBD. Also might want to question the outcomes here a bit...

Breaking this out from #12

Outcome

If a candidate selects a timeslot that cannot be fully booked, admins can easily reschedule them in another free timeslot.

Structure

Sketch out a "Reschedule" UI stemming off the timeslot page.

Interaction

TBD

Outcome

When admins try to add staff to an interview, they should understand who has or hasn't previously indicated their availability.

Structure

Design an "add staff" UI on the timeslot page which accomplishes this

Interaction

TBD

Outcome

Allow the admin to accommodate candidates who cannot make any available timeslots.

Structure

Let admins add a timeslot to the dashboard.

Interaction

TBD

Outcome

If a large number of staff under-select their availability, and many timeslots cannot be automatically booked, the admin should have a clear path to success.

(paraphrased from this comment)

Structure

TBD

Some suggestions:

• Rendez (like rendezvous)
• Rondé
• Calenta
• Dayt
• Convene
• Conveen
• Rally
• Rallie
• Assemble
• DayPlan

Any others?

This can be labeled as hold if we wish, but it's just something I came across when coding the timezone stuff.

Say you want to have interviews start at 10pm, and end at 2am. If you choose "schedule interviews on Monday", only half of your times will actually fall on a Monday, and the midnight - 2am shifts won't be scheduled.

Outcome

If demand is much higher than admins anticipated, let the org easily accommodate extra candidates.

Structure

• Let admins add many timeslots at once
• Send a new invite to those extra candidates, explaining new timeslots? (perhaps add a new email to the list in #13)

Interaction

TBD

Invite-related

Remember to include links to responses and calendar invites...

• Applicant confirmation
• Staff confirmation
• Applicant follow-up, with call details
• Staff follow-up, with call details
• Applicant confirmation, interview manually added by admin
• Applicant invite revision (rescheduled by admin)

Transactional emails for staff

• "This interview has been cancelled"
• "All of your interviews have been cancelled"
• "You have been transferred?"

Outcome

Depending on where an admin is in the interview process, we should alert them to important and relevant information each time they log into the dashboard.

Structure

Sketch out user flows and / or mockups for the dashboard in these states:

• Right after the admin sends invites
• Admin returns, some time slots are scheduled
• Admin returns, all time slots are scheduled
• Location / details haven't been filled in
• "Alert" state: many staff haven't selected yet, close to interview period
• "Alert" state: many candidates haven't selected yet, close to interview period

GBAS wants oral presentations and behavioral interviews to intermingle in the same duration, because... their staff are very busy?

Because we're holding on #26, we need a page in the dashboard that allows admins to manually add and remove applicants from their interview process.

From a convo with @jkgoldst:
After talking through the workflow for this project and building out a lot of it in Screendoor, we've identified two pain points we may hit while moving data between the Main Applicant Database (MAD) and the individual projects where the HR Joint Assessment will happen (including writing sample, CV review, behavioral interview, & oral presentation).

Outcome

Find the easiest way to transfer the data on each qualified respondent in two directions:

1. Transfer data on qualified applicants in MAD and import into separate HR Joint Assessment project(s) -- one project per posted vacancy.
2. Move final scores from Assessment phases (writing sample, CV review, behavioral interview, oral presentation) into MAD to show as columns. These scores will then be used to cull applicant pool further before matching process.

Once the admin is finished setting up, what do they see?

Outcomes

If an admin has multiple conference rooms, let them schedule 1 in each location at the same timeslot.

Structure

• When setting up, let admins indicate how many interviews they want in each timeslot.
• Nice to have: make it easy to designate meeting locations for each slot?

If an applicant or SME never received one of the invite-related emails in #13, an admin should be able to easily resend it.

Outcome

When an office has a holiday, training day, or other "off day", allow admins to prevent adding time slots during those days.

Structure

• Let admins exclude days from scheduling period during setup
• Nice to have: by default, automatically exclude legal holidays from scheduling period

To consider: the Doodle has interview days starting at different times, so they might want to exclude individual timeslots as well.

Interaction

TBD

Breaking this out from #12

Outcomes

If the admin needs to take action during an interview period, they should be notified accordingly.

Structure

Brainstorm...

• The alerts an admin needs to see, and when
• When to send follow-ups

Copying @ajb's last comment in dobtco/dobt#1608:

Some meta-feedback: I try to make screenshots of user flows (or anything, really) < 1500px wide, so that they're easy to read on most screens.

Thanks for the suggestion. I kinda struggled making that chart... I think I need to learn Sketch or something too.

I disagree with your assessment that this is a "manual scheduling UI with a computer assist." Maybe I gave you the wrong ideas with my WIP modeling, but depending on the constants that I throw at the model, over 90% of the appointments can be booked automatically. I would obviously like this number even higher, but I would feel comfortable saying that we should aim for 90% or higher as a measure of success.

(Let's go over the modeling on Monday, it's a little more than I want to write up in here.)

Also, the modeling will allow us to determine what factors are necessary for more appointments to be booked without admin intervention. For example, we can tell users "please increase the number of timeslots", "please ask reviewers to pick at least 6 timeslots", "please increase your number of reviewers", etc. Also, my modeling doesn't account for users who have nearly full availability, like those two did last year. If we add them, 100% of the slots will have enough reviewers.

The wizard currently sets a definitive start date. Your flow assumes that the admin will move everyone through all three phases before that start date happens. If the admin forgets to do that work, what happens to the start date? What do we do when the admin goes on vacation / gets sick, becomes busy with something else, our reminder emails go into their spam folder, etc?

If the admin is going on vacation, we can let them "set it and forget it" and automatically set a date for Phase 2 to happen.

If very few have responded by the Phase 2 date, I'm not sure that's a problem that we can be expected to solve.

Also, I think we can safely assume that for this GBAS deployment, Nicole will be very on top of things.

Let's say the admin enters "Phase 2" when very few applicants have selected... maybe they pressed "Generate schedule" by mistake, or most of the participants are laggards like I mentioned above. Is there a way to automate the schedule again when more available times come in?

Yup, I just updated the simluation to include this. You can run an "auto-book" at any time, and it won't change any appointments that have already been scheduled. (This makes it safe to run at any time.)

We're asking the staff to do a lot of work: either we make them manually adding a bunch of "hold" invites to their calendar, or we attach one invite file for each event to their confirmation email, and make them open and accept each one. Is it a reasonable assumption that they'll do all of this? If enough staff members don't, GBAS will run into the same headaches.

This is a good question, I'm glad you bring it up. Instead of sending calendar events (.ics files?) and expecting users to manually download and add them to their calendar, we could publish a per-user calendar feed that would automatically update. (Here's a project where I've done this before: https://github.com/ajb/milestone-cal)

We can also encourage users to pick less-selected timeslots by subtly highlighting them and prompting them with some friendly copy.

I see this as kind of the core of my original flow, but I thought you said it wasn't technically feasible to implement. Could you explain again what makes my concept difficult to build? If I have a better understanding of this, I can be more effective in making valuable contributions towards what we eventually decide upon.

To be clear, this is what I'm advocating for in my flow:

It's kinda clunky, but it could help the algorithm be more effective.

The part of your concept that I'm resistant to is that all of the flows in this screenshot would add a ton of complexity to our application, and in my concept, they are consolidated into a single flow.

Outcome

When an admin see the details of a timeslot, we should show them the most relevant information relative to when that timeslot occurs.

Structure

Sketch out timeslot page mockups and / or user flows for...

• No attendees
• Candidate signed up, no / some staff booked
  • "Alert" state, a few days before interview starts
• No candidate, some staff booked
• No candidate, all staff booked
• All attendees booked
• Day of interview
• After interview / after timeslot

Outcomes

• Avoid displaying every calendar invite in an arbitrary time zone that might be irrelevant to the customer (like GMT).
• Ensure applicants and interviewers are viewing time slots in their current time zone.

Structure

• Ask the admin to choose a time zone for their project.
• Ask everyone to choose their time zone before viewing time slots. (We can use the browser's locale to select a smart default.)

Interaction

We can take a page from Calendly's book, and make the time zone dropdown a nice selectize with optgroups for each continent / region.

Separating this task from #22 as it's fairly meaty on its own.

Outcome

Nice to have: if staff, who live in Screendoor and aren't necessarily aware this app exists, lose their invite email, they can easily retrieve their meeting details from Screendoor.

Structure

TBD. One idea: Let reviewers download their calendar invites in Screendoor, or (in our v2?) see it on a new "Calendar" page

Outcome

Admins should know how many candidates they're inviting to interview.

Structure

When the admin is selecting candidates through a Screendoor filter, show the admin how many responses they've selected.

Outcome

Admins can add supplemental details, like locations and interviewer roles, to time slots more efficiently than going one-by-one.

Structure

Include a "bulk edit" feature in the admin dashboard.

Interaction

TBD

• More colors
• Background image for first section?

Outcomes

Let's say admins want to schedule everyone in a project with a status of "Interview." So, after the first scheduling emails are sent...

1. When a Screendoor reviewer moves 1+ responses into "Interview", they should know those respondents will also receive scheduling requests.
2. When a Screendoor reviewer moves 1+ responses into "Interview" by mistake, and then moves them out, the scheduling requests should be cancelled.

Structure

• After schedule requests have been sent, add some UI feedback into Screendoor to meet the first outcome
• To reduce the impact of errors, wait an hour or so before sending interview requests to newly moved responses, and then check to see whether they were moved back
• If respondents have already received invites and a reviewer tries to change their status, make the reviewer confirm the change
• If the reviewer does change their status, send the respondent a "cancellation" email (add this to #13)