UNPACKING: “How it Works: IBM Design Thinking”
Updated: Jan 8
Peer Review Series: Review #1 of 10:
Racking up more than 500,000 views on YouTube this video document was chosen as the first in our ten part experimental review series due to its high public visibility and its emphasis on methodology being depicted as “Design Thinking”. [To view the video document yourself go here.] Is this document adding to the clarity or the confusion around this subject? Lets take a look.
When one critiques a design process it is sometimes useful to consider the underlying metaphor(s) being invoked, In the video the early stage of the process begins by depicting a collection of things that mostly do not make it to the next step. A candidate metaphor to consider here is Darwin’s Natural Selection.Generate variety then only the fittest survive. However in contrast to the actual environment acting as the objective function a group judgment regarding “wow-ness” is substituted. Usually objective functions involve more than one parameter.
Perhaps “wow” could be an aesthetic judgment that implicitly combines many factors. Yet it still substitutes judgment for survival. It mixes metaphors – a proposed mechanism of biological evolution with a buzzword made popular in business and marketing. Is there a theory of evolution of ideas through “wow” assessment? Is it backed up by any evidence? Perhaps there is and the implication is that IBM has it. I am sure they have experience with it.
To be fair generating variety then selecting from it is common to many proposed processes, Brainstormingand Nominal Group Technique as examples. Is there something special about the use of a similar process here? After all, although little is said about it in the video, it is ostensibly the source of all the “wow”. Has IBM discovered and proven a Nominal Group Wow Technique?
Employing analogy and mixing metaphors can be a very powerful design technique. When applied to processes, such as design processes themselves there is another metaphor being invoked – it is a machine metaphor which implies efficiency and power. Ie. “use this process and you will make a new product faster, with fewer people, and less cost.”
Now what about mixing the machine efficiency metaphor with the evolution metaphor which is what is being done in the early stage of the proposed process? Is there something about the mechanism of Natural Selection which is inherently efficient? In nature it does not seem to be efficient at all. It takes millions of years, lots of dead ends, tremendous inefficiency in terms of lives. One could argue that Natural Selectionis efficient in terms of the total search space.
Yet, the Natural Selection / evolution metaphor is to a large extent characterized by incrementalism whereas “wow” generally connotes disruptive innovation.
This raises a new question: Is the intentional juxtaposition of metaphors with conflicting implications more creative? More efficient? More incremental? More disruptive? How does one know?
On the question of whether this video is adding to the clarity or the confusion around the subject of Design Thinking I would say….To the extent that this model represents actual instances, that is real projects, it is very valuable. A record of the specific ways the model was followed with all its variations would be even more valuable. There is of course the postmodern school of thought which disavows the value of meta narratives ie. models, and would only ascribe value to the instances. It would be most useful for someone to embed in these processes and carry out an Actor Network Theory analysis to track what is really going on and how well each instance does.
A major reason a focus on case studies is warranted is that proposed process components which sound good may not work the way you one expects. Let me share two examples.
In this video there is a step in which after a change is made everyone on the team is informed. This sounds very egalitarian and democratic and seems to promote communication which is ostensibly a good thing. But consider this. In the 1980’s there was a push to involve everyone in each step of the product development process as a means of improvement. It was called Concurrent Engineering. But in many cases it really slowed things down, it made things worse. Until some studies were done and found that there is an important distinction in what information is being discussed and shared at each step.
If you got everyone’ perspective regarding each step in the engineering process it generally avoided downstream problems but you often had to trade off a bit of a slower start. In contrast if you considered each step all at once this led to a communication overload and slower overall process. There is not enough information in this video to indicate how the avoid this problem while espousing the same thing the early progenitors of Concurrent Engineering. So establishing an empirical basis for processing claims would be very useful. Otherwise it is difficult to discern what actually works versus what sounds politically correct or just attractive from a marketing perspective, or just en vogue style-wise.
A second example, again from the start of the video concerns the generation of “wow”. The more predominant term in the literature which reports on studies of how effectively and efficiently “wow” can be generated is Creativity (that is at least one strongly related phenomena.) This field of study is at least eighty years old. Yet, I have met many people involved with and/or responsible for processes to generate new ideas that seem to be ignorant about the last seventy years of findings of those studies.
If they were that out of touch with the journals of their profession they would clearly be considered to be at risk for malpractice. For some reason when it comes to Design Processes a lack of scholarship is considered to be okay, it is rarely even questioned. But what of the portrayal of this most critical step, the generation and selection of “wow” in the video, does it add to clarity or confusion?
In the 1950’ perhaps the most famous component of Design Processes was developed – Brainstorming. The name entered the popular lexicon. Everyone thinks they know what it means but most people I’ve met that invoke it neither know the steps, nor the rules. They especially do not know that the process was discredited within the decade of it’s promotion and these studies are published in the peer reviewed literature.
In the 1970’s the Nominal Group Technique was developed and was demonstrated to reliably outperform Brainstorming. A key reason is that it was found people generate more creative contributions if they are given the space and quiet to respond to a Triggering Question first as individuals. They first behave as an aggregate of individuals in the context of sitting together, that is why the word “Nominal” is in the name. In this group process people start as ‘not really’ a group and based on research and evidence this is found to be more effective. This finding was counterintuitive. It does not sound even politically correct. But the results are there in the peer-reviewed literature for a variety of different fields of study.
Over the decades other creativity processes have been developed and promoted, few have been properly researched or subjected themselves to the peer-review process. Even Brainstorming is attempting to make a comeback although with a different process.
One might say that Brainstorming never went away. What did go away was the legitimacy of the specific process being recommended. What also went away, at least for a good long while, was the credibility of the approach to its early promotion and what a number of researchers came to believe were unsubstantiated claims.
What remains then of Brainstorming? The brand. There is perhaps no more popular brand of group process. Yet already by the 1960’s it was tested by a number of researchers and found wanting.
So if one invokes a process to generate a variety of ideas with “wow” potential at the start of the macro-process does it clarify or confuse? Let us consider someone trying to follow this video as a recommendation of how to proceed themselves. One should pick a specific process. If one is not knowledgeable about design processes I think people would tend to rely on the most popular brands of processes which as is the case with the 1950’s Brainstorming is perhaps not the most effective or efficient.
More likely they don’t follow any process at all or improvise. So in this sense I think this small segment of the video, by leaving the specific, named process unspecified, actually adds to confusion.
But we should consider this branding effect for the video as a whole. The whole thing has the IBM brand on it. Furthermore it invokes branding of some processes such as Agile.
Having the IBM brand on this is greatly simplifying for the person/organization trying to follow it as a recommendation or considering hiring IBM. The strength of the brand adds clarity. In contrast to the idea generation piece discussed above the macro-process will probably never be researched as well as idea generation methods. For one the overall process is months instead of minutes.
Secondly it is unlikely that a company will pay to do the same project in parallel by alternative processes in order to compare them (although this has been done$. Third it takes tens to hundreds of examples to develop statistically reliable assessments.
So at the macro-process level this video is clarifying – because it has the IBM brand, we transfer the basis of legitimacy from process research to reputation. One tends to trust that IBM has done their homework and the person following the recommended approach does not have to worry (as long as someone helps them with the details of implementation). Or someone just hires IBM.
As an ex-IBMer, I am very familiar with ‘IBM Design Thinking’ and it’s unfortunate the video only focuses on the most elemental aspects of it. I know that ‘IBM Design Thinking’, as a tool for shifting perspective across the organization, was (is) very successful BUT I also know it has struggled to bring together the notion of Design Thinking and Agile.
Just to give a bit of inside context. The video has been made for the THINK series. The THINK series is an educational/Point of View program created by IBM a few years ago for outside clients but it has been extended to internal teams as part of a self-learning program and as a way to evangelize Design Thinkingacross the organization.
I find it interesting that companies, and IBM is no different, want ‘artisanal’; i.e. unique, solutions (thus using something like Design Thinking) yet they use manufacturing processes designed for mass consumption (LEAN, Agile, Scrum, etc.) Having said that, the narrative focuses on how they are using these two methods, Design Thinking and Agile, for the improved development of software solutions even though the title of the video is “Restlessly Reinvent”.
Although they define Design Thinking as a method for problem solving, the way they are approaching it is limited to artifact creation. There is no upstream/top-of-the-funnel conversation; it is assumed from the beginning that the business problem is about a product/service experience narrowing the benefits of Design Thinking to just making things rather than elevating it as a way of thinking/being which is where the most value lies.
Democratizing the design process doesn’t mean taking the complexity out of it. The design process provides the guardrails for managing complexity but, sadly, when used for making artifacts only, it diminishes its value and its impact.
I know for a fact IBM’s attempt at customizing Design Thinking is by adding HILLS (their term for challenges), SPONSOR USERS (their way to have access to feedback) and PLAYBACKS (their version of transparency). Since the design process is universal and already transparent, collaborative and you do have to have a problem to solve, the concept of ‘customization’ seems rather odd and out of place. It comes across as a way to disguise the need for the company to be operationally and foundationally ready so they embed the organizational checkpoints in the Design Thinking process…messy.
They seem to ‘fuse’ outcomes and ideas as one thing and the criteria they use to discard/accept ideas is based on what they call “WOW factor.” I personally don’t know what they mean by “WOW factor” but I question how such a term can even be an acceptable criteria in any business setting. The success and/or failure of an idea needs to be based on measurable criteria not on subjective opinions.
On the question of whether this video is adding to the clarity or the confusion around the subject of DesignThinking I would say I am not quite sure it is doing either. From my perspective, the purpose of the video seems to be to show the application of Design Thinking for a specific purpose, as understood and applied at IBM. For the uninformed, the video may come across as a practical application of Design Thinking and it may even help them to become curious about it. Some may find it helpful in gaining a better understanding of it. The informed may consider it over simplistic, without a solid foundation on design and as just a sales tool.
Let me start by problematizing the basic assumptions of IBM Design Thinking process. The video presents a fictitious fast-growing but basic retail garden store as the putative subject client for the IBM process. This imaginary case is used to demonstrate the full lifecycle of the basic four-stage design process as Design Thinking application. The stages are presented as if they are necessary, pragmatic and almost scientific methods adapted to a simple business issue, that of managing an online sales presence.
However, I’m not at all convinced of the pseudo-service design application and its value. There’s nothing inherently wrong with the four-stage design model, except that it suggests that these stages are themselves the answer to the most vexing aspects of the business problem. They most definitely are not. These are all IBM asserts to a problem that IBM decided was at issue.
As a product/service designer since the late 80’s, I see an array of basic rookie errors promulgated by this latest management fad. In the Green Genes scenario, the false issue of “internet sales” is raised and then “solved” by basic UX research and (we think maybe) website design. But the really easy parts are highlighted, and the hard parts, the real business issues of concern, are overlooked. This is a process sales pitch, and not an exploration of the value of Design Thinking.
To be very specific – how do we know (or why would we even believe) that the garden shop needs to sell plants online? Do you typically buy plants online? Is this feature sustainable from a business marketing and back office perspective? Does the business intend to develop internet-based personalized marketing with its customer bases? What’s the integrated value proposition here?
As an actual UX and field-level researcher for much of my design career, I just found the business case and business model associated with the case unconvincing. The notion that a fast growing, but basic retail shop, even needs much of a website is not established. The attention given to a precious few “key customers” as a kind of super-user group – a basic marketing method, not a Design Thinking method – does not seem that useful in the case context. There was no indication of a survey or rigorous population sampling of the “user base” or the retail customer.
The real value of Design Thinking would be in the FRAMING of the issue in the first place. Design Thinking would help the company determine the best strategy and then to consider the fit of the online presence and an integrated service value proposition. I would want to address the following questions:
What is unique about your business that is increasing growth at the physical stores?“
Why do you need to invest in anything more than a basic website?“
What do your customers really want, what are their preferred actions in interacting with the company?“
Are we assuming that the company is losing business because there is not sufficient content on the site?
How would we know this?”
There is no basic framing or fact-finding, or problem finding and idea evaluation being done at the level of the service itself. The assumption is made that a website will manage an assumed online base of “users” (which they label their customers as in another telling rookie error). There is absolutely no business case, business model, competitive analysis or customer behavior profiles indicated to drive the strategy toward this process.
The multi-disciplinary, IDEO-like team for a 20-40 employee garden shop is drawn into a time-consuming and expensive IBM-style market research process, which is glamourized as “Design Thinking”. Oh, and then Agile processes will magically build the site. But the time and cost, and release and test problems are not even discussed here. The real messy issues of implementation are totally glossed over. In any business process such as a major e-commerce site, the implementation is 90% of the time and cost. The up-front design, while critical of course, is a relatively smooth compared to actually building and testing a service-integrated website within budget for a small company.
Selling corporate empathy as a design solution is misleading, underconceived, and counter-strategic, as the real business issues in the case are not encountered in this process. If this is what IBM is selling in their Design Thinking program, my business has nothing to worry about. Redesign got its brand position in the early 2000’s by fixing the problems incurred by major digital design firms such as Razorfish, March 1st, Organic, Giant/Viant/Scient and the others. Perhaps I can retire on fixing the IBM clients’ digital properties so they are fulfilling their business needs with appropriate value propositions and improved business models. Because IBM Design Thinking isn’t going to do it.
With respect to the contribution of the video to the understanding of Design Thinking, I believe it is a very partial presentation. A standard product development methodology is repackaged as Design Thinking, when the real functions skills of Design Thinking are not surfaced in the pitch video. The value of the client organization learning Design Thinking for itself is not even addressed – instead the process of “digital development for a small business” is framed as if it were the creative work of a design team.
I have become accustomed to compartmentalising this type of sales pitch, so thanks for inviting me to unpack this further.
Sales Pitch & Customization of Design Thinking Process: First and foremost, I see this as a pitch that seeks to differentiate via a ‘customized’ and fairly ubiquitous and simplified four-step Design Thinking process. Development of clear and straightforward narratives to democratise Design Thinking and enable accessibility (or in this case buy-in) I believe is an acceptable strategy if executed correctly; however I think this video contains confusing elements.
The video sought to form a narrative around IBM’s value proposition which was demonstrated through a simple example. The addition of “Hills, Sponsor User and Playbacks” would not deem this particularly unique or significant enough to warrant a customization claim; nor would it directly address the “complex needs of large enterprises”. It appears as a rationalization of a semi-service design approach for a predefined problem regarding revenue targets sought via a digital channel.
Problem Framing: My questions centre on the framing of the problem, which is defined as ‘revenue not meeting expectations’ and I would want to understand this further. What are the business expectations and why are they so? What assumptions, agendas and data is this based on?
This leads me to question the bridge between their predefined problem and solution path of “website functionality”, with minimal regard for evidence, data analysis or true user research. If the physical retail business is doing well, what was the ‘fit’ between this proposed solution and user needs that deemed the digital channel a viable proposition for this particular business case?
Output-Orientated Product & Service Design: From this video alone, I believe IBM frame all design thinking as output orientated product & service design. Upon looking at another video [Understand IBM Design Thinking in 10 minutes] IBM claims “We treat everything as an unfinished product”. This dismisses any complexity that arises within large enterprises (that their unique model claims to address) and certainly does not consider complex business models, organization design, market forces, organizational environment, behaviors and values.
Agile Processes (with embedded assumptions of product development) and Design Thinking: I always find this a problematic combination and is a separate topic for another time. If hypothetically we were able to validate the problem framing was correct, and the solution path warranted an improvement to their website, then this would seem an appropriate process for solution development and delivery.
Features, Ideas and Outcomes: I found concerning and odd they confuse potential features or ideas as outcomes. Similarly concerning is the use of the term “wow” factor as some sort of quasi-metric for prioritization and success. These two elements alone do this video (and IBM) a disservice and in my opinion and swiftly relegate the designer from the boardroom table once more.
To answer your final question whether this video is adding to the clarity or the confusion around the subject of Design Thinking. I would say this does not describe (meta) design thinking and substitutes elements of service and product design thinking in its place, thus creating confusion for the use of design in more complex challenges that IBM expresses it is or wishes to tackle.
This video articulates an approach to improving existing digital solutions. It does not outline an approach to generate a new business or core value proposition. As an improvement approach, the video includes a few head scratchers and lacks some key elements.
Assumes the problem and solution at the outset which will limit the range of potential solutions (e.g. digital only.)
Does not account for business metrics that are key to shaping an opportunity. What makes for a good problem or solution from IBM’s perspective (for example: new customers, market share, differentiated value in the market place, etc).
Depends on a “wow” factor for decision making. Statements like this make it challenging for the business community to take design seriously.
Assumes it is a relatively simple leap from insights to viable solutions. And if a disruptive concept does emerge, how does the approach account for navigating the organizational gauntlet designed to eliminate risk and maximize near term reward?
Uses the term “Hills” in lieu of user barriers. We don’t know what the dimensions of the barriers are, or if any exist. Are they purely functional? Do they account for behavioral drivers? Barrier dimensionalization will drive problem framing and govern conceptualization.
Is void of enablers that cause a user to act in a particular manner. Opposite of barriers, enablers are critical to understand and consider as they often compete against solutions to barriers.
With this video, IBM isn’t focused on tackling societal challenges. As such, it shouldn’t be criticized as an approach for doing so. While there are far more designers working on enterprise software challenges than those working on societal issues. This video will not resonate with the latter for several reasons:
Does not accommodate a challenge scale. Societal challenges need to be viewed from a range of what we at Upstream term as altitudes. As shown, this video describes a product/service altitude. Zooming out to view gardening more broadly would open the opportunity landscape (e.g. how to get more people interested in gardening to making it part of their daily lives).
Is solution biased. Societal challenges need to be approached in a “solution agnostic” way. Rather than view the challenge through the lens of an existing digital offering, a societal challenge needs to be viewed through the broader human experience and the ecosystem that shapes overall behavior.
Does not define dimensions for “Hills” or barriers and misses enablers all together. Societal challenges require identifying dimensions that drive behavior across barriers and enablers. This allows us to identify the key levers to drive desired behavior across an ecosystem of stakeholders. Once the levers are known, it is then possible to deploy co-creation toward how to best pull those levers (e.g. digital solution, analog solution, messaging, policy, etc.).
Does not articulate a robust co-creation process to fill the gap between challenges and solutions. Societal challenges are rarely resolved with a single design intervention. As such co-creation needs to engage a broader set of stakeholders than those shown in the video.
Does not account for a diffusion of ownership. It is rare for societal challenges to have a single entity that is either responsible for the issue or able to resolve it within their organizational scope. The perspectives and motivations of all stakeholder groups need to be considered in problem framing and solutioning.
On the question of whether this video is adding to the clarity or the confusion around the subject of Design Thinking I would say it depends on the context in which this video clip is been used.
A general comment: I think all companies are struggling to create awareness of what Design Thinking is in their organization and to get to a place where 20,000-30,000 people understand, live, and breath it and apply it well – is in itself a complex problem (which deserves a good applied Design Thinking process…..could be a GREAT problem to work on as a more serious community.)
Video clips are a way to quickly show some broad principles, which might be useful if used with deeper work and I think the poor animator/video designer has a big challenge to do what is seriously complex in a way that is useful in some small way…
My bigger bug bear is the idea that short video clips (2-3-4 min) can teach everything in that space of time because people are too ‘lazy’ to invest the hard work of real, deep learning? It reinforces shallow thinking and the perception of knowledge on a topic. Short clips like these create the impression that DOING the work is just as simple and easy.
I ‘experienced” a so called Design Thinking process with an app at a conference (60 min?). What it really is, is an app to help someone along a brainstorm session (people loved it because it was fun but I guarantee no-one walked away with any real learning or insights at all). An app is useful to remind you of the next step in a process (if you are a newbie), but it certainly can not teach the skill of Design Thinking.
With this comes the idea that Design Thinking is the silver bullet for current organizational challenges….there are no silver bullets for anything and what is not well understood is the amount of work that is needed to do a good applied Design Thinking process with all the depth that is required
1) There is a need to make a clear distinction between the different types of Design Thinking. Product design, service design, UX design: none of these are the same and as such even though principles of good divergent and convergent thinking should apply, the context is very different for each of these processes, the the starting point is fundamentally different and the outcomes that a team/organization is working towards can not be the same either.
What is lacking in most organizations is the next level of Design Thinking (as you, GK, has pointed out on many platforms). Few clients are brave enough to really do it.
I know NextD and Humantific have for some time been working on making this distinction clear.
Maybe we could think of a way to collaborate with a wider audience/community to agree on clear definitions that could be accepted worldwide by the Design Thinking community, business schools and organizations?
2) There is a need for a far more rigorous “academic” approach. Not to make it theoretical as such but to deepen the understanding of the levels of thinking that is required in Design Thinking and to actually STOP and THINK.
Blindspot, HeadSpin and HocusPocus are three words that come to my mind after watching this video. In the marketplace today there are many other videos like it so parts of it look very familiar. This video more or less exemplifies a Blindspot that has infected much of the Design / Design Thinking industry. Watching this video it is no wonder that many organizational leaders and the public in general are confused about the subject of Design Thinking!
With the intention of helping our NextD Journal readers make sense of this video below are 10 HeadSpinsthat I saw embedded in it that seem to contribute to its confusion.
At 15 seconds: Indicative of the Blindspot version of Design Thinking the client challenge is magically, without hesitation, defined by the IBM narrator in the first 15 seconds of this video before any facts are known other than general marketplace conditions. From the get-go the narrator defines the problem path and solution path as “experience”. For anyone who knows anything about the front end of innovation [and today many organizational leaders do] that is a nonsensical notion. That giant assumption is HeadSpin #1. The IBM narrator does not seem to know it but what he is describing is known today as assumption-boxed methodology. Regardless of how it is being marketed, or what it might be called, any method that makes challenge and outcome assumptions up-front is assumption-boxed whether the seller is telling you that or not.
At 40 seconds: The IBM narrator suggests that the method being shown combines “Design Thinking” with “Agile” and is “based on principles that can be a great asset to anyone trying to solve a problem or find better ways of getting work done”. The depiction of wider applications for the method being shown is a central theme of this video that the IBM narrator repeatedly returns to throughout. Based on what was just shown in the previous sequence however this would appear to be a rather considerable leap of logic. How is general application to “solving problems” and “finding better ways of working” possible if the only challenges recognized are experience related? To be sure that is HeadSpin #2. Since what is being shown in the video is straight-forward Experience Design, why not just say so? Experience Design actually has a long history. Its strengths and weaknesses in the context of enterprise changemaking are well known. One might ask: What is the purpose of hiding and or creatively redepicting what this methodology actually is?
At 46 seconds: Reaching for even more descriptive terms the narrator describes this version of Design Thinking as “a method for practical and creative problem solving”. This would confuse anyone with basic knowledge of the creative problem solving (CPS) community. Perhaps unknown to the narrator, and possibly to the IBM strategists, CPS is an entire community of practice where deep methodology knowledge exists. Key is to understand that CPS methods are not assumption-boxed but rather assumption-free. HeadSpin #3 is suggesting the method appearing in the video is [assumption-free] “creative problem solving” when the IBM narrator just got finished defining the problem as experiencewithout a single situational fact being known. When you have at the outset of a project already predetermined the challenge path and solution path you are not selling “creative problem solving” but rather you are engaged in straight-forward solution selling. One is clearly not the other. In this video the IBM narrator seems to be confusing the two. Is this a lack of methodology awareness at IBM as in Blindspot or is this deliberate smoke & mirrors as in HocusPocus? What’s your guess…Blindspot, HocusPocus or something else?
At 1:59: Repeating the logic of the opening sequence, in the Green Genes nursery example the IBMnarrator immediately defines the client challenge and the solution path as experience related. The IBMproject team marches forward from that assumption immediately focusing on “users”. What this seems to mean is that in this particular method the initial Step called “Understand” already has the challenge brief embedded in it. That typically means someone, somewhere has hopefully already done the heavy-lifting strategic framing work to determine what the enterprise challenges actually are outside the method being shown in this video. The starting point for this method being shown is downstream in an already defined experience brief (framed challenge). In the video it is never really explained where the experience related brief actually came from. One might ask why this starting point? Why the slight-of-hand? Why the heavy spinning? That is HeadSpin #4.
At 2:46: During fact finding with Jane, the selected “Sponsor User”, the IBM project team and the narrator are already far down the Experience Design rabbit hole by this point in the Green Genes story. Jane, the “aspiring gardener” would have no knowledge of the problems facing the Green Genes organization beyond her own consuming experience. If the challenges facing the organization related to adapting to the constantly changing marketplace have nothing to do with fixing customer experience Jane can certainly not help them. Jane’s “priceless insights” are only relevant to the assumption-boxed experience challenge. The IBM narrator seems to be unaware that if the project team has presumed the wrong challenge Jane’s “priceless” input is not going to help them.
At 3:19: When the IBM project team regroups to “redefine the challenge” based on Jane’s input what gets reframed remains within the assumption-box of experience. At no time in the project journey does anyone on the IBM team including the narrator question the notion of experience as the preconceived problem and solution path. Based on Jane’s input what gets “redefined” are functionality requirements not the original assumption-boxed challenge. In the video no fact finding at all was done outside of experience to confirm what the enterprise challenges were assumed to be at the outset. In real life, the design of experience might be one of a hundred+ important challenges facing a large enterprise. Some of those challenges would typically be much broader than fixing experience. Where are the other 99 challenges? Where is the picture of how the 100 challenges fit together? Missing the opportunity to significantly alter course, after “redefine” the IBM project team remains down the experience rabbit hole. Does this mean that IBM “Design Thinking” teams are not allowed to venture outside the box of Experience Design? They are allowed and empowered to “redefine problems” but only within the assumption-box of experience? This is what the IBM Design Thinking team knows how to do?…and is allowed to do? Huh? Whether framed as “Design Thinking” or not, that would be an extremely limiting factor in enterprise transformation, especially around challenge framing. Clearly the terms framing and “redefining” can mean lots of different things, both broad and narrow. Rather than an adaptable Swiss army knife, this version of “Design Thinking” appears, in actuality, to be more like a single solution path hammer, being rather aggressively redepicted as a Swiss army knife.
At 4:22: The integration of what is described as “Agile” in iterative prototyping and feedback aligns with the front end of the assumption-boxed method being described in the video. Truth be-told both Experience Design and “Agile” are assumption-boxed, with “Agile” also often being time-boxed. Setting aside the ambitions of “Agile” advocates presently “Agile” is about developing “functionality” iteratively and efficiently. The addition of “Agile” in the Green Genes context does nothing to alter the front-end challenge and solution path assumptions already described by the IBM narrator as experience related. Of course outside in the marketplace, other practitioners already engaged in acceleration and iterative prototypingas part of design process might question the need and value of depicting these elements as newly minted by “Agile”. Now enjoying a resurgence, acceleration, iterative prototyping and feedback loops are not unique to “Agile”. All existed long before “Agile” arrived. Evidently the addition of “Agile” conceptually fit within how IBM was prepared to alter its previous “Design Thinking” approach and market it to its business clients packaged up as a new version of “Design Thinking”.
At 5:04: With the video wrapping up, the IBM narrator returns to the notion that the methods depicted in the video described as “Design Thinking” and “Agile” have the potential for “more far reaching applications”. Again the theme of aspirational questing for more generalized applications of the method runs throughout the video. Never explained however is how a predetermination towards framing Experience Design challenges connects to all challenge types found in large complex global enterprises. The “Agile”community itself has similar aspirational strategic ambitions that are not yet realized due to the same framing limitations that Experience Design methodology has. This video presents a look into what happens if you stitch together two assumption-boxed approaches. There is considerable irony in that both Experience Design and “Agile” are confusing subjects where the practitioners aspire towards more strategic applications. To be clear there is inherently nothing wrong with assumption-boxed methods.They are useful in downstream contexts where the actual challenges have already been defined. Since they contain assumptions regarding both the challenge and the solution path assumption-boxed methods are not conducive to upstream organizational [and societal] contexts where the challenges are often fuzzy, diverse, complex and at the outset unknown. Central to contributing to massive public confusion on this subject of Design Thinking is the re-depicting and selling of downstream assumption-boxed methods as upstream assumption-free methods. Truth be told this is probably the #1 elephant presently occupying many Design Thinking living rooms today. This re-depiction practice has become widespread but is certainly not universal in the industry. As a community of professional practice we might ask ourselves: Is this re-depicting an ethical and solid foundation for the unfolding future of Design / Design Thinking? What’s your guess?
At 5:34: In closing the IBM narrator returns to the theme of acceleration pointing out that as the marketplace changes we all need to “evolve faster than ever” and “keep reinventing ourselves everyday” as an important objective. The disconnect would be assuming that capacity for reinvention is connected to mastery of Experience Design. Welcome to HeadSpin #9. Going forward all of us are going to be encountering a continuous stream of widely diverse fuzzy complex challenges, not just Experience Designproblems. In the open marketplace, outside the logic of this video, it is already quite clear that adaptable changemaking capacity requires adaptable, assumption-free methods and skills. It is already known that organizational agility and “Agile” are presently two very different things. The latter is not going to translate into the former anytime soon. It is already known that however you package them, downstream assumption-boxed methods are not ideally suited for highly complex fuzzy organizational [and societal] change contexts.
At the end of the day this video seems to present the results of a methodology redesign effort that evidently took place within a giant global, technology oriented corporate culture. For some unknown reason the redesign alters the tactical back end but not the strategic front end of this methodology. Referring to this methodology as “Design Thinking” rather than Experience Design does not alter its downstream nature. Redesigning the front end of such methods, where framing occurs would certainly have broad impact on its strategic applications beyond experience challenges, wherever it might be applied inside and or outside of IBM. The tricky part is that strategic shift from downstream assumption-boxed to upstream assumption-free would also require different skills and tools. Shown in this video is essentially what we call a stay-in-the-box version of Design Thinking often attractive to business folks who seek to “manage” “Design Thinking teams” in organizations. This version is suited to a particular corporate culture. The need to redesign the front end in order to full-fill the various adaptation promises being made in the video was evidently not recognized. Since this is primarily traditional Experience Design being repackaged and redepicted as new, untraditional Design Thinking that would be a headspinner for many viewers. With that degree of head spinning in mind I would say this video significantly adds to the confusion on this Design Thinking subject.
With 500,000 views of this video underway on YouTube the mistake would be to assume that what is being depicted is the sum-total of what Design Thinking is. At best this is a highly corporatized downstreamversion of Experience Design Thinking being creatively repackaged with strategic ambitions not yet realized in actual methodology. That gap between philosophy and methodology, between strategic ambitions and methodology realities is not unique to IBM.
In the context of NextD Journal we are interested in making sense of the arriving future of Design and Design Thinking/Doing. We have a particular interest in examining the alignment of challenge scale and challenge complexity to methods, toolsets and skillsets. With change now constant and global challenges rising there is considerable effort underway in many communities of practice to better align changemaking tools and methods with the types and scales of challenges facing us in our organizations and in our communities on this planet Earth.
The good news is this need to seriously rethink the strategic aspect of Design Thinking/Doing has already been recognized elsewhere in the design community operating and reinventing methodology outside of a single corporation’s constraints.
When we consider the vast array of organizational and societal challenges that designerly folks seek, in good faith, to participate in, the need to engage in serious methodology redesign on the front end, not just the back end seems clear. As the applications of design / design thinking/doing migrate to larger and larger scale challenges containing increasing degrees of complexity there are already many things the community of practice will need to consider. We will be exploring this slippery subject more going forward in this ten part series. Please feel free to join us on this unfolding journey!
Hope this is useful to our Next Journal readers! Good luck to all.
Stay Tuned for NextD Journal [Reboot]: Document in Review #2: Coming Soon!