The first two steps in the Stanford design thinking process focus on identifying and defining the problem (or, just as often, problems) that the design thinking process is being used to solve. The traditional architect is often inclined to be see these first stages as a bit ‘fluffy’ – especially when they are used to striking near to the mark in seeing the problem themselves (I speak from chastened personal experience here). That said, defining the problem is not always as simple as it can seem at first glance – Henry Ford is often quoted as having said that “If I had gone out and asked people what they really wanted, they would have said ‘a faster horse’.”
In contrast, the third step in the traditional Stanford process is ‘ideate’. The interaction with the enterprise architecture field for this step is very interesting, as the techniques used in design thinking ideation are in illuminating conflict with the way that most architects work. What I mean by this is how design thinking ideation is always intended to be a collaborative exercise, while most architects are used to identifying ideas by themselves, thinking deeply about each possible approach in order to look for pitfalls. In this post I’m going to look at why this is, and suggest an approach for getting around this problem based on personal experience.
The range of techniques for ideation – coming up with ideas in groups – is numerous and there’s really no value in my doing a review of them here, as I won’t have anything useful to add. For those seeking more information, Google is as always a useful friend, and I’m also going to recommend Dave Gray’s outstanding book Gamestorming as a reference work for brainstorming techniques, tied together with a well-thought out theory of how to tie brainstorming activities together.
The thing that ideation techniques have in common is that they all preach that you should not focus on the hard-nosed feasibility of the idea, but rather ‘Stick it up there’, and discuss it later. Often the improvisation comedy technique of “yes-and” is suggested to ensure flow (meaning, no matter what you think of someone else’s idea, you can either accept it and adapt it, or keep thy mouth shut). This is a critical point. In order to keep ideas flowing at maximum speed, no idea can be shot down in the ideation stage.
Contrast this with the architect’s traditional approach to ideas, where the architect prefers to come up with ideas on their own and then validate the feasibility of each one before suggesting them to any group that may exist – at this point I’ll plead guilty to this myself. This impulse has good foundations. Technical experts are all too familiar with the non-technical person who suggests that something must be possible, based on – well, in practice, because they want it to be. A classic example is the 1990s fashion retailing startup boo.com, that failed for various reasons, not least that its graphics and flash-animation heavy website failed to load on the dialup connections that most people had back then. The technical employees who kept predicting this were dismissed with “Oh, you’re just being an engineer”.
At the same time, lack of technical understanding on the part of executives provides a dangerous opportunity for office politicians and outside vendors to use misconceived ideas to gain power or budget spend, respectively, to no good outcome.
So the swashbuckling, ‘anything goes’ approach used in design thinking ideation is valid, because it’s necessary to generate the maximum number of ideas. But at the same time, the caution from the architect is valid, because of the need to guard against impossible ideas that then get fixed in the heads of executives (Architect: “This assumption violates the second law of thermodynamics!” Manager: “Rules were made to be broken”). And this is particularly a problem in enterprise architecture because the non-technical people must necessarily be involved in any useful brainstorming.
So how can the techniques of design thinking ideation become useful in an architecture context?
What’s needed is a filter - a mechanism to sift the ideas coming out of the ideation stage into the impossible, the impracticable, the hard, the easy, and so on. Now, some might say that the following stage in the design-school methodology, ‘prototype’, would be where you’d do this, but in the brainstorming-focused environment promoted by design thinking, the risk is that in all the enthusiasm this is not so likely to happen.
An alternative approach is to assemble a ‘filter team’ as part of the ideation stage that can do a quick sanity test of each idea. Ideally this team would rate them on some scale with comments. I would personally recommend a qualitative scale such as ‘physically impossible/ highly difficult/ difficult/ effort/ easy/ trivial’ instead of a numerical scale, purely because such assessment should be high-level and vague at this stage, and a numerical scale often provides a sense of rigor that in this case would be unfounded.
Infeasible? Not at all, because I personally have participated in just such an exercise. We set up a pipeline, where the product managers and sales reps would brainstorm at a table next to us architects (we were free to provide input if relevant and technical-focused, such as technical trends), but at half-hour intervals the collection of ideas would be filtered down and fed to the architects to brainstorm and rate. Once we had done this, the ideas were passed down to the next table, who would brainstorm on prototyping and market research possibilities. The end result was about 10 product ideas that were signed off on by every stakeholder.
So a filtering stage is a better idea in a situation where the ideas can become dangerous runaway train fantasies, such as in the enterprise architecture space. Of course, like everywhere, there’s no free lunch. Such an approach can only work if the filtering team comprises the kind of architects that embrace change while foreseeing obstacles. So, just as in any exercise, selection of team members for such a group is both a delicate and critical exercise. Also, such a group should be involved in the ideation itself, so that they are invested in the overall output of that exercise. Some training may be needed to help them temporarily drop their natural architect’s skepticism. Regardless, a filtering ‘tiger team’ can be an effective approach to square the circle and ensure that the ideation stage flows correctly into the prototyping stage.