In an ideal world, all software projects would have an interaction designer or user experience (UX) specialist working with the team to ensure that the product is designed in a way that truly satisfies the needs of end-users. In a software project with separate business analyst and interaction designer roles, the work of these professional is complementary. While a BA is making sure the business requirements are well defined and understood, the UX professional may be researching the user segments and creating personas to represent their needs, goals, and related tasks.
In this interview with Laura Brandenburg, UX specialist Patrick Quattlebaum describes the benefits of introducing user experience in a project’s early stages:
The value of UX early in the process is to introduce the user lens to this upfront work. At a minimum, user research has also brought some feature ideas to the table, and feature prioritization involves finding the sweet spot of features that align business with user value and can be built and maintained within the technology constraints. Ideally, UX has helped frame the design problem around business goals and user goals, not technology. We bring our understanding of human behavior to the process because we see users as the key integration point.
A project is much more likely to receive help from user interaction and usability specialists when its product is a high-profile commercial software or web application. For internal applications and non-commercial customer-facing software (such as Internet Banking applications), it is common for a project to unfold without the involvement of a UI/UX professional, and with complete disregard to considerations of what is valuable for the user in the first place.
A UX designer helps create business value by shaping software products in a way that increases the likelihood of achieving the intended outcomes of their use. Without the influence of a user experience advocate, it is common for the development team to direct its attention exclusively to individual features and functions described in the requirements, implementing a design that allows users to complete tasks, but not necessarily achieve their goals or solve their problems. As Alan Cooper points out in his book The Inmates are Running the Asylum, “programming is such a difficult and absorbing task that eliminates all other considerations, including the concerns of the user”.
As an example, consider a support person who is talking with a customer over the phone. The customer has several service request tickets she wants to discuss, but the system only allows the employee to view and update the details of one ticket at a time. Each time the customer talks about a different ticket, the employee has to go back to a search page and reenter the name of the customer to get the list of the open tickets and select the appropriate one . The process to open and update each of the customer's tickets is slow, prone to errors, and frustrating both to the support person and the customer. All the required functions--select a customer, open a ticket, update a ticket--are there, but organized in a way that does not reflect the actual user needs.
In order to avoid user experience problems in their projects, business analysts may need to step up to the plate and take on the additional role of interaction designer. In fact, after performing some analytical work, a BA may very well discover that improving the user experience is the fundamental problem that needs to be solved by a project. This reality is more frequently when a software product has been already built, and feedback from users (before or after the application is put in production) indicates that the main problems are a not a result of missing or inadequate features and functions, but rather of the difficulty of using them. However, if a project starting from scratch is lacking a clear user interaction strategy, it is a good idea for the BA to include, in the business analysis work plan, user interaction design activities related to thinking through the interaction aspects of the product, defining the personas, and articulating the problems that the design must solve.
A few years ago, I was hired as a BA to help a team responsible for an internal web application that had a huge list of items in the product backlog, with requests ranging from additional reports to more details to be displayed on a page. My first task was to help the business stakeholders reprioritize the items in the backlog. Many of these items had been made obsolete by changes already made to the system, and several included requests that conflicted with each other. After the review of the backlog items was completed, it became clear that most of the change requests that were still relevant didn’t address the root cause of the problem: a poorly designed user interaction.
To determine whether the point of failure is the way users interact with the functions and features of the system, rather than the functionality itself, a BA may have some analysis to perform. In the example above, this understanding came as a result of interviews, research of system behavior, and observation of how employees who used the system actually worked. Through this process, I was able to identify critical design requirements that had been overlooked. For example:
-
It was established that the needs underneath the request for new reports could be easily fulfilled by the “advanced search” functionality. Only a few users were taking advantage of the the advanced search properties because the choices to filter results were not presented in a way that was intuitive to the majority of the employees. Adding more reports would only clutter the user interface; the real solution consisted in redesiging the look and feel of the advanced search page to facilitate user inquiries and saving these inquiries for future reuse.
-
Data fields that users wanted to be included on a page turned out to be easily accessible through an option to expand the details of a record with a simple click (if a user preferred to always see the expanded view, he/she would have to use the option to expand only once, as the system already had a built-in feature to make it a “sticky” preference). Again, the problem was not the system behavior, but rather a non-intuitive design that prevented users from noticing that useful collapse/expand functionality that was already available for them.
A business analyst joining a project that doesn’t include a user interaction specialist should be ready to take on the responsibility to help the project team design a product that doesn’t create obstacles for customers to achieve their goals, or employees to perform their jobs. By forgoing this initiative, the analyst may be unwittingly contributing to the creation of feature-rich but hard-to-use products that continue to frustrate users no matter how many new reports, features and functions are introduced to the application. A BA who feels comfortable wearing the hat of UX designer will be in an strategic position to take into consideration the “human factors” that can make a software product not only efficient and usable, but also easy to learn and pleasurable to use.
To learn more about user interaction design, check out these resources:
Interaction-design.org
Interaction Design Association Resources page
Jakob Nielsen's Alertbox
Recommended books
Author: Adriana Beal has a B. Sc. in electronic engineering and an MBA in strategic management of information systems. For the past 10 years, she has been identifying business needs and determining solutions for business problems for a diverse client base that includes IT, telecom, and major U.S. financial institutions.