I’ve written before about why I believe that software development should be separated from usability. In this post, I’d like to expand on this theme and discuss why some people (designers in particular) should consider breaking the separation. When designing a website or program, a designer is typically involved in the process from start to finish – literally from concept to completed product. If usability is also an important factor in the process, then there’s a lot more work involved in the development stage. After all, even the tiniest details can change the fundamental structure of the final product.
A designer may have a strong expertise in the realm of software design and website development, but zero knowledge of the user interface, search engine optimization, usability and end-user experience. Should these experts spend all their time in just the development phase? Obviously not. They’d benefit from a broad spectrum of skills.
The opposite is true for software engineers.
They’ve typically spent years acquiring specialized skills in various software engineering disciplines. But their biggest strength is also their weakness. They don’t know anything about the technologies, languages or user interfaces on which they work. And they certainly can’t relate to the designers or executives who do.
Separating these two “teams” makes a lot of sense. The software engineering discipline doesn’t know or care about the user experience at all. It’s job is to optimize the cost of production. And the usability aspect can be dealt with during the project. Both sides can be successful.
But sometimes the software project doesn’t go to plan. The usability issue may not be as severe as originally thought. Or the end user may demand more flexibility than was expected. These things happen.
In these cases, it’s best to hire a user experience designer to deal with the user issue.
Designers have an intimate understanding of how users think and why they’ll be happy if a certain feature is included. They can work with the software engineers to remove certain undesirable features or add new ones that will meet the needs of the current and future users.
So should software development be separated from software design? There are some cases where it really makes no difference. If the software is going to play a major role in business decisions – say, the product is supposed to replace a current business system – then it’s probably a good idea to have the two involved. The resulting product will almost surely have a desirable outcome. Separating the two helps identify weak areas and improve them before the release goes live. It also makes it easier for the software engineers to realize potential usability issues early on.
On the other hand, a software engineer may have to ignore usability issues and focus on functionality. That’s usually a better approach for him/her. After all, what’s the point of having nice-looking software if the end-user doesn’t like it. And we’ve already established that it’s usually the programmer’s job to add functionality. So separation is definitely a wise option for most projects. Separation keeps the software cleaner, allows improvement without breaking the code, and lets the end user get what he/she wants out of the software.
But how do you know when separation is necessary? When software is clearly too different to be used together, for example when the software contains two or more programming languages (C/C++ and Java), or when the software’s data models and interactions are so different it’s difficult to decide what they should mean or how to map them. These situations usually mean that developers should separate the two. Or, if the projects at hand are so similar that usability must be closely considered, then it makes sense to build them into the same application. Some software companies choose to build a program from scratch that incorporates both elements.
Should software development be separated from software design & usability?
This again depends upon the project’s goals. When the software developer has a clear goal in mind – such as “create a new innovative project,” “implement an existing application,” or “improve on an existing application” – then usability and design should be considered apart from the software itself. However, if those goals are less clearly defined, then it is likely that there should be some degree of separation.
Last but not least, a business can benefit by having its software and its source code protected from competitors. If a competitor can come up with an application that utilizes some of the same technology as your software, you may lose business. That’s why your business needs to consider whether it’s worth the cost to have its software protected. After all, your competitor could simply abandon their efforts and sell your own technology to your existing customers. You need to consider how much it would cost in terms of lost business to have your software protected from competition and consider whether it’s worth the cost.