It’s common knowledge that companies throw small fortunes on IT development in the trash, without ever seeing a proper return on that investment. The numbers are public and speak for themselves.
This is one of the major concerns of decision makers who either buy software development externally or develop it internally. They are becoming aware of the need to implement a common framework for evaluating IT projects. This can be done by adopting common methodologies to gather requirements early in the projects. Keeping track of requirements from the source to the final output is the only way to control the money spent on IT.
But one thing is sure, integrating only Business and Technology requirements is not enough, if most of the time the requirements are based on assumptions and extrapolations. That’s where we, UX specialists, can help companies by also integrating requirements from the User perspective. Involving the users right from the start increases the chance of success for the IT development process:
- Because the Business frequently has many misconceptions about what the user want;
- Because this process brings final users on board, making them also “accountable” for the result;
- And because some of the key users can become “evangelists” among their peers when it comes to adopting the new tool.
How can UX fit into Requirements Engineering?
Requirements gathering lead by Business Analysts often turns out to be a succession of (endless?) meetings with business teams. A group of people sit together during several hours and try to explain to analysts the way they work, what would they like to have in the future, and so on. What happens normally is that a lot of assumptions and extrapolations are made in these sessions. Assumptions about what final users want and how they really work. And this is a normal phenomenon as IT professionals working in house gain years of experience in their fields, they also lose some fresh perspective on their business and on their end users.
So, the work of the UX specialist is basically to “validate” all these assumptions (rather than “discover”) against real world scenarios. In the process you can be sure that many requirements will be dropped, others will be changed, and new ones will be uncovered.
Our aim, as UX specialists, is to design correct usable things, (rather than wrong usable things) and a big part of this is achieved by conducting correct user requirements gathering (commonly known as User Research) by applying the correct research tools to each project. These can include Contextual Inquiries, Field Studies, Cultural Probes, Focus Groups, etc, depending on time, budget, scope and availability of people. Different approaches require different resources.
In conclusion, the sooner a project is correctly aligned with the real user needs, and the requirements are traced from the beginning to the end of all projects, the higher the chances are of having a good return on the money invested in software development.