Design Debt
We know the dangers of accumulating technical debt, but there is a debt that is potentially more dangerous -design debt.
Technical Dept is a well known concept for tech companies. There is always some code that is clumsy and rushed, workarounds tied together with string, corners cut because of deadlines, poor documentation. Its a debt that needs to be paid. If it isn’t, life will get increasingly complex: New features will be harder and slower to implement, you will lose flexibility, and the user experience (as always) will be the first to suffer.
One of the objectives of agile, an approach most startups appear to adopt, is to keep this debt in balance, to tread the fine line between business needs, user benefits & product development roadmap. Like financial debt, technical debt incurs interest, which comes in the form of the extra effort that we have to do in the future because of our previous choices. We can choose to continue paying the interest, completely ignore it and blast ahead regardless, or we can pay down by refactoring. Although it costs, and we may feel that we have nothing to show for our efforts, we gain in the long run.
Not all companies have the benefit of being lean agile startups. Many products and services evolve out of existing business, are subsidiary ventures of other organisations, or choose not to take a lean development approach. It can be much harder in a bigger business, one with multiple products, or products that are responses to digital shifts (for example publisher moving into ebooks) because you have an existing structure and traditional processes. Organisations like these need to actively consider the dangers of accumulating technical debt.
There is another kind of debt we need to examine though, one that is potentially more dangerous to the business than technical debt, design debt.
Design debt is more dangerous because it can start before a line of code has been written. It can start at the very inception of a project, for if we build our product without a real vision for the joined-up-user-centred-experience we want to create, our products will already be suffering from design debt — because they haven’t been thought through properly. When technology products and services evolve with design debt, it can compound technical debt, because we can spend our time paying down for solutions that are fundamentally ill conceived, essentially putting good money after bad.
While doing a little more research on the subject of design debt, I came across a simply excellent article by Andrew Chen.
The point is, as a product experience grows deeper, at some point the initial design philosophy of just adding more links to a page or more tabs or more buttons just stops scaling. Yet it’s often hard to reorganize the whole site, especially if it means taking a short-term dip on traffic, so the “safe” thing to do becomes to incrementally add things until the user experience is horrible.
Infact this article is so good, so comprehensive and well informed that I am going to bow out gracefully after a final cautionary paragraph, to Andrew Chen’s article on Design & Technical Debt” and highly suggest that you read that one.
Perhaps sometimes our enthusiasm makes us rush into building new products, new features or services without having really-truly-properly examined them from a design thinking perspective. ‘Confirmation bias’ is the tendency of people have to favour information or feedback that confirms their existing beliefs — sometimes we love an idea so much, get so fixed on it’s brilliance that we just don’t want to hear that it won’t work or isn’t viable.
I worked in a team on the discovery phase of a social app for teenage girls with a killer idea. The group was very enthusiastic, and we worked up some rapid prototypes which we were all equally energised about — it was exciting, we were on to something! It was only when we entered the persona development phase, created imaginary users with tangible personalities, interests and backgrounds, that we realised the product was fundamentally flawed. A gloom fell, like when the sun goes behind the clouds, and it was suddenly obvious to all of us. Teenage girls simply wouldn’t use it.
In an alternate universe, one in which we didn’t take a design thinking approach, the product would have been built and marketed with great enthusiasm but be plagued by lack of user adoption, and be ultimately doomed to failure. There would be a big meeting with serious faces where they would puzzle over the lack of success. They would look everywhere for a solution, except where they really needed to look, but it wouldnt matter because it would be too late.
This is perhaps a true definition of design debt.
This article was first posted on breadcrumb.tv
