How often, when you begin an assignment, do you have a clear understanding of what outcomes are desired by your client? An outcome is different than a deliverable. An outcome is the impact, benefit or change that is desired. A deliverable is a product of work.
In this video, Dean Kamen, talks about his work on an amazing prosthetic device designed for injured soliders.
What struck me was that when DARPA shows up at his door they ask for three specific outcomes:
1) The solider must be able to pick up a grape without crushing it.
2) The soldier must be able to pick up a raison without dropping it.
3) The soldier must be able to do this in 2 years.
There were no requirements for a specific technology, materials, process or staffing. There were some requirements for success (i,e, self contained, fit a 50th percentile female frame etc.) But these three outcomes shape the deliverables.
All too often we focus on deliverables rather than outcomes when we design. Clients are quick to specifically request what they want delivered rather than the outcomes they need. We need to setup clear outcomes up front and then let the design process define the deliverables.
written by Jon Lax
WOW…I’m absolutely stunned, what a guy!
This really puts a perspective on everything for me, what an inspiration…
I have to say I’m really moved by this guy and his thinking, it will be with me for the rest of my days.
Well done Jon for posting this, thank you!
Technology comes from Humanity.
It’s the most touching speech I’ve ever watched on TED. When there is true compassion for people(client), there will come the great product(outcomes).
: )
This notion of working towards outcomes over deliverables is pretty common in the software world. The bullets referenced are ostensibly “user stories” in Agile terminology. “As a soldier, I want to pick up a grape without crushing it.”
This approach is very successful in software because it puts the user first, and recognizes that there are practically infinite technological approaches to nearly any problem, which makes the selection of any specific approach fairly inconsequential to the end user.
It also ensures that you do what needs to be done, and nothing more. If the user can do what they what they’ve asked to be able to do, you’re done; step away. Outcomes should determine deliverables, and not the other way around.
this guy’s demeanor and delivery here is captivating. he comes off as humble and extraordinarily passionate.
the tech of course is stunning.
excellent post.
I agree with this, this is definitely what design should strive for. The user needs this seemingly more than the client in some cases..
The key is having your clients’ trust while defining their deliverables from outcomes, while staying within budget and timeline. It’s sometimes quite an illusive dynamic to strive for.
When a client trusts you to take moderate steps and propose deliverables at each presentation, they may also begin to loose trust or feel that you are loosing focus of their needs in regards to budget and timeline if deliverables meander too much from their almost unconscious expectations of deliverables.
A lot of people working outside the design industry do have unspoken expectations for design deliverables and may not even know it fully themselves. They may assume something within their outcomes that may ultimately not be delivered according to a thorough design process and the proven needs of their users.
The carte blanche of trust with your clients is when they want to pay for you to define their outcomes, then deliverables etc. otherwise it could be a trick to balance budget and trust with thorough and honest design.
Dean Kamen’s work is great, but there is something disingenious or scripted about him. He knows the technologies he can use, great, but in presentation, why does he contrast between emotional and personal sentiments to peak interest and delve directly into technical terminology? It’s slightly annoying, though he is doing something great for humanity.