There is a great wave of projects and programs involved in creating engaging experiences for customers, all lacking the essential component of User Requirements.
Market requirements, Business requirements, Technology requirements and User Requirements become Project Requirements
Project requirements on a project with a UX focus are formed by an amalgamation of business requirements and user requirements that become guidance to technology requirements and are driven by market requirements.
Just as business requirements are captured from the business, user requirements are captured from the users. User requirements that come from the business are KPI’s and should only be success and effectiveness measures not drivers of experiences themselves. This is a common area of failure in projects, hearing the statement “we are all users” is a clear indication of impending failure, due to complacency and incompetence.
Gathering User Requirements
The processes for gathering user requirements have a similarity to those employed in gathering business requirements except there is a higher degree of analytical rigor required to avoid tangental solutions based upon outlier opinions.
Getting the requirements right
It is an understood factor in travel that if the journey starts even half a degree wrong then the final destination will be considerably different from where the person intended to be, this is for many why there is a make do culture when working with technology requirements. Unfortunately bad requirements gathering can seriously derail a project before it really begins.
There are several types of requirements gathering research that are carried out as separate work streams.
- Market requirements which includes competitor analysis and proof of concept.
- Business requirements, including business stakeholder perceptions and business KPI’s.
- Technology requirements often described as non functional requirements, including existing capabilities (hardware, software and skill base) and comparable technologies.
- User experience requirements which include behaviour research, KPI’s, perception research and interpretation for the specific project domain.
One of the key things to understand is that the structure and implementation of requirements gathering in each type is different even if some methods may appear the same, their interpretation and output are not. Additionally in user experience the method of interpretation and output are user centric rather than business centric. I find user stories a very helpful output method as it maintains user goals in a structured format that can be reused in the development process.
Global Aid Organization – Case study 1
In a recent project the client requested assistance in setting up the requirements gathering process, they were intending on having groups of people from the same department together. One of the key things to understand in structuring research is the possible points at which the data can be skewed and therefore become less valid. It is human nature in a group for people to temper what is said if senior staff is present.
Instead of running the requirements gathering along department lines it was defined by stakeholder roles;
- Senior managers (strategic high level thinkers)
- Managers (project capability thinkers)
- Production (detailed problem solving thinkers)
- External users (frustrated users with wide subject based experience)
- External consultants (cutting edge thinkers with wide subject based experience) as a design panel
There was also screening documents for participant selection for each role in order to assist in defining effectual research methods. Participants were sent an overview prior to sessions so that they would understand what was going to happen at very general level. In parallel an external agency was commissioned to research market requirements in the same domain and in a comparable domain. A technology audit was also carried out to support the technology requirements component.
Global Publishing Organization – Case study 2
In another project where the client was intending the project to effect change in multiple countries and markets requirements gathering research was conducted in several countries. The United Kingdom was used as a baseline country with adaptations defined through in person and remote research for Eastern Europe, Western Europe, USA, South America and South East Asia.
People focused requirements
Capturing requirements is subject to other peoples availability, this remains one of the most time consuming 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 gathering 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 for the final project as it maintains communication lines and project transparency.
Screening participants is critical in order the understand the importance to place upon their opinions.
All opinions are valid for the person giving them, just not all opinions should have high impact on the project.
Creating a participant profile for systems with internal or external users
There are several key questions that the facilitator needs to ask themselves when preparing to gather requirements.
- 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.
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.
People who are not part of the business and who will use the system or product being created also need to be screened so that they a representative of real users.
Eliciting user requirements
There are lots ways to elicit user 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 dependent 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.
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 an event 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, 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.
Government National Project – Case Study 3
On a national 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.