This question hasn’t bothered me more in my career than in recent times after I went through an online UX course. So in UX parlance, what would be considered as a reasonable vocabulary — is it gathering of the requirements or is it generating of the requirements? Designers ought to comprehend user needs and generate feasible ideas for the real world, so clearly, it’s the connotation of the word ‘gathering’ which is at conflict here more than the approach itself.
According to the information given on his website, Joe Natoli is a speaker on topics of User Experience (UX) and Design for 29 years, from national and global conferences, and has launched eight successful online courses. Two of which I happened to reflect upon on Udemy a few weeks ago and both were insightful at the very least. However, it was his differentiation and comparison of requirements gathering versus requirements generating in both the courses that made me unusually inquisitive about the synonymous terms. It’s also purely language semantics at play here as I explain in detail below. But first, this is Joe’s take on the point in question from the UX Strategy Fundamentals course:
I want you to know about requirements up front (which) comes from a very smart lady by the name of Kim Goodwin who said that requirements cannot be gathered. OK this is important because I hear that phrase a lot (and) in the last 26 years I’ve heard it more times than I can count. We’re going to gather requirements which essentially means we’re going to get a bunch of people in a room and they’re going to tell us what they need and we’re going to write them down. We’re gathering from them. OK. It does not work that way. And if it does it’s not going to be successful. As she says there’s no requirements tree back. We’re not going to go pick requirements off the tree or any one of these and this one looks particularly good. I think we’ll do that. It doesn’t work that way. You have to iterate and generate requirements you have to kick them around and decide what’s right what matters what doesn’t matter what can work what isn’t going to work. It’s a process. It’s not an answer. You need to find out what users need to be able to do with your website in terms of functionality in terms of the content that they see and interact with in terms of data if they fill out a form and give you information or they look at reporting where they get data and information.
UX Strategy Fundamentals → Section 4: Determining and Controlling Project Scope – Lecture 17. UX Focused Requirements: An Introduction.
There’s a rather simple approach of looking at the use of the term ‘gathering’ and ‘generating‘. For instance, in a client-vendor partnership the requirements have already been generated so to speak at a much higher-level and received through an RFP (request for proposal) outlining those exact areas which require UX skills for mitigation. The vendor/designer/dev teams assemble to understand those requirements during the drafting of a proposal — in this case the term ‘gathering’ is used synonymously to signify ‘comprehension’ and should not to be confused with the act of collecting data or information. In summary, without the client submitting project requirements and without the third-party vendor assembling a team to study those requirements for a clear and comprehensive perspective it’s impractical to create a proposal or a process to move forward with the discussion on how UX could even help in solving the problems. The scenario becomes less complicated if it’s an internal design team in which designers have easy access and awareness of the requirements given the backdrop of their training and orientation within the organization. Yet there’s no harm in seeking clarification through the 4-step process which I’ve outlined below.
Nonetheless it’s important to keep in mind that UX is not a compartmented function and its future outcome is based upon enforcing the process of consolidating data, ideas and other elements from key stakeholder areas such as branding & marketing, sales, technology, etc., with each having a profound influence through a requirement or a constraint that must be factored in to build the final product. Although the RFP or other documents might state a general requirement for UX design it’s up to the designer to interpret those requirements into a concrete process correlating to the relevant tools and techniques — over here the term gathering relates to building ‘familiarity’ with the otherwise recognized or latent business and user needs and converting them into actual actionable items or business opportunities for the client and the vendor. It’s a matter of language semantics more than a technical misrepresentation of the word ‘gathering’ in my opinion.
Here’s a simple, yet a practical framework for the gathering (comprehending) of requirements that I have followed over the years and implemented during my projects —
- Contrary to popular notions, the so called ‘requirements’ or practical information for creating a successful digital strategy does not come packaged in a dossier, in fact its scattered within several key documents, like within corporate data such as brochures, annual reports, internal magazines, etc., in the company vision/mission/values statements and corporate branding guidelines, through online or intranet research, and so on, and one has to read or listen to the requirements to make appropriate notes to begin with — so at times, I’ve received tons of data which is dubbed as “requirements” but it would be inconsequential to the goals of the project. While in some cases, I have had to hunt down appropriate information as part of my user research strategy to connect with the core ideas of the project, and filter through each of these data sources to reach definitive conclusions and insights.
- The next crucial step is to summarize the data into practical requirements by understanding the conditions as well as the constraints that might challenge the practicality of the working solution in the long run, it’s also about making sense of what the business objectives are, who the users are, how is the product going to be used in certain environments, and relate all the insights to the user needs in simple terms.
- If I have doubts regarding the insights from those requirements or if I’ve noticed something untoward I would add it to a list of questions and reach out to the relevant leads from marketing, sales, design or IT departments, and seek a comprehensive clarification. It’s even more beneficial for me to have the leads participate in a focus group meeting together and have a discussion on the possibilities, the technology limitations, and what could be eliminated from the list of objectives in order to fine tune the deliverable. But mind you, even at a systemic level, despite my insightful participation I’m not generating any requirements. There are a bunch of discrepancies as I pointed out which I’m trying to uncover as well as overcome and I’m simply stretching my level of understanding by eliminating the ‘scope creeps’ and what’s not possible to do at this stage. As Steve Jobs said, and I quote, “Deciding what not to do is as important as deciding what to do.”
- Last but not the least, my summation of the requirements are presented to the participating team members through a ‘Scoping’ document. In that, there are references to the UX tools & techniques which would be implemented based on the time frame required to finish the work in phases. This document also outlines the relevant touch-points, the KPIs, the list of deliverables and relevant milestones for the entire duration of the UX project.
Next comes the ideation phase which is crucial for the success of the entire UX initiative, in that the designers provide the first visual clues of the summation of the requirements through rapid prototypes or sketches for a quick review and feedback. However, the 4 steps which I have highlighted above alone constitute the ‘requirements gathering’ phase, i.e., figuring out what exactly are the challenges and what needs to be done in order to mitigate the issues through research, open-ended questions, focus groups and interviews. Nowhere in those 4-steps are the requirements ready to be ‘plucked from a tree’ and neither are you responsible for generating any requirements. There are no ‘ready-to-eat’ meals available and your job as a UX designer is to generate practicable, user-centric concepts and ideas which relate to the customer’s business goals. Furthermore, your design solutions are only as usable and delightful as the depth of your research so comprehending those requirements and empathizing with the audience is a means to the end and one must make the most of this opportunity. Now if by any chance, you find yourself ‘generating’ UX requirements, then you probably entered the wrong meeting room, or you got invited to a ‘think tank’ session.
