Penknife

01 / The Fork

One product that had to be two

Penknife looks like one recruiting platform. It is sold as two.

The first buyer is a hospital's own talent team — hiring nurses, technologists and clinical staff onto its own payroll. The second is a staffing agency — 314e's own recruitment desk first, then the agencies it sells to — placing contract clinicians into hospital networks nobody in the room owns.

Those two businesses share almost everything you can point at. A person. A role. An application. An interview slot. A start date. What they don't share is what any of it means. For a hospital, a filled requisition ends the story. For an agency, a placement is where the story starts earning — it hangs off a deal with a bill rate and a client who is watching the clock.

The obvious answer was two products. We had one team, one codebase, and hospital clients who wanted both.

The finding that shaped the build: the split people expected in the data barely existed. It lived almost entirely in the first screen after login.

The proof is in the sidebar

Three real accounts, three navigations. Nobody configured these by hand — the nav is assembled from what the signed-in user is entitled to. Give someone both entitlements and the Dashboard item grows a level rather than the app growing a mode switch.

Staffing permission Relationship-led home

Penknife staffing dashboard — followed records, today's meetings, recently interacted contacts

Opens on Followed Records, today's meetings and recently interacted contacts, under Overview / Pipelines / Activities tabs. An agency recruiter's day starts with who they owe a reply to. Note what's missing from the sidebar: Applications.

Internal hiring permission Requisition-led home

Penknife internal hiring dashboard — recently assigned jobs, calendar, scheduled interviews

Opens on Recently assigned jobs with per-stage counts, a calendar, and scheduled interviews with assessment cards attached. A hospital recruiter's day starts with the reqs they own — and Applications appears as a top-level object.

Both permissions The nav grows a level

Penknife sidebar for an admin holding both staffing and internal hiring permissions — Dashboard expands into Staffing and Internal Hiring

Dashboard expands into Staffing and Internal Hiring. No app switcher, no workspace picker, no second login. The one place the two businesses genuinely diverge is the one place the IA branches.

Three accounts, one build — sidebar detail, cropped from full-screen captures

The navigation isn't a menu we wrote. It's what your permissions add up to.

02 / Context

A staffing operation running on spreadsheets, sold as a hospital's own software

314e Corporation is a US healthcare IT company in the SF Bay Area. Part of their business is running large staffing operations for hospital systems — hundreds of open clinical positions at once. When we joined the project they were doing it with fragments: a generic ATS, a disconnected CRM, email threads, and spreadsheet pipelines held together by people remembering things.

Penknife was 314e's answer — their own platform. Its commercial model was white-labelling: the hospital gets a fully branded recruitment system (their logo, their domain, their colours) while 314e operates it behind the scenes. UCLA Health is one confirmed deployment.

That model had a direct design consequence. We couldn't lean on product identity as a quality signal. Nobody would ever see a Penknife logo and infer competence — every screen would be wearing someone else's brand. The experience had to carry it alone. The tool had to be recognisably good, not recognisably Penknife.

It also meant the platform had to sell twice: to hospitals who wanted to run their own hiring, and to agencies who wanted to run staffing desks. Same software, two contracts, two vocabularies.

Reconstructed synthesis · not an original research artefact

The recruiter's desk had four versions of the truth.

AGeneric ATS

Where the candidate's pipeline stage lived.

CSeparate CRM

What the hospital client believed was happening.

@Email

What was actually said — trapped in personal inboxes.

#Spreadsheet

The weekly report, already stale when it was read.

A visual reconstruction of the workflow described in research synthesis. It compresses the same evidence in the text above; it is intentionally not presented as a photograph of the original fieldwork.

03 / The Problem

Healthcare recruiting isn't like other recruiting

The complexity is higher on every axis. Candidates carry multi-layered credential requirements — licence types, specialties, compliance documentation. Positions are often urgent; a clinical coverage gap affects patient care directly. And the regulatory environment adds verification layers that generic platforms were never built to hold.

Why a CV match is only the beginning

Open clinical shift

A coverage gap has a patient-care consequence. The clock is already running.

01 Licence Right type, current and valid in the state.

02 Specialty Clinical experience must fit the actual unit.

03 Shift pattern Availability has to match hours and cadence.

04 Compliance Documents must be present, verified and auditable.

Eligible for this job

Not merely qualified on paper — placeable in this hospital, now.

Generic ATS failureAll four healthcare gates were flattened into free-text notes, making them difficult to search, compare or audit.

Four disconnected tools

ATS for tracking. A separate CRM for client relationships. Email for communication. Spreadsheets for reporting. No single source of truth, and no agreement on which one was authoritative.
No unified candidate view

Recruiter context was scattered across systems. Every handoff meant re-explaining a candidate's history from scratch, usually over Slack, usually from memory.
Healthcare complexity unaddressed

Generic platforms had no concept of licence types, specialty matching, shift patterns, or compliance documentation workflows. Everything real lived in a free-text note.
Hospital clients had no visibility

Hiring managers had no real-time view of their open positions. Status was compiled by hand each week and was stale by the time it was read.
Two audiences, one backlog

Agency staffing and hospital internal hiring wanted different things from the same screens. Every feature request arrived pre-loaded with a fight about whose workflow won.
Email lived outside the record

The most important artefacts in recruiting — what was actually said to a candidate and a client — sat in personal inboxes, invisible to everyone else on the account.

"How do you design a single platform that makes a recruiter's full day — sourcing to placement — faster, less error-prone, and contextually aware of healthcare's demands — without forking into two products the day a hospital asks for one?"

04 / Who Logs In

Five people arrive with five different questions

The shared record was an architecture decision. The experience still had to begin with a person in a moment: a recruiter starting a shift, a manager between rounds, or a candidate applying after work. Mapping those moments made the permission model much easier to reason about than a conventional persona grid.

Agency recruiter reviewing active pipelines — One hiring record · five working moments

Hospital talent partner reviewing job requisitions — One hiring record · five working moments

05 / Research → The Insight

The ATS/CRM split was the whole problem

We started with direct access to 314e's own recruitment team — an advantage, because we had real users from day one, and a constraint, because internal projects carry political weight. Not every pain point gets said out loud in a group with your manager in it. So we sat with recruiters during their actual workday rather than interviewing them about it.

Contextual inquiry with senior recruiters Workflow mapping — applied → placed Competitive audit: iCIMS, Workday, Lever, Greenhouse, Bullhorn Stakeholder interviews with account managers Analysis of the incumbent spreadsheet system

01 Observed behaviour Recruiters kept switching questions.

“Where is this candidate?” was immediately followed by “What does the client know?” The workflow crossed the ATS/CRM boundary even when the tools did not.

02 Recurring pattern Every object carried two meanings.

A candidate was both pipeline state and relationship history. A job was both a requisition and a client promise.

03 Product principle Collapse the boundary, preserve the perspectives.

One object model and activity history underneath; permission-shaped navigation for staffing and internal hiring above it.

Contextual inquiry · applied-to-placed workflow map · incumbent spreadsheet analysis · account-manager interviews

The finding that mattered: ATS and CRM functions are not separable in a recruiter's head. A candidate is also a relationship. A job opening is also a client deliverable. Every recruiter described toggling constantly between tracking where a candidate sat in the process and managing what the client believed was happening. Generic platforms enforce that split at the tool boundary. Penknife's premise was to collapse it.

The re-key marks are where the old workflow lost information. Collapsing them was worth more than any single feature we shipped on top.

06 / The Object Model

Applications is the join. Activities is the glue.

Given the volume Penknife handles — candidates, jobs, clients, interviews, tasks, communications, compliance documents — IA was the phase that decided whether the rest would work. We ran card-sorting and tree-testing with recruiters to learn how they grouped things, rather than assuming.

What came back was an object model, not a feature list. Recruiters navigate by what they are looking for, not by which step of a process they're on. So the sidebar became a list of nouns, and every screen in the product became a filtered view of one of them.

Candidates Jobs Applications Placements Companies Contacts Opportunities Tasks

Application is a first-class object, not a status field on a candidate — which is why it can carry a fit score, a stage, an interview and a client's feedback without any of them belonging to the person.

Search as the model, exposed One field, six object types, counted

The global search returns Jobs (67), Applications (79), Candidates (99), Company (99), Placement (99) and Opportunity (99) as separate, countable buckets — plus a Recent list. If the object model were wrong, this dropdown would be the first place it showed.

Result shape follows object type A job result and a person result don't look alike

Job rows carry status, department, employment type and location chips with a “+5 More” overflow. People rows carry email and phone as tappable links. Same list, different row grammar — so you can tell what you've found before you read it.

Penknife global search dropdown showing results grouped by object type with counts

Global search — results grouped by object, capped at the top 100

07 / Key Surfaces

Ten surfaces that carry the workflow

What follows is the product as it actually stands, in the order a recruiter meets it. Where a surface belongs to only one side of the business, it's flagged.

07a

From requisition to live job Both sides

The jobs list is the first place the two businesses have to coexist. An agency's staffing jobs and a hospital's own requisitions sit in the same table, under the same columns, in the same pagination — because a recruiter with both permissions genuinely works across both in one afternoon.

We resisted a segmented control at the top. Splitting the list would have made the common case (find the job I'm thinking of) worse in order to make a rare case (audit only staffing jobs) marginally better. Instead the distinction became a single marker on the row, with the label on hover.

Penknife jobs listing — all jobs and drafts, with staffing jobs marked by a dot

Jobs — staffing and internal requisitions in one table

One list, two kinds of job A dot, not a tab

Staffing jobs carry a small amber dot beside the title; hovering names it “Staffing Job”. Internal requisitions carry nothing. The default state stays quiet — you only pay attention to the distinction at the moment you need it.

Drafts are a peer, not a filter All Jobs 85 · Drafts 99

More jobs sat in draft than live. Half-written requisitions are a real state in healthcare hiring — approvals stall, headcount moves — so drafts got their own counted tab rather than being buried behind a status filter.

Recruiter is a column Ownership is visible before you open anything

Job title, recruiter, openings, status, department, location, created date and job ID — the columns a recruiter uses to answer “is this mine, and is it still live?” without a single click.

Visibility first, everything else after Public · Private · Confidential

The very first control on a new job is who may see it. Confidential requisitions are real in hospital hiring — replacing a department head who hasn't resigned yet. Getting this wrong is unrecoverable, so it sits above the title field, not in an advanced section.

The pipeline is part of the job Stages are configured per role, from templates

A Pediatric hiring pipeline is not a Physio Intern pipeline. Stages are built inline — Applied, custom stages, then the fixed terminals Hired / Rejected / Withdrawn — and saved as reusable templates with a last-modified date. Recruiters clone far more than they author.

Screening moves upstream The questionnaire is authored with the job

Multiple-choice screening questions, reorderable, importable from templates, each individually required or not. Asking the licence question at application time is what makes the AI score downstream worth anything.

Three exits, honestly labelled Save as Draft · Preview · Add & Publish

Publish means the job goes live on the hospital's white-labelled careers site. Preview shows exactly that page before it's real. Given the audience, we never let “save” and “publish” share a button.

Penknife new job form — job details, hiring pipeline builder and screening questionnaire

New Job — one page, three sections, jump-nav on the left (the frame auto-tours the full form)

07b

Three ways to find a person Both sides

Every recruiter we shadowed searched in one of three registers, and they were not interchangeable. Sometimes you know the name. Sometimes you know the shape of the person but not the name. Sometimes you have 220 applicants and one afternoon. We built a different instrument for each rather than one search box pretending to cover all three.

All three assume the person is already in the database. The fourth register — the one where they aren't — turned out not to belong inside Penknife at all. That's section 08.

Three instruments, three failure modes. Naming what each one can't do was how we stopped them collapsing into a single mediocre search.

Penknife query builder — nested boolean rules and groups with full-text resume search

Advanced filter — nested rules, groups and subrules over structured fields and resume text

Boolean, made visible Not / And / Or as a segmented control per group

Recruiters were already writing boolean strings into other tools and getting them subtly wrong. Making the operator a visible, per-group control — with the group's scope drawn as a bracket down the left — turned a syntax problem into a structure problem.

The resume is a searchable field Rules can reach inside the document

A rule can target Resume and full-text search it, then carry subrules underneath — Skills, and further fields — so “has this in the resume, and specifically these skills” becomes one expression instead of two searches and a manual intersection.

Complex searches are assets Search / Saved as peer tabs

A good ICU query takes real effort to compose and gets rerun weekly. Saved sits beside Search at the top of the modal, and Save Search sits beside Apply Filter at the bottom — so the effort is banked at the moment it's spent.

Penknife tasks table with related-to and other-references columns — **The same table grammar, everywhere**Tasks reuses the identical shell — date-range filter, sortable and individually searchable column headers, the same customiser and pagination. Learning one table in Penknife teaches you all of them, which is most of why the tool onboards quickly.

Penknife column customiser — reorderable, pinnable columns — **Columns are the user's, not ours**Every table shares one compact customiser: searchable, drag-to-reorder, per-column pin and deselect-all. Full Name is pinned by default and stays anchored while the rest scroll. A recruiter chasing certifications and one chasing phone numbers gets the same screen configured two ways. The detail is shown near its native size rather than stretched into a second full product screen.

07c

Scoring, without the black box Both sides

Penknife scores candidates against a job's requirements. For clinical roles that means licence type, specialty match, years in specific care settings, and location or availability constraints — which is exactly why it can be useful, and exactly why recruiters were suspicious of it.

The design problem was never accuracy. It was standing: what authority does this number have in the room, and what happens when a recruiter disagrees with it? Three decisions came out of that.

Penknife applications table with fit score, relevance chips and stage tabs

Job record → Applications — fit score as a column, stage as the navigation

Decision 1 — two layers, not one number A judgement chip beside the raw score

Each row shows Relevant or Irrelevant next to a numeric score. The chip is what you scan; the number is what you interrogate. In testing, recruiters trusted a number more when it was accompanied by the model's own plain-language read of it.

Decision 2 — show the work in progress “Calculating” is a visible state

Scores arrive asynchronously, so a row can sit in Calculating with a spinner. We refused to render a placeholder zero or an empty cell — both read as “this candidate scored badly”, which is a lie the recruiter acts on.

Decision 3 — the stage tabs still win All 160 · Applied 80 · Review 30 · Interview 1/2/3 · Rejected · Hired

The primary navigation of the applicant list is still process state, not score. The AI sits inside the recruiter's existing structure rather than replacing it — you never have to adopt the model's worldview to use the table.

The threshold belongs to the recruiter A slider from Irrelevant to Relevant, not a ranking

“Filter by AI Scoring” sets a floor — shown here at 65 — with the track labelled Irrelevant → Relevant and thumbs-down / thumbs-up anchoring each end. The model narrows the pool. The recruiter defines what “narrow” means, and can change their mind in one drag.

Opt-in by construction AI Recommendations is a tab, never the default

It's one of five tabs on the job record — Applications, Details, Activities, Draft Applications, AI Recommendations — and the record opens on unfiltered Applications. Reaching for the AI lens is an action you take, not a filter applied to you on entry.

Freshness is stated, not implied “Last Updated: 6 Days Ago”

Sat in the toolbar beside the search field. Scores drift as jobs are edited and resumes are updated. A stale score presented as current is the fastest way to lose a recruiter's trust permanently, so the age of the answer is always on screen.

Penknife AI Recommendations tab with the fit score threshold panel

AI Recommendations — the recruiter sets the cut-off

On honesty

We designed the interface around the score, not the model. How it was trained and weighted was engineering's; what a recruiter was allowed to conclude from it was ours. Keeping that line visible is the reason this feature became something account managers led with in pitches instead of something recruiters quietly switched off.

07d

The home screen is a shift hand-off Internal hiring

The internal-hiring dashboard was not designed as a report. It was designed to help a recruiter resume a working day: which requisitions are active, where applicants are accumulating, and which interviews need an assessment next.

The same screen used on the cover makes that hierarchy visible without invented call-outs or a separate marketing mock-up.

Penknife internal hiring dashboard with assigned jobs, applicant counts, calendar and scheduled interviews — Reading the dashboard from left to right

07e

Every record has the same anatomy Both sides

This is the least visible decision in the product and the one we'd defend hardest. A task, a job, a contact and an opportunity are wildly different things — but in Penknife they are all built from the same four parts, in the same order, with object-specific tabs added on the end rather than mixed in.

The payoff is compounding. A recruiter who has opened one record knows where the audit trail lives in every other record, forever. It also meant the drawer, the full page and the slide-over could share one implementation, which is how a small team shipped this many object types.

Tab lists transcribed from the shipped screens. The object-specific tabs are appended, never interleaved — so the audit trail is always in the same place relative to the end of the list.

Penknife edit task drawer — details tab with polymorphic reference fields — **Details — where the graph is actually built**Two reference fields do the structural work: *Related to (Candidate, Contact)* and *Other References (Job, Opportunity, Placement)*. A task isn't filed under one parent — it's pinned to the graph, so it surfaces on every record it concerns. Owner and collaborators, due date and time with an explicit timezone, and a reminder offset complete it.

Penknife edit task drawer — activities tab with an append-only log — **Activities — append-only, with a counter**The tab carries its own count (99) so you know there's history before you open it. Entries are timestamped, individually actionable, and long notes clamp to a *Show More* rather than pushing the composer off screen. Nothing here is editable in place; corrections are new entries.

Task drawer — the same two-tab shell used for creating and editing

Same spine, full-page scale Details · Description · Activities 99 · Files 20 · Edit history

The opportunity record uses a left jump-nav instead of tabs because the content is long — but the sections are the same spine in the same order. The pattern scales from a 500px drawer to a full page without a recruiter having to relearn anything.

Primary and secondary details, separated Deal value up top, expected bill rate below

Opportunity ID, name, deal value ($340k), status and contact sit in Primary. Expected bill rate, added-by and closed reason sit in Secondary. The split came from watching who reads which — account managers scan the top, finance reads the bottom.

Activities filter to what you're auditing All · Email · Starred, plus per-entry star and share

Stage changes and outbound emails land in the same chronological feed, each with the related job linked inline. Starring is how an account manager marks the two entries that matter before a client call.

Edit history is a table, not a footnote Field · Changed from · Changed to · Modified by · Modified on

Paginated and sortable, at the bottom of every record. This is what compliance asked for and what settles arguments — including the ownership change visible here, from Steve Rogers to Aayush.

Penknife opportunity detail page — details, description, activities, files and edit history

Opportunity record — full page, same spine (the frame auto-tours every section)

07f

The client side Staffing only

This is the half of the product a hospital's internal team never really uses, and the half an agency lives or dies by. It's also where the ATS/CRM collapse pays off most visibly: the same board grammar, the same slide-over, the same activity feed — pointed at deals instead of people.

Penknife opportunities pipeline — Kanban stage view with deal values

Opportunities — pipeline board with per-stage value

Deals move like candidates do Qualifying → Evaluating → Socializing → Negotiating

Identical board mechanics to the candidate pipeline — because an account manager and a recruiter are frequently the same person on a small desk, and asking them to hold two interaction models for the same gesture was never going to survive contact.

Column headers carry money Stage count and stage value, together

Each column shows both how many deals sit there and what they're worth. Pipeline health is two numbers per column, readable without opening anything — which is the whole reason an account manager opens this screen.

Act from the card Value, client, and inline actions on the face

Hospital client name, deal value, and edit / task / refresh shortcuts sit on the card itself, with the open/closed state as an inline dropdown. The most common actions never require a click-through.

Penknife opportunity slide-over panel over the Kanban board — **Detail without losing your place**Clicking a card opens a slide-over, not a page — the board stays visible behind it. Annual recurring revenue, win probability, stage, owner and company sit on the left; Description / Activities / Files / Edit History on the right. The same spine, at panel scale.

Penknife contact record with automatically logged email activity — **The relationship, logged without anyone logging it**A contact's Activities feed shows *Email Opened by Aishwariya X* and *Outbound Email by Mark Adams* — attributed, timestamped, captured from the connected mailbox. No manual entry, and the tab counts (Work History, Jobs, Opportunities, Files) tell you what else this person is entangled in.

07g

Communication as infrastructure Both sides

Recruiting is mostly email. That sounds trivial until you're sending on behalf of a hospital, from a domain you don't own, to clinicians who are legally entitled to opt out — at which point the send button is the most dangerous control in the product.

So the email layer isn't a feature; it's a chain of checkpoints, and we designed the chain before we designed any of the screens. Each link is a place a bad send can still be stopped.

Six checkpoints between a recruiter's intention and a clinician's inbox. Most email tools have two.

Penknife broadcast composer with completion checkmarks for from, to, subject and body

Broadcasts — bulk send, staged as four verifiable decisions

A broadcast is a checklist, not a form From · To · Subject · Body, each with a completion state

Four stacked sections, each carrying a green tick once it's valid. Sending to 100 people is a different psychological act from sending to one — so the composer makes you see all four decisions in one glance before Send is credible.

Audience type is chosen first Candidate / Contact toggle at the top

The two audiences have different merge fields and different legal footing. Making that the first control — above From — means the personalisation tokens offered downstream are always the right set.

Send is a split button Send, or Schedule from the caret

Scheduling sits inside the primary action rather than beside it, and Preview & Test sits immediately to its left. The riskiest control on the page is flanked by the two things that make it safe.

Compliance is default content Opt-out link and postal address pre-inserted

“Don't want to receive emails? Click here” and the physical address are already in the body, with Opt-out as an insertable block alongside Templates, Personalization and Signature. It takes deliberate effort to send a non-compliant broadcast.

Penknife preview and test dialog rendering the email as a specific recipient — **Preview as a person, not as a template**Step through recipients one by one — *1 / 90* with a name picker — and read the mail exactly as that individual will receive it, merge fields resolved. Then send yourself a copy. This is where merge-field mistakes get caught, which is the single most embarrassing failure mode in bulk recruiting mail.

Penknife in-app email composer with templates, personalization and signature — **One-to-one uses the same machinery**The single-send composer carries the same three insert controls — Templates, Personalization, Signature — and the same preview affordance. A recruiter who learned the broadcast composer already knows this one; the difference is the recipient count, not the mental model.

Penknife email settings — SMTP domain verification with CNAME records — **Deliverability, explained to a recruiter**Sending as *starlightmedicalcenter.com* means proving you own it. The screen states the status plainly (*Pending*), gives three copyable CNAME rows, says out loud that DNS can take 48 hours, and names the escalation path if it doesn't clear. Written for a recruiter who has never touched a DNS record — because that's who has to do it.

Penknife Microsoft mailbox connection with plain-English scope disclosure — **Consent written like a human wrote it**Connecting a Microsoft mailbox lists *why* first (auto-tagged activities, calendar booking links, a Penknife Reminders calendar) and then every scope in plain English — including “Send mail as you”. One toggle governs whether synced mail is visible to colleagues. We surfaced the uncomfortable permissions rather than burying them in an OAuth dialog nobody reads.

07h

Automation you can read Both sides

Automation in a recruiting tool is where trust goes to die. Something fires at 3am, touches 53 candidate records, and nobody can reconstruct why. The design brief we set was narrow: a workflow must be legible in one sentence, and its failure must be as visible as its success.

Penknife workflow automation list with active, inactive and error states — **Failure is a first-class status**Workflows list with author, age and state — Active, Inactive, and *Error*. Most builder tools show a workflow as on or off. Error as a peer status, rendered in the same column with the same weight, is what stops a silently broken automation from looking healthy for three weeks.

Penknife workflow builder canvas — trigger, condition and action nodes — **Three nodes, and the blast radius named**Select Trigger → Setup Conditions → Add Action, with the canvas showing exactly that: *Candidate — when a record is added*, a condition resolving to *53 Records*, then the actions. The record count is printed on the condition *and* in the action, so you know how many people this will touch before you press Create.

Why a stepper and a canvas

The stepper across the top is for building; the canvas below is for reading. Newer users follow the three steps in order. Experienced admins arriving at someone else's workflow ignore the stepper entirely and read the node graph. Rather than pick one metaphor, we let the same screen answer both questions.

07i

The candidate never sees Penknife Both sides

The most technically complex thing we built, and the one with the highest measured return. When a recruiter publishes a job in Penknife, it goes live on that hospital's white-labelled careers site. Applications route straight back into the ATS, tagged to the right job and the right client. No CSV, no re-entry, no external job-board account.

It required defining a multi-tenant publishing model with engineering before a single screen was drawn — which is also why the token system existed in the first place.

Fairview Hospital white-label careers portal powered by Penknife

Fairview Hospital — white-label careers portal (the frame auto-tours the full page)

Hospital brand, Penknife invisible Their logo, their colours, their domain

Candidates see Fairview Hospital throughout — careers page, listings, application forms. “Powered by Penknife” appears once, in the footer. Everything above it is a token swap, which is why a new client deployment took under two days rather than a redesign.

Healthcare filters, because of the data model Location, department, hiring type, work type, employment type

The left rail filters are driven by the structured fields set on the New Job form — not free text. Specialty and deployment-type filtering works on the public site only because somebody was forced to pick from a dropdown on the inside.

The job page is a candidate experience Full description, structured metadata, similar jobs

Apply Now pinned in a sticky right card with publish date, employment type, department, work type and hiring type beneath it. Similar Jobs at the bottom extends the session — a candidate who isn't right for this role is often right for the next one.

Inbound routing was the real feature An application becomes a record, instantly

Applying here creates the record in the ATS, tagged to the correct job and hospital client, screening answers attached, scoring queued. This eliminated the single largest source of manual data entry we measured across the whole platform.

White-label job detail page — candidate-facing view

White-label job detail — candidate-facing

07j

Insights — the module we got wrong first Both sides

Reporting shipped thin. At launch the dashboard gave aggregate counts — open jobs, applications per requisition, scheduled interviews — and clients wanted diagnostics: time-to-fill against a benchmark, where the funnel leaks, whether we're meeting the review SLA we contractually promised. That gap became the loudest post-launch request on the project, and we iterated it under pressure.

The screen below is where Insights landed. We're showing it because it's the honest end state, not because it was the launch design — it wasn't, and section 11 says so plainly.

Penknife Insights — time to fill, submission to offer, pipeline funnel and per-client SLA

Insights — pipeline velocity, conversion and client SLA adherence

Every number carries its comparison 18.4 days — and the benchmark it beat

Time to fill shows −3.2d vs target with a 21.6-day network benchmark underneath. Submission-to-offer shows 3.8:1 against a 5.2:1 industry standard. A metric without a reference point is a number an account manager can't defend in a room, so none ship alone.

The funnel names its own leak Conversion per stage, not just volume

Sourced 1,248 → Screened 38.9% → Clinical review 44.0% → Hospital interview 40.2% → Offer 37.2% → Placed 87.5%. Reading the percentages rather than the bars tells you the bottleneck is hospital-side interview scheduling — which is exactly the argument an account manager needs to make.

SLA per client, marked client-facing Corewell at 86% is amber, on purpose

Each hospital account shows active requisitions, average review time and SLA adherence, with the panel explicitly tagged Client-Facing. Designing a surface you know will be screen-shared into a client meeting changes what you're willing to round.

Bottleneck stated in words “Hospital hiring manager review (+4.1d)”

The per-requisition table ends in a Primary Bottleneck column written as a sentence, not a code. It's the one column nobody has to be trained to read, and it's the one that turns a report into a decision.

08 / Outside The Product

The record starts on somebody else's page

Every surface in section 07 assumes the person is already in Penknife. On a staffing desk, most of them aren't. Sourcing happens on LinkedIn, and on DiscoverOrg for the sales side — two tabs that belong to other companies.

What we watched was a recruiter with a profile open in one window and a Penknife form in another, retyping a name, a job title, a phone number and a city, then pasting the profile URL into a field literally called LinkedIn Id. Per person. During a hiring push, dozens of times a day.

The copy-paste is the visible cost. The expensive one is the duplicate. An ATS is only worth what its one-record-per-person promise is worth, and every hand-retyped profile is a chance to create a second Yash Janoria with a different phone number. Once there are two, the activity spine from section 06 splits across both — and neither half can be trusted to answer “when did we last talk to this person?”

So Penknife grew a second front end: a Chrome extension that puts the database on the page you're sourcing from. And we gave it the opposite priority from the one everyone asks for. It leads with recognition, not capture.

The extension's first job is not to add a person. It's to stop you adding one twice.

The design work here is the right-hand column. An extension that only knew how to add records would have been half the build and most of the damage.

08a

One line, on a page we don't own Sourcing

The extension's entire resting state is a bar across the top of the profile. It doesn't float over the photo, it doesn't open a panel by itself, and it doesn't ask to be dismissed. A recruiter reading a profile is doing the real work — the job is to sit next to that, not on top of it.

Resting state — the profile is untouched; the bar has already answered

The first word is a warning “Multiple Records Found In The Database”

Before Add is offered at all, the bar has told you the answer probably already exists. This is the single most consequential sentence in the extension, and it is the only thing on screen we contributed until the recruiter acts.

View sits left of Add Reading order is the safety mechanism

Two controls, in the order we want them considered. There's no confirm dialog on Add and no warning modal — the ordering does that work, every time, for free, on a surface where a modal would have been an intrusion onto someone else's page.

It's a state, not a trigger You never click to find out

The bar's text changes with what the lookup returned, so the duplicate check has already run by the time the recruiter has finished reading the headline. Making the check an action would have made it optional, and an optional duplicate check is not one.

08b

Three names that are nearly the same name Sourcing

This is the panel the whole extension exists for. Three records come back for one profile — John Doe, Johnny Doe, Joh Doen, all Senior Software Engineer. That isn't a contrived demo; it's what a recruiting database looks like after a few years of hand entry, and it's precisely the state we were trying to stop growing.

No algorithm was going to resolve it. But the one person who can is sitting right there with the source profile open — which is the argument for putting the panel here rather than in a data-hygiene screen somebody visits quarterly.

Phone number, on purpose +01 · +91 · +91

Each row shows name, title and phone. Name and title are the fields that collide; the phone number is the one that usually separates two similar records. It's in the list so the recruiter can decide without opening anything.

Openable, not selectable The arrow leaves for Penknife

Rows have no radio buttons and no Link action. Binding a profile to the wrong record, or merging two, is destructive and hard to unwind — we weren't going to let it happen from a bar on a page we don't control. The arrow takes you to the record, in the platform, where that decision has proper surroundings.

The escape hatch is a question “Not The Correct Match?”

It sits in the header, in the bar itself, phrased as the doubt the recruiter is already having. The one case where the extension is wrong is the case where a duplicate gets born — so it's the case that got the most visible affordance, not the most buried one.

Count in the title Matching records 03

Zero-padded, beside the heading. “Some records matched” asks you to scan; a number tells you immediately whether this is a quick confirmation or a judgement call.

Penknife extension matching-records panel — three near-duplicate candidates named John Doe, Johnny Doe and Joh Doen, each with title and phone number and an open-in-Penknife arrow

Matching records — three near-duplicates, and no way to merge them from here

08c

A profile is three different things Both sides

Once the recruiter has decided none of the matches are the person, Add becomes the answer — and its first question isn't a field, it's a classification: Candidates · Contact · Company.

One LinkedIn page has three legitimate readings. To a staffing recruiter, a clinician is a candidate. To an account manager, a hospital's director of nursing is a contact, and the hospital group is a company. Those are the five people from section 04 looking at the same URL and meaning different things. File it wrong and it lands in the wrong half of the object model, where nobody will look for it again — so the extension asks rather than infers, in one click, before any typing.

Add Candidate — the profile, already read, with one thing left to do

The form arrives finished Name, title, phone, city, state, country, LinkedIn Id

Every field the page can supply is filled before the drawer opens — including the profile URL into LinkedIn Id, which was the specific paste we watched recruiters do by hand. City, state and country come through as resolved selects rather than free text, so the record is filterable in the platform on day one.

One field left blank, deliberately Primary Email is empty

LinkedIn doesn't publish it. We could have guessed a first.last@company pattern and been right often enough to feel clever — but a plausible wrong email in an ATS gets used, by the broadcast tooling in section 07g. An empty field is the honest one.

The one thing the page can't give you “Click or drag to Upload”, last

A profile is not a CV. The résumé upload is the final control before Save, pinned with it, because it's the only part of this form that requires the recruiter to actually have something. Everything above it was free.

One primary, full width Save, and nothing competing with it

No Save and add another, no Save and open. In roughly 440px of drawer on a page we don't own, the platform's density argument doesn't apply — everything section 07 earns from a wide screen had to be re-earned here from sequence.

08d

Confirm, then get out of the way Both sides

The last screen is the one most likely to be designed badly, because it's the one where a product is tempted to celebrate. A recruiter in a sourcing run has twelve more tabs to get through.

Penknife extension confirmation — “Candidate Successfully added !” with a View in Penknife link, and the bar now reading Add Another Record — **“Candidate Successfully added !”**The confirmation is one sentence and one link. *View in Penknife* is underlined text, not a button — the extension doesn't take the tab you were working in. The record is filed; you keep sourcing.

Penknife extension confirmation for a contact — the same success component and View in Penknife link, proving one component serves all three object types — **Same component, different object**Contacts confirm identically to candidates. Three object types, one success state, one sentence to translate — the same instinct that kept eleven objects on one record anatomy in section 07e.

The banner also changes: once you've filed one record it reads “Add Another Record”, not the original match warning. The bar knows a sourcing run when it's in one.

Cost we took knowingly

A second runtime, a second release cycle, a third-party review queue

The extension is a separate codebase shipping on Google's timetable rather than ours, and it carries the declared data handling that comes with it — the store listing states plainly that it handles personally identifiable information and authentication data. We accepted all of that because the alternative was a form nobody would fill in.

Where it's publicly verifiable

Chrome Web Store · v2.0.13 · updated November 2024

Listed publicly under Workflow & Planning, published by 314e — see the listing. The captures above are the store's own screenshots and span two releases of the extension; the header colour changed between them, the flow didn't.

09 / Mobile

A deliberate, defended no

Penknife is a desktop tool. Recruiters work at desks, across wide screens, in long sessions, holding a lot of rows in view at once. Mobile was never going to be the primary experience, and we made that call early rather than discovering it at the end.

What we designed instead was a constrained surface for the people who genuinely need to act away from a desk — hospital hiring managers and account managers. View submitted candidates, leave feedback, approve or reject. Nothing else. The mobile experience is less capable by design, and that was the right call.

That surface shipped as its own Android app rather than a responsive squeeze of the recruiter workspace — Penknife is publicly listed on Google Play, free, published by 314e Corporation.

94%

of observed sessions belonged on a wide, information-dense desktop.

Average session · 40+ minutes

Mobile · approval surface

01View submitted candidates

02Leave feedback

03Approve or reject

Scope stops here by design

Research-backed scope

94% of sessions were desktop, averaging 40+ minutes

A responsive reflow of a data-dense recruiter workspace would have produced a worse desktop experience and still a mediocre mobile one. We chose to do one of them exceptionally well and said so out loud, with the analytics on the table.

Hiring manager use case

Three tasks, and nothing adjacent to them

Not a compressed recruiter UI — a purpose-built surface for the away-from-desk approval scenario. Every request to add “just one more thing” to it got measured against those three tasks, and most didn't survive.

10 / Decisions & Trade-offs

The calls we would still make

The useful part of a trade-off is not the polished rationale. It is the line we drew, what we knowingly gave up, and whether that cost still looks acceptable after launch.

Working page / 10Decision log — choice on the left, cost in the margin

01
Fork the product?One schema; permissions compose the front door.
Cost accepted: more entitlement edge cases.
02
How should white-labelling work?Semantic tokens, not client CSS overrides.
Cost accepted: slower first deployment.
03
Where should density win?Protect the desktop workspace; make mobile an approval surface.
Cost accepted: no full recruiter workflow on a phone.
04
What authority should AI have?Let the score narrow the pool; let the recruiter set the line.
Cost accepted: one extra action before seeing recommendations.
05
Where should a record begin?On the sourcing page — behind a duplicate check nobody can skip.
Cost accepted: a second codebase, on Google's release timetable.
06
Dedicated client parent?We folded client context into the existing framework.
Debt taken: the client-facing view has a structural ceiling.
07
Who did research represent?314e recruiters deeply; hiring managers mostly by proxy.
Blind spot: approval flows carried more inference than evidence.

A decision without its cost is just a slogan.

11 / What We'd Do Differently

The honest parts

This is a live product we're genuinely proud of. It also has real seams. These are the ones we'd change.

Where the seams appeared

Discovery Research lost cadence

Research access Hiring-manager blind spot

Architecture Two-sided model surfaced late

Delivery Reporting got squeezed

After launch Parent-profile ceiling

01

Discovery ran long and loose. We front-loaded research into an unstructured phase with no sprint cadence and no time-boxed synthesis. Good insight, poor momentum, and all the compression landed at the back end where it damaged the reporting work. We'd run discovery in short, tight cycles now, even at the cost of depth.
02

We designed the hiring-manager experience from inference. The client-facing portal and approval flows were built largely from secondary interviews and account-manager accounts. We should have escalated the access problem as a project risk in week two instead of designing around it and hoping.
03

We found the two-sided structure late. The staffing / internal-hiring split emerged from build conversations rather than from research, which meant retrofitting the dashboards and the permission model after the IA was settled. It worked — but it was luck that the object model turned out to be shared. Had it not been, we'd have shipped a fork.
04

Reporting was under-resourced relative to its strategic weight. It was the module clients asked about first and the one we designed last. Insights is good now; it got there through post-launch iteration under pressure, not through design investment during the build. That's the single biggest planning mistake on the project.
05

The parent-profile decision was the wrong call. Folding client context into the candidate view framework was pragmatic and shipped on time, but the integrated approach has a ceiling — there's a quality of client-facing experience it structurally cannot reach. Given the same constraints we'd fight harder to carve out the backend work.

12 / Outcomes

What we can actually defend

Penknife is live, but the commercial metrics belong to 314e and most are not public. So this is an evidence page rather than a victory lap: direct facts, observed signals, and the claims we are deliberately not making.

Project receipts / 12What survived contact with production

Direct factStill in production

The product launched in 2021 and continues to serve US healthcare recruiting workflows.

Confidence · confirmed

Architecture proofTwo operating models, one build

Staffing agencies and hospital talent teams run from the same object model and design system.

Confidence · visible in shipped permissions

Deployment proofUCLA theme configured in under 48 hours

The semantic token system turned a new white-label client into configuration rather than a fresh front-end project.

Confidence · delivery record

Observed signalAI scoring entered the sales story

Account managers began leading demos with recruiter-set thresholds and visible score freshness.

Confidence · team observation, not analytics

Distribution proofThe sourcing surface is publicly listed

Penknife ships as a Chrome extension on the Chrome Web Store — v2.0.13, last updated November 2024, published by 314e under Workflow & Planning.

Confidence · public store listing

Scope proofThe mobile call held as a separate app

The away-from-desk surface exists as its own Android app on Google Play rather than a responsive reflow of the recruiter workspace — section 09's argument, still standing in a store listing.