A Good User Experience Starts with Excellent Requirements
In "Don't Hope for a Happy UX—Build One Yourself," Noel Wurst highlights the importance of engaging the customer/end-user early in website and e-commerce projects. He correctly points out that early client engagement enables developers to create a user interface that works the first time, rather than having to subsequently spend time, effort, and money fixing a broken user interface.
I completely agree with Noel's points. I'm sure we've all experienced situations and systems where we've been subjected to a bad user experience, and this can certainly be extremely frustrating.
The ideal and best place for user engagement to start in projects is early in the requirements elicitation and analysis cycle—before design commences. One real challenge, however, can be the separation of the actual end user from the client representative—they can often be different people. When talking about business systems and IT software, it is not always the subject matter experts who ultimately will be using the solution that is being specified. It’s even less likely to be the project sponsor.
The actual end user might be a front-line call center worker, a customer, or even a worker in another organization—and these stakeholders might not be formally involved in the project at all. To make things even more complex, there may be different users—with competing goals and different worldviews.
This is a large subject area, but there are two key techniques worthy of consideration.
First, the technique of stakeholder identification, categorization, and management is critical. It’s extremely important to understand which stakeholders will be using the business system that is being developed/changed, which stakeholder groups rely on its outputs, and who has an interest in or influence over the system. Early identification of stakeholders means that they can be engaged and their requirements—including their user experience preferences and needs—can be better considered.
Second, process identification and modeling is extremely important. Building a simple user interface is made much more difficult when the underlying business process is unnecessarily complex; it’s therefore important to simplify business processes before you automate.
It’s important to understand the triggers that lead to users starting a business process and the ultimate output they are trying to obtain or achieve. Keeping processes at a logical (rather than physical) level provides designers with more flexibility in how to implement them. This also prevents locking in unnecessary design constraints too early.
These are clearly just two considerations. It is also key to consider data requirements, functional and of course non-functional requirements, among other requirement types, too. Good user experience starts with good requirements, and keeping requirements logical and solution-agnostic early on prevents building in unnecessary design constraints. Understanding the stakeholder and process landscape is important.
