Misconceptions about the role of design in software projects still live strong. Our Business Development Manager Eeppi breaks down the most common of them.

Regardless of the popularity of various service design approaches in recent years, the importance of design in both software and business development is still not fully understood.

We see the effects of this relatively often when discussing with potential clients. Many companies want to start the ”actual development” as soon as possible to have a release version in their hands quickly. Unfortunately, this may end up being something that fails in the market because it was not needed or wanted after all.

Increasing the risk of building something that ends up being useless is unfair to our customers and not a good look for us either. And even if the result is not a complete catastrophe, the cost of ”designing by coding” is almost invariably much greater than building a solid foundation for the project with design methods and research.

Increasing the risk of building something that ends up being useless is unfair to our customers and not a good look for us either.

This, in a nutshell, is the reason we won’t do projects where there is not a sufficient enough emphasis on design.

In our view, the problem stems from a fundamental misunderstanding of both agile philosophy and the role of design itself.

Instead of (or perhaps in addition to) ”making things look pretty”, good design aims for efficiency. Instead of increasing costs, it seeks to lower them in the long run. Good design doesn’t seek easy victories but rather ones that are more future-proof.

Here is a list of some common misunderstandings about design – and our responses to them.

Claim #1: The purpose of design is to make things as pretty as possible

This misunderstanding probably stems from the ”pretty but expensive” stereotype often associated with the word itself. However, this is most definitely not what good digital design aims for. Rather, the goal is to find the core purpose of the product at hand, get rid of the clutter around it and present it in a way that is as simple as possible, great to use and, ultimately, something that the audience wants to use. This is why allocating enough resources to design creates better software and lowers the overall cost in the long run. In short, it’s about seeing the bigger picture before the proverbial poo hits the fan.

Claim #2: Designers are only concerned about looks and not practical things

It’s easy to see how this misunderstanding logically follows claim #1. Designers are, first and foremost, concerned about finding out the core problem of the client and creating a service that best answers the said problem. This is crucial to make sure we’re even building the right thing and that we’re building it the right way.

Claim #3: Design and research add significant costs

This claim is true in the short term. But again, we’re playing the long game here. Firstly, when designers research your unique business case and users, that deep understanding of both the users and the market results in a product that truly serves its audience. The worst possible scenario in terms of budget is a product that no one uses or that has to be completely rethought soon after the launch.

The worst possible scenario in terms of budget is a product that no one uses or that has to be completely rethought soon after the launch.

Secondly, good design helps to keep your users happy. Regardless of whether you’re building software for consumers or your company’s internal use, people have high standards in terms of UX. Thirdly, a well-designed product is longer-lasting and further development can actually focus on new features and enhancements instead of trying to fix a broken foundation.

Claim #4: Design slows down the development

Good design makes development faster, especially when designers and developers work in the same team. This way, we can base the technology choices and architecture on the goals and features of the service, backed up by the service design work. As a rule of thumb, making changes in code is slower than making changes in design. Thus, when designers and developers work together from the get-go, they’ll be able to optimise this balance, saving a significant amount of development hours.

The future is design-driven

During the past few years, the number of designer recruits has been on a sharp rise in Silicon Valley. This trend is in line with our way of thinking: at Taiste, we have found it extremely beneficial to have as many designers and developers working in our team.

Design minimises some of the biggest risks in software projects and that alone is worth the price of initial admission.

Design minimises some of the biggest risks in software projects and that alone is worth the price of initial admission. Whether, as the saying goes, well begun actually turns out to be half done in any particular software project depends on many factors. What good design can promise, however, is that it allows us to see what really must be done and what, indeed, can or should be left undone.

Do you have a digital project you’d like to create a design concept for? Don’t hesitate to contact us – with our design sprint service, you’ll ensure a solid foundation for successful development.

Voisit olla kiinnostunut myös näistä: