This audio­book turned out to be a great col­lec­tion of arti­cles on design. Each arti­cle has a spe­cif­ic pur­pose, is con­cise, and packs a big learn­ing punch. Some arti­cles are just ok, but most are outstanding.

Design think­ing means meet­ing cus­tomers desires, in a strate­gic, viable busi­ness method, that’s also tech­no­log­i­cal­ly pos­si­ble. Tim high­lights the impor­tance of being design think­ing shep­herds, guid­ing and grow­ing the abil­i­ties of non-designers.

He iden­ti­fies five key parts that make up a great design thinker’s per­son­al­i­ty profile:

1. Empa­thy: Imag­in­ing from mul­ti­ple per­spec­tives, great design­ers see the world in minute detail.

2. Inte­gra­tive Think­ing: Tak­ing an ana­lyt­i­cal approach, they have the abil­i­ty to see all the ele­ments, even con­tra­dic­to­ry ones. They take a con­found­ing prob­lem, and turn it into a nov­el solu­tion.

3. Opti­mism: No mat­ter the con­straints, great design­ers believe that there is always a way to improve on the sta­tus quo.

4. Exper­i­men­ta­tion: Great design­ers under­stand that a mas­sive changes does not come from small incre­men­tal fea­ture addi­tions. To make mas­sive change hap­pen, they pro­pose exper­i­ments to push new directions.

5. Col­lab­o­ra­tion: The lone genius design­er has become the inter­dis­ci­pli­nary design­er. They work col­lab­o­ra­tive­ly, and have sig­nif­i­cant expe­ri­ence in mul­ti­ple domains.

Idea: Tim looks back on the progress and devel­op­ments over the past few years. He iden­ti­fies that great design sat­is­fies both our func­tion­al needs, and our emo­tion­al desires. It’s not the first prod­uct that always wins. It’s the first prod­uct that does the job, and we love, that will be suc­cess­ful. Prod­ucts that are tru­ly mean­ing­ful, are the ones we should strive to create. 

Inno­va­tion is made up of three phas­es: inspi­ra­tion, ideation, and imple­men­ta­tion. Design think­ing should be lever­aged in each phase. Brown focus­es on how to improve inspi­ra­tion and ideation in this article.

What’s promis­ing? What holds things back? How might we lever­age con­straints as cre­ative spring­boards? What assets do we have that we can take advan­tage of?

This arti­cle is a tool­box of design process meth­ods, as well as high­light­ing the poten­tial pit­falls of design think­ing, and the ways to solve them. I real­ly enjoyed how Liedt­ka illus­trat­ed the entire design process, and showed how the out­put of one step becomes the input of the next step.

Inno­va­tion is only pos­si­ble when it: low­ers the cost and risk of change, has employ­ee buy-in, and offers supe­ri­or solu­tions to the ones that exist today.

1. Immer­sion: Exam­ine what makes for a mean­ing­ful cus­tomer jour­ney. Data can’t tell you what peo­ple aren’t able to artic­u­late. The best way to tru­ly under­stand the cus­tomer expe­ri­ence is to expe­ri­ence it by liv­ing it. After expe­ri­enc­ing, and gath­er­ing lots of infor­ma­tion, find a shared hall­way in your office, and post-up the insights, allow­ing passers by to take it in–the pho­tos, quotes, emo­tions. Key stake­hold­ers can high­light key infor­ma­tion, that will be used for future solu­tions. Next, clus­ter post-its and search for insights. These insights become a set of shared knowledge.

2. Align­ment: Ask “If any­thing were pos­si­ble, what jobs would be accom­plished through our expe­ri­ence?” Pri­or­i­tize by impor­tance first. This helps to reduce the ten­den­cy to pick less risky ideas first, and gives ideas a fight­ing chance against the sta­tus quo.

3. Emer­gence: Once you under­stand the cus­tomer needs, care­ful­ly plan who will par­tic­i­pate, what chal­lenge will be giv­en, and how the con­ver­sa­tion will be struc­tured. Use the insights from before to deter­mine design cri­te­ria. Use the design cri­te­ria to do indi­vid­ual brain­storm­ing, gath­er and share ideas, build on them cre­ative­ly by using “yes, and”. These par­tic­i­pants deep under­stand­ing of the user’s sit­u­a­tion will help them become cham­pi­ons in the long run. 

4. Artic­u­la­tion: Emer­gence gen­er­ates many some­what fea­si­ble, some­what attrac­tive ideas. Next we test those ideas against implic­it assump­tions. Ques­tion them: What would have to be true for this solu­tion to hap­pen? What are the assump­tions about why it would work? Fight the bias to pick the first solu­tion, or the over­ly opti­mistic solu­tion. The out­put of this step is a port­fo­lio of diverse, well thought through ideas, with their assump­tions vet­ted, and with the sup­port of com­mit­ted teams.

5. Test­ing: Car­ry out build­ing, and test­ing pro­to­types with users. The goal is to learn as fast as pos­si­ble, and to move for­ward. It is not a box-check­ing exer­cise, nor is it to fine tune, it may reveal nec­es­sary rad­i­cal change. Embrace it. The out­put of this process are learn­ings you can use to do more test­ing, and when you have suf­fi­cient con­fi­dence, use the pro­to­type to inform the final refined solution.

6. Build the refined solu­tion: Work with the team to shep­herd learn­ings, and insights, using expe­ri­ence and knowl­edge to deter­mine a way for­ward in dif­fi­cult decisions.

Idea: In order for design think­ing to be adopt­ed, it must have the right stewardship.

Bason and Austin set out to find solu­tions to the fol­low­ing design problems:

1. Feed­back received from cus­tomers is some­times over­ly emo­tive.
2. Diver­gent think­ing can feel like spin­ning wheels, and wast­ing time.
3. Iter­a­tion can be uncomfortable.

Team­mates need guid­ance to nav­i­gate the process, to ensure that it goes smooth­ly. They iden­ti­fy three ways to over­come these chal­lenges: Lever­ag­ing empa­thy, encour­ag­ing diver­gence and nav­i­gat­ing ambi­gu­i­ty, and rehears­ing new features.

Lever­ag­ing empa­thy is all about under­stand­ing the real­i­ty of using your prod­ucts and turn­ing that infor­ma­tion into a pos­i­tive force for change. By pos­i­tive force for change, they mean some­thing con­struc­tive, and for­ward look­ing. Start by gath­er­ing a wealth of data, and fram­ing insights in a way that directs focus towards the goal. Set aside pre-con­cep­tions about the prod­uct and strive to approach with a begin­ner’s mind. If the prob­lem feels too big and over­whelm­ing, think in steps that move in the right direc­tion. These activ­i­ties help to build a vis­cer­al under­stand­ing, and can be a pow­er­ful reminder lat­er in the project, if we for­get why we are doing something.

How doe we as design­ers explain a method­ol­o­gy for a process we do not ful­ly under­stand? We can do this by lead­ing by exam­ple, jump­ing fear­less­ly into the unknown. When faced with ambi­gu­i­ty, we are stretch­ing to find solu­tions, it’s not a lack of direc­tion. Know­ing where we want to get to is clear, but how we get there is up for us to fig­ure out.

Instead of try­ing to con­trol ideation, embrace pos­i­tive chaos. Always gen­er­ate at least sev­en dif­fer­ent approach­es, to get beyond the ear­ly options. To be tru­ly inno­v­a­tive, gen­er­ate extreme ideas, and use them to learn and gen­er­ate new ideas. 

Cre­ate tan­gi­ble design pro­to­types to help address skep­ti­cism. “Failed” pro­to­types are a valu­able step in the process. It’s impor­tant to spell out what you aim to achieve, and for who. User feed­back leads to ideas that we would­n’t have dis­cov­ered oth­er­wise, and is an absolute­ly cru­cial step.

We can­not com­mis­sion design think­ing and walk away. We must help team mem­bers to under­stand the real­i­ties of work­ing in ambi­gu­i­ty, and high­light why this is a con­struc­tive, pos­i­tive part of the process.

Idea: In order to inno­vate, you’ll have to go up against stiff resis­tance. By treat­ing this resis­tance to inno­va­tion as a design chal­lenge, you can be more successful.

With com­plex arti­facts, the design of their inter­ven­tion, intro­duc­tion, and inte­gra­tion into the sta­tus quo is more cru­cial to suc­cess than the arti­facts them­selves. In this arti­cle Brown focus­es on the inter­ven­tion stage.

A way around this is the hybrid approach, tak­ing the sta­tus quo, and merg­ing it with the new change. Although often eas­i­ly accept­ed insti­tu­tion­al­ly, this often does not mesh with a design­ers goal: to cre­ate the best pos­si­ble solution.

1. This does­n’t address the prob­lems I believe are crit­i­cal.
2. These aren’t the pos­si­bil­i­ties I would have con­sid­ered.
3. These aren’t the things I would have stud­ied.
4. This isn’t an answer that’s com­pelling to me.

With all of these poten­tial prob­lems, win­ning com­mit­ment tends to be the excep­tion to the rule.

1. Go ear­ly and say, we think this is the prob­lem we need to solve, to what extent does that match your view?

2. Iter­ate and go back and say, here are the pos­si­bil­i­ties we want to explore, based on what we agreed on (in step 1), to what extent are they pos­si­bil­i­ties you imag­ine? Are we miss­ing some? Are any of these non-starters?

3. Iter­ate and go back and say, we plan to do the fol­low­ing analy­ses on those agreed upon explo­rations, to what extent are these analy­ses that you’d want done? Are we miss­ing any?

4. Intro­duce the strat­e­gy: At this point when you present the strat­e­gy, it is almost a for­mal­i­ty, and stake­hold­ers aren’t shocked or sur­prised by some­thing out of left field.

When launch­ing a com­plex prod­uct, inten­tion­al­ly keep com­plex­i­ty down in the first release. The first step of a prod­uct launch is user accep­tance. They need to learn a com­plete­ly new sys­tem. The sec­ond step is expan­sion. Once the users under­stand the core expe­ri­ence, you can add new fea­tures that intro­duce com­plex­i­ty. Design prod­ucts so that they can evolve.

1. Prime stake­hold­ers by estab­lish­ing an anchor for the future change.

2. Cre­ate a new mod­el, based on knowl­edge experts, and an under­stand­ing of user needs.

3. Learn about the hur­dles to launch, and cre­ate a pilot project to test the waters. Test assump­tions, and tweak based on pilot user insights.

4. After the suc­cess of the pilot, oth­er groups will want to par­tic­i­pate. Expand and launch the next stage. Repeat all over again.

Inter­ven­tion is many small steps, not one big one. Don’t wor­ry about get­ting things per­fect­ed before com­mu­ni­cat­ing with users or stake­hold­ers. Com­mu­ni­ca­tion is the way forward.

Intu­it real­ized that on their Net Pro­mot­er Score (NPS), they had improved their detrac­tor score, but could­n’t increase the top end. Peo­ple using the prod­uct weren’t pas­sion­ate about it. Mar­ket­ing got peo­ple in the door, but prod­uct qual­i­ty was what they stuck around for.

Intu­it adopt­ed a phi­los­o­phy of “design for delight”. They intro­duced inno­va­tion cat­a­lysts: peo­ple with broad per­spec­tives on design, knew what great design looked like, who were col­lab­o­ra­tive, out­go­ing, and influ­en­tial. They embed­ded these inno­va­tion cat­a­lysts with­in teams, to encour­age teams to con­sid­er the cus­tomer per­spec­tive, and embrace design thinking.

They shift­ed away from pre­sen­ta­tions, and toward cus­tomer insight, and experiements.

They intro­duced a new four week cycle cen­tred around three activities:

1. Painstorm: What are the biggest pain points for cus­tomers? Is this a prob­lem that we could solve?

2. Soul Jam: In one week, gen­er­ate as many ideas as pos­si­ble, nar­row­ing down to one, and build a prototype.

3. Code Jam: In two weeks, write code that’s good enough to test out ideas. 

Today’s tech-cen­tric com­pa­nies have more data than ever, and yet prod­ucts con­tin­ue to fail. It seems as though we’ve mas­tered inno­va­tion, and yet we haven’t. Why is that?

Most data cre­ates cor­re­la­tion: Most man­agers make deci­sions based on cor­re­la­tion. The data how­ev­er is often relat­ed to the actu­al cause. Instead of focus­ing on cor­re­la­tion, focus on the spe­cif­ic jobs your users need to accomplish.

If a prod­uct does a bad “job” of the task we hired it to do, we won’t use it again, for the task we want to accom­plish, we’ll find anoth­er one. Jobs to be done the­o­ry helps you iden­ti­fy the causal dri­vers for prod­uct use, and enables you to build the right prod­uct.

You are in the busi­ness of “the job” your users set out to accom­plish. Your goal is to meet that job, not to cre­ate a tech­ni­cal arti­fact (the soft­ware). Suc­cess­ful inno­va­tors solve prob­lems, while address­ing user anx­i­eties, and the iner­tia that holds users back. Jobs aren’t just func­tion, they have social, emo­tion­al attrib­ut­es that mat­ter. Jobs are com­plex, mul­ti-faceted, and require a pre­cise definition.

1. Job is short­hand for what an indi­vid­ual seeks to accom­plish in a spe­cif­ic circumstance.

2. It usu­al­ly involves more than just a task, it’s an experience.

3. Cir­cum­stances the user faces is more impor­tant than the user char­ac­ter­is­tics and trends.

4. Good inno­va­tions solve prob­lems that had inad­e­quate, or no pre­vi­ous solution.