What is it are we doing when we do design? How can we teach it (or, how can we learn it)? What can we learn from product and service designers at FAANGs — who may have more luxury to write than many of our peers — that we can apply to the majority of design work, which is smaller in scale and scope?

Scale is the main difference, right? Scale of project, scale of team, scale of resources …. Can we assume the underlying principles of product and service design are the same regardless of scale?

Modeling product and service design for degrees of scope require we try to distill the common vapors from the work involved, which is the aspiration of this blog. The day-to-day practice of product design specifically is wildly varied when we’re thinking about the tasks performed across companies and projects, so much so that the common thread between products of any size can seem all but invisible.

But we can make an inroad through the lens of Jobs-to-be-done, which describes the desired end-result to the specific task performed.

That is: product design at any extreme can be understood through a handful of jobs I’m calling Trades and their Crafts, a series of short posts I am writing to help me firm-up some of my thinking about how to we should design solutions for different magnitudes.

To start, let’s talk about Job Fractals.

Job fractals

A job-to-be-done is a user’s overarching goal, in the pursuit of which they rely on a service you provide. For instance, when a student approaches the reference desk (the product) at their university’s library, in search of some knowledge provided by the librarian (the service), the immediate job-to-be-done is to achieve a passing grade for their assignment. The service here is but a stepping-stone on a larger journey.

But jobs are fractal. A job contains jobs, and is itself a part of a larger Job. It’s turtles all the way down. The student’s job to achieve a passing grade is but a part of an overarching job to pass their class, itself one of many jobs-to-be-done involved in their job to start a career.

When you realize that a job is fractal you can begin to understand how the end-user experience resulting from the clicking of a button ripples upward through the seemingly disparate end-user experience of, say, receiving a push notification.

The job-to-be-done for a person at every step of their journey is a sliver of their job-to-be-done for pursuing the journey in the first place, which itself is a sliver of another. The closer you zoom in to a user’s job-to-be-done, the more jobs-to-be-done you discover.

Awareness of and willingness to try to suss-out the job-behind-the-job is the fundamental concept of service design, and is core to the understanding of your and your user’s place in a larger ecosystem of products and services.

What changes about the librarian’s service if it is designed understanding that their role enabling a student to pass their assignment impacts the greater job involved: to start a successful career?

Talking about the job that’s way up here — imagine me gesturing while I write this — and the Job that’s way down there gets pretty loopy. How many times have I written “job” up to this point? Lots, huh?

So I thought I’d make-up a vocabulary - starting with job fractals, which illustrate the need for better words with which to talk about this stuff.

Job fractals: jobs-to-be-done contain jobs that contain jobs that contain jobs.

It’s all turtles.

Consider liking (❤) this issue of Metric if this made you think. Help produce this work for $5 per month or $30 per year.

Metric by Michael Schofield

Job Fractals