#UX #requirements #gathering methods #determine #value

Requirements gathering methods determine value

There are lots ways to elicit UCD requirements so I don’t intend on listing them all here, what I will note are some of the effective ways that I utilise. They can be described as structured, unstructured or a mixture of the two, but importantly the methods produce differing depth of requirements dependant not only on the method but on the skill of the facilitator and the characteristics of physical location used. In effect the method used is limited by the capability of the facilitator.

Research Structure

It is critical to determine if there is enough usable information around the project to be able to establish a valid research start point. Get the questions right and the answers follow, get the questions wrong and you’ll waste a fortune. If your unsure carry out a pilot study to find out what the questions are.


Observational / Reflective

Asking users to carry out their normal activities while being observed does take quite a bit of setting up so that the activity data is not skewed as a result of the observation. It is critical not to participate or lead the user. It is especially common when users are told the fine detail about the project; they will try to give you what they think you want. Often this is because they feel threatened by the process, the old notion of time and motion leading to them getting sacked is embedded in British culture. However this type of method is very useful in a pilot study to determine what type of activities should form the basis of questioning or workshop based co-creation.


Narrative is about stories, like the narrator in a play, they see the whole thing being able to talk in the present, remind of the past, note the future or describe a similie that others can relate to even if they cannot yet relate to the main story.

Asking users to describe how they think something should work (Cognitive Walkthrough), what the differences might be for different user types, how it’s done now, is there anything in other technology or experience that they can relate it to. In this way a multi-path picture can be built up from each participant for each interactive pathway within the new system or technology.


Diagnostic is about testing something this will often manifest through workshops with groups of people. By setting a group a task or co-creation ‘Design the front page of your new website’ spending ‘K10,000,000 that’s Karl’s currency’ on to meet your goals and noting the group dynamic, decision making and outputs, very rich information is revealed by participants.

Show and Tell

Show and tell is imperative to feed back to participants what has happened to the information they have provided. More it can be used to validate key concepts and project directions in a fairly light environment, where participants can be highly critical knowing that everyone else is in the same frame of reference for that meeting.

Some of the Problems

Although the whole process exists to elicit information suitable to influence the project, some participants will have pet requirements that if not given the correct level of sycophantic response they will seek to invalidate the entire project as it does not represent their vision of what the project is any more. This type of attitude is very common when working with low pay low (self) risk bureaucrats, as they can personally destroy projects then blame it on ‘expensive’ consultants.

Case Study 4

On a national census project that was due to be run online and offline a member of the bureaucratic project team insisted that their opinions were correct on the basis of having won an award for a website ten years earlier. The opinions were very dated to the point of being bad practice, incorrect and were a constant disabler to the project. This client refused to consider an open support system, marketing website (to prepare country) or full language landing pages to support the full ethnic background of the country in question. The day to day engagement was painful, but the UX for the several forms, question logic and user interactions were eventually signed off even though the client never signed off the personas based upon the requirements they gave.

Tagged : / / / / / / / / / / / / /

#UX #Requirements #gathering #preparation

People focused Requirements

Capturing requirements is subject to other peoples availability, this remains one of the most painful parts of the process as few participants seem to understand just how important their experience is to the project. Often a participant can shape the final output without realising they have done so, I include a Show and Tell component to requirements research as it informs participants that the information provided is important, has been used and is affecting the whole project. Additionally Show and Tell is critical to validation and creating buy in. I will post more about Show and Tell later.

Screening Participants

Creating a participant profile

There are several key questions that the facilitator needs to ask themselves when preparing to do research;

  • What do I need to know?
  • How will I cross relate requirements sessions?
  • Does this domain have it’s own rule system?
  • Does this domain have it’s own language and is it inclusive or exclusive?

The participant profile needs to represent the answers to the above questions, a good place to look for participants is senior managers (not directors) as they still have direct reports from the bleeding edge of business but have gained a level of strategic understanding both for their area and the ebb and flow of internal politics. Dependant upon the project type an understanding of the their knowledge base (within the business or organisation) is required as it determines the weight their views should carry. Other significant factors include; length of service (often describes personal drivers), education background and level, attitudes and behaviour (tend to be observational by selectors) and social / business importance.

Selecting participants

There is a huge amount of internal politics involved in projects and often unsuitable participants are forced on projects, often as internal staff have failed to create buy in internally. I tend to work with a selection group of two to three internal people to help me understand the value each participant add to the project or the threats and risks associated with their internal agendas.

Case Study 3

I was involved with a offshore wealth management (HNW and UHNW) companies major project as a UX consultant for a new truly complex asset trading and policy construction system (a type of which I had completed before as an Enterprise Solutions Architect). I had requested but never received a profile of each participant as they had been pre-selected by the client. I had spent several days meeting people with valuable hands on experience and then I was put into an office with a Director of Sales who after 10 minutes showed an obvious controlling agenda stating “they work for me” when describing several staff members (who incidentally did not work for her). I completed the requirements gathering process and found that the Director of Sales requested other staff in the agency to work on the project. The agency involved had no specific experience in this type of system so had acquired my services specifically to work on this project. I understand they are now on to their third UX person on this project since I left, frankly the project is not standard UX and they are in deep trouble. On my side I was stunned but still think it’s one of the funniest experiences I have had working with people.

In short if your standard preparation methods have been circumvented by your clients it is a clear indication that there are problems now and will be problems on the project in the future.

Tagged : / / / / / / / / /