Every Design Has a Job

What is the difference between a design which works, and one which doesn’t? Strictly speaking, in the world of functional design, we ought to be asking: does this design do the job it was intended to do?

A focus on outcomes tends to come naturally in the world of B2B software and systems development, even if those outcomes are more often internally-defined. But, as important as they are, we’re talking about something other than business or functional requirements here.

When we undertake the effort to put form to an idea, especially in software, a large part of our concern should be to look outward: what is the effect that using the software has on the real world?

Can a person accomplish a specific task using the software we’ve created? That is an important question, but only the first.  We should ask something broader: does the design enable a person to experience or achieve what they desire in the outside world?

For example, a content management system might enable authors to publish product information quickly and easily, saving them time and making it possible to get updated information into the hands of customers who need it, sooner. Worthy goals, to be sure, but what are the second and third order effects of that outcome?

Do customers actually see that information more quickly? Do they act on it more readily? Do they buy more, or buy sooner, as a result? For certain, the authoring environment in a CMS is but one piece in a complex system of cause and effect. How that information renders for the customer is another. But both are contributing to accomplishing the same job.

Identifying these jobs using the Jobs to Be Done framework, created by Clayton Christiansen in the 1990s and operationalizes by Tony Ulwick, is a key step in deciding the criteria by which a design can be judged. Importantly, these Jobs are defined specifically with external real-world outcomes in mind. Whereas functional requirements or User Stories may define an outcome in systems terms, allowing for immediate validations of a design’s capabilities, a Job to Be Done requires measurement of the outside world. That can often feel less exact, and messier.

But that shouldn’t dissuade us from asking: does this design help people accomplish what they need to accomplish? Few people use software for its own sake; they use it to enable or improve or alter what they experience in the real world.

Every Design has a Job, the question is: does the Design Do Its Job Well?