Design Science Process

The most common mistake in building anything is starting to build too soon.

There is a pattern so widespread that almost everyone has either done it or watched it happen. Somebody has an idea, they get excited, and they start making the thing. Code gets written. Prototypes get thrown together. Meetings happen. Months pass. And only when the thing is nearly finished does anyone notice that the problem it was meant to solve was never clearly defined, that the people it was meant to serve were never actually asked, and that the criteria for success were decided after the work was already done, which is a polite way of saying they were made to match whatever came out. The product ships, the team claims victory, and six months later everyone quietly stops using it because it never really addressed the thing it was supposed to address.

There is a formal model in design science research that tries to prevent exactly this, and it lists six steps, not two. The first two steps, which almost everyone skips in the rush to build, are identifying the problem properly and defining the objectives the solution has to meet. Only then do you design, develop, demonstrate, evaluate, and communicate. The discipline is boring, which is why it gets skipped. It is also the difference between a solution that works and a solution that merely exists. Rigour is not what happens at the end when you measure your results. It is what happens at the beginning when you decide, carefully, what you are actually trying to do. What have you seen someone build in a hurry that turned out not to solve the problem it was supposed to solve?

Last week we said building something can itself be a way of knowing. This week we look at the most common mistake in any project, which is starting to build before anyone has worked out the problem.