While considering the earlier stages of the design thinking process, we've seen how the various stages in the design thinking process offer some useful concepts and techniques for architects. For example, the prototyping stage is about creating a way that consumers of the product or service can imagine themselves using. In design thinking, a prototype can just be a storyboard – and this in turn shows the value of making an effort to tell a story while you are creating and socializing the initial drafts of the Enterprise Architecture program with stakeholders.
The final stage of the Stanford d-school methodology is called 'test', and just as for the other stages in the process, it offers some useful insights that are possible to draw from.
Before we can talk about them, we need to clarify our definition of testing for the purposes of this discussion. Unfortunately, the word 'test' triggers some associations with most architects – just as with prototypes, the idea of testing an architecture immediately brings up images of an actual implementation that is then made to execute test cases to flush out problems with the implementation. But we're not at that stage in this discussion.
The confusion comes because the truth is, we aren't testing the implementation when design thinking talks about testing. We're not even testing our prototype. What we are testing is our understanding of the problem, how we've formulated the problem, and how well the potential consumers of the product or service feel it actually addresses their problems.
So, just as the prototyping stage of the design thinking process implies that we should prepare one or more stories around the architecture so that stakeholders can visualize how the proposed architecture would be used and how it would address their problems – the test stage involves actually telling those stories to those stakeholders. The test stage of the design thinking process essentially corresponds to the review stage for the draft architecture – but with caveats.
The caveats are, amongst others, the lessons that we can learn from the test phase of design thinking process. First, the objective of the review should not simply be to pass the review, but to seek feedback – and, if necessary, provide insights to allow the proposed architecture to be improved before a firm stake ends up being placed in the ground. It is possible, in the test phase of design thinking, to encounter completely new insights that did not come up during the empathy phase, and this is not seen as a sign of failure, but merely a natural outcome of the process. In the same way, the review of the proposed architecture is an opportunity to flush out assumptions or concerns that did not come out in the initial scoping phase.
Secondly, the presentation of the draft should include use cases, since one of the goals is to enable stakeholders to imagine how the architecture would work once implemented. One approach that could be used here is to identify a historical problem the likes of which the architecture is hoped to mitigate. For example, the chief architect of the State Farm insurance company related how attempts to institute a payment holiday for victims of Hurricane Katrina caused all kinds of problems – and he was able to reference this when making the case for the Enterprise Architecture program years later. I'm going to go out on a limb and suggest that the vast majority of organizations will have some similar nightmare problem that they can remember with a shudder.
In an ideal world, we'd also be able to implement another area of philosophy from design thinking's test phase which allows the potential consumer to experiment with the prototype themselves. Alas, the environment of enterprise architecture limits our ability to do this. Despite this, the two insights that we've gained offer useful techniques that could contribute to the success of the program.