In these pages I have been emphasizing the value of frequent iteration and gathering feedback on the smallest steps possible. These are the ingredients of Design Thinking. But, you ask, what if I don’t get to design the product? What if we are just making a procurement decision and rolling out an existing commercial product? Does Design Thinking apply?
Over the wall
The phrase “thrown over the wall” describes the circumstance where one group does its part to produce a product or service and then “throws it over” to the next group for further development.
Examples include an architect sending plans to engineering; engineering sending car plans to manufacturing; a business analyst sending user requirements to a project manager. In each case, absent thoughtful iteration and contact between the two parties, the result will be the first group giving an unnecessarily difficult and incompletely defined task to the second.
Design Thinking intends to avoid these “over the wall” events by using multi-disciplinary teams and iterations, i.e. multiple returns to the user with increasingly developed prototypes in order to ensure that the work being done is in alignment with the users’ needs.
Sometimes you need to throw something over the wall
For example, it’s time to replace your Enterprise Resource Planning software.
There are two phases to this project: before you buy, and after. Unless you have money to burn, or your original decision was truly disastrous, you don’t get to buy enterprise scale software and then ask your community, “Do you like it?”
A procurement decision of that magnitude is a one way trip, a decision “thrown over the wall”.
However, you can put iteration into the two before and after phases. In fact, it’s critical.
Before and after
Before making the decision to buy a product, gathering user needs can be an iterative process. You hold interviews, make observations, then make a prototype (and by prototype I mean wireframe, produce a narrative, an animation – anything that helps you and the users improve confidence that you know what they do and what they need) – and then iterate until that confidence is as high as possible.
Compare the prototypes to what is available in the competing enterprise software packages. Can the user get their needs met and how easily? This, along with other factors like cost, ease of integration etc, inform your procurement decision.
After you buy, keep those user observations handy. It’s time to roll out the software, make the configurations and provide training. These steps are informed by the user observations. Here again you can iterate. You know what was important to the users and have levers to pull – configuration and training – each time comparing what the user wants to what the user is getting.
