Recently, I’ve bumped up against people asking me what user experience is and what it really means in the development process. These questions surprised me a little, as from my perspective, UX is well-established discipline within the software development industry, with a proven track record of improving the product quality based on user feedback.
There are many definitions out there to draw on when attempting to explain “user experience”. According to uxdesign.com, user experience is “the judicious application of certain user-centered design practices, a highly contextual design mentality, and use of certain methods and techniques that are applied through process management to produce cohesive, predictable, and desirable effects in a specific person, or persona”. In the same article, former Vice President of the Advanced Technology Group at Apple Don Norman is quoted, explaining user experience as “all aspects of the person’s experience with the system”. The International Organization for Standardization (ISO) defines user experience in ISO 9241-210:2010: Ergonomics of human-system interaction, as “person’s perceptions and responses resulting from the use and/or anticipated use of a product, system or service”.
The common thread in all of these definitions is the interaction between a human being, a person, and a given system, inclusive of that person’s perceptions about the product. From a practical standpoint, what I’ve found over my years of experience as a user, as a developer, and as a business analyst, is that it’s a good idea to kick off scope definition and requirements gathering with a deep understanding of the product’s audience, or expected user base. If a team doesn’t start with that understanding, it makes it harder to scope the product correctly and target the highest priority features to achieve a shippable product increment.
Typically, one of the first steps in requirements gathering or in a Joint Application Design (JAD) session involves defining all of the expected users of the product or system. Once the expected users are well understood, a business analyst is able to categorize the general functions that those users might want to access in the system, and drill down to specific features that will allow those users to accomplish what they need to accomplish by using the system. Once each category of functionality is understood and the specific features start to crystallize, technical resources can start applying their expertise as to how those features can best be built and a coherent system design starts to emerge.
What does this mean for involving UX resources?
In my opinion, UX should be involved as early as possible, even as early as preliminary scope definition, even if your user experience expert is only sitting at the table to absorb the feedback coming out of product owners and business stakeholders. Business analysts should always process the input from stakeholders to generate a solid set of use cases and workflow diagrams to inform the job of the UX expert. However, developing a cohesive experience for different users is a highly organic process that depends on gaining insight into different users’ perceptions and expectations. When UX isn’t at the table early on, they have to play catch up at a later date, and try to rapidly absorb user needs so they can generate designs for the team to implement. The materials a business analyst generates to support that function are critical, but awareness early on in the process is just as key to providing the UX designer with the necessary context to not just design something within the desired timeframe, but design the system well.
Project managers and business analysts should bring UX designers in early and often and work very closely together in a collaborative and iterative way to ensure a common understanding of what the users need, so that the chances of delivering a successful first increment are as high as possible.