The Design of Job Descriptions

A bottom-up, alignment-oriented approach

Read this article in its original place.

Role ambiguity sucks. It leads to disappointed employees, wasted time, failed interviewing processes. If people don’t know exactly what their role is, they can’t perform. If managers don’t define clearly the roles of their employees, they can’t assess their performance. And a lot of that frustration comes, in my experience, from sucky job descriptions.

You probably think job descriptions are terribly boring. I won’t judge you. Most of the time they’re boilerplate text; when writing new ones, hiring managers tend to just copy the last one they used, tweak it a little bit, and publish. If you write them this way, then they’re certainly boring.

I see things differently though: if you design your JDs — instead of writing them — you can turn lifeless documents into an alignment-producing, consensus-driving, ever-evolving communication tool. It leads to effective interviewing, and ultimately to role clarity. I can also find them pretty exciting, but please don’t judge me.

Here I propose that if you approach them as a design project (define the problem, understand your users, generate low-fidelity solutions, iterate), you’ll end up with results which will leave you as excited about them as me.

Keep in mind this approach is most useful for new positions — when you’re hiring the first 2 or 3 people with a certain title (for example, your first few engineers) or creating a completely new role within the company (think hiring the first designer, marketer, salesperson, HR lead, etc).

By the time you’re hiring your 19th designer or your 57th engineer, you should have a job description which is extensible to dozens of roles and a systematized interview process. In other words, I can’t imagine this approach being too useful for a big company.


JDs define what you’re looking for — and very importantly, what you’re not looking for. They take the infinite pool of possible candidates and draw a line around what’s acceptable, and leaving what isn’t outside. A great job description is one with a sharp boundary, removing the blurriness which leads to ambiguity.


So instead of writing an ad (aspirational, non-specific, over-inclusive), approach the problem as if you were writing product specifications (straightforward, actionable, uncompromising).


When interviewing candidates you’re looking at several other aspects, and you should reflect them in your job description. I approach this by breaking these characteristics into three categories: responsibilities, profile and skills/experience.

Responsibilities: what the hire will do.
Clear, concrete, objective tasks the candidate will execute day-to-day, or be responsible for supervising. This is where you come to full agreement about how far the role extends and define the main criteria upon which performance will be evaluated later on. While this list must encompass the primary technical needs of the job, it should also include secondary but important responsibilities – or even aspirational goals.

Examples: collaborate on product strategy; execute on visual design; maintain database infrastructure; educate salespeople on product features; manage customer acquisition for the product; develop the department’s hiring brand; publish articles in industry publications.

Profile: what are they like.
Objective descriptions of subjective individual characteristics. This is where you draw the line about the temperament, values, social skills and priorities your candidate will need to excel on the job. I see these often taking the shape of an adjective followed by an explanation.

Examples: pragmatic, visionary, flexible, disciplined, charismatic, driven, communicative, results-focused, team-oriented, humble, inspiring, flexible.

What’s really important here is not to just dump a bunch of adjectives into a list. The adjectives in the examples above are all positive, but it’s unlikely that someone would be both pragmatic and visionary at the same time, or that you’d be able to find someone who equally humble and inspiring. Use this opportunity to figure our exactly who you need on your team.

Skills/Experience: what they must have done before.
Justifiable skills which are needed for the job, and/or the experience to prove them. This is the kind of thing you’ll evaluate in resumes and exercises. Be thoughtful about what you actually need here and of true ways of assessing it.

Examples: ability to present in front of large audiences, complete fluency in Ruby on Rails, basic HTML/CSS prototyping knowledge, SPHR certification, good written communication skills, excellent analytical skills.

Ideate (Low-Fidelity)

As the facilitator, make sure to introduce controversial points and encourage discussion, so you can achieve the clear boundary lines of the role we discussed above. In this process, sticky notes and whiteboards are definitely your friends.

The output of this phase should be a series of unpolished bullet points, grouped into the three categories. Worry about meaning, not polish, and make sure you have clear agreement/understanding among stakeholders.

Refine (High-Fidelity)

  • Company intro. “Who are these people?”
  • Role intro. “Why are they hiring for this position? Is this roughly something I’d want to do? Who would I report to?”
  • Responsibilities. “What would I do day-to-day exactly?”
  • Profile. “Are they looking for someone like me?”
  • Skills/Experience. “Would I meet their requirements?”
  • Extra role info. “What are the benefits? Any perks?”

But please go beyond descriptive copy. While you should absolutely be clear and concise, this is a great opportunity to express your hiring brand.

I actually believe it’s a good idea for different departments or different hiring managers to use slightly different tones in their job posts. Some teams are more serious, other more on the funny side, some are competitive, other very collaborative, and that should be reflected here.


Once you start interviewing candidates, you’ll most likely notice details about the job which you didn’t anticipate earlier in that process. You might notice for example that all candidates ask about the full range of responsibilities; or that perhaps it’s unclear to whom they’d report.

This is user feedback! Use these opportunities to come back to the document you’ve prepared and update it with answers to those questions. Share it with the team, clarify the role further, update the job post. It will only make interviewing later down the line and help screen bad fits early on.


If you want to see a couple examples of the final product of this exercise, check out this and this JDs. They were very successful in hiring for these positions (aka we’re not hiring anymore!)

You should consider following me on Twitter.

Writing about time, fatherhood, leadership and the making of software. VP Product and Design at Metabase.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store