Exponential cost of fixing design defects

The later a problem in your app is detected, the more expensive it will be to fix it. As the implementation keeps growing, often on top of what is already created, the amount of time to fix a problem that stems for a design issue a lot of rework may have to be performed and the cost of this could very well be exponential based on how long it took to find it as it can require fundamental changes to the implementation. This is similar to how the cost increases exponential in general for software defects as is illustrated in the image below.


Why detection happens too late

So what are the reasons for it taking a long time to detect design issues? There are two reasons for what leads to issues to be detected late.

Better specifications is not a solution

In the context of complex applications with graphical user interfaces such as for the web, there can be a lot of room for a developer to interpret a functional specification for how a new change should be implemented. Creating a specification to describe how every possible situation should be handled, such as how text should be wrapped when content is too long to fit, the visual appearance of buttons on hover and click, changes to layout and styling for suiting different screen sizes are just a few examples of what developers normally have to figure out for themselves. It is therefore likely that the output is not going to be exactly what the designer originally intended for. But it could also be that the designer did not know what would be the best solution and could only discover it after actually testing the product.

Even if a specification for a new feature was 100% complete (which is not possible), it would likely not just be a waste of time, but also a waste of opportunity. Leaving room for interpretation allows developers to use their own creativity and experience to create better solutions than could have been thought of by the original designer. The developer has intimate experience with many different ways of implementing various functionality and knows existing off-the-shelf libraries that could be used for high quality output at a low price. Creating a specification that is too detailed can deprive the end result from many design improvements and cost savings.


The solution to this is that developers need to work tightly with designers and customer representatives such as product managers and customer support throughout development. For this, you need frequent releases (or deployments) so others can test and validate that it solves a need in a good way.

Some companies use a staging environment to solve this, which is an environment for web applications to run that is similar to the production environment. However, this solution is only appropriate if what is being deployed is already ready for going to the production environment. Continuous development can not easily be done with a single staging environment as other changes other developers are working on may need to be added to it which then can not go to production if yours are not ready.

To be able to do this, you need a solution to create a new staging environment for potentially any new feature or change you want to make to your app and make it easy to distribute a link to this version of the app to people that need to test it.

Get all latest news and articles

Receive emails with tips for improving your software development processes and news about updates in Valist.