Requirements Gathering Workshop
According to Jenny Preece and Helen Sharp, in their book Interaction Design: Beyond Human-Computer Interaction , data gathering can be done using the following conventional techniques:
Interviews: Interviews are good for getting people to explore issues. Semi-structured or unstructured interviews are often used early on to elicit scenarios. In the context of establishing requirements, it is equally important for development team members to meet stakeholders and for users to feel involved. This on its own may be sufficient motivation to arrange interviews.
Focus Groups: Focus groups are ideal for establishing a consensus view and highlighting areas of conflict and disagreement during the requirements activity. On a social level it also helps for stakeholders to meet designers and each other, and to express their views in public. It is not uncommon for one set of stakeholders to be unaware that their understanding of an issue or a process is different from another’s even though they are in the same organization.
Questionnaires: Questionnaires may be used for getting initial responses that can then be analyzed to choose people to interview or to get a wider perspective on particular issues that have arisen elsewhere. Or the questionnaire might be used to get opinions and views about specific suggestions for the kind of help that would be most appreciated.
Direct Observation: Observation of participants in their natural setting is used to understand the nature of the tasks and the context in which they are performed. Sometimes the observation is carried out by trained observers who record their findings and report them back to the design team, and sometimes the observation is carried out by or with a member of the design team.
Indirect Observation: Diaries and interaction logging are used less often within the requirements activity. Interaction logging on an existing system may be used to provide some data about how a task is performed currently, but the information is too tightly coupled with details of the existing computer support to be particularly helpful if a completely new system is planned.
Studying Documentation: Manuals and other documentation are a good source of data about the steps involved in an activity and any regulations governing a task. Such documentation should not be used as the only source, however, as everyday practices may augment them and may have been devised by those concerned to make the procedures work in a practical setting. Taking a user-centred view of development means that we are interested in the everyday practices rather than an idealized account.
Researching Similar Products: By observing and analyzing similar products, it is very easy to establish the requirements of your own product
So, which data-gathering technique should you choose? There is no right or wrong answer here. The above techniques have their own pros and cons. For example, interviews are ideal in order to gather data from smaller groups while questionnaires are ideal to gather data from a geographically spread user base. Other forces that come into play are the nature of the task, the participants, the analyst, the resources that are available and a multitude of other factors. Thus, you may find yourself combining more than one of the above techniques in order to be able to interpret data that is unclear.
At Unii.com we organised x2 Requirements Gathering Workshops with the Presidents of University Financial Universities. In the following blog I will review why we identified ‘Presidents of University Financial Universities’ as our target user and the process of planning, executing and concluding a requirements gathering workshop.
User Requirements Workshop
The process of planning and executing a UX workshop has six steps, beginning with understanding the purpose—or high-level goal of the workshop—and ending with a course of action taken based on the results produced by the workshop.
1. Articulate the goal(s).
When crafting a goal statement, consider what the tangible output is that should be produced by the workshop, and write a short, clear description of the ideal end state. This statement will guide your agenda creation, ensuring that every segment is guiding towards that end state. Usually, end states fall into one or more common categories, such as:
Agreement: Consensus on direction
Understanding: Shared deeper knowledge of a subject
Generation: Creation of new ideas or thought patterns
Strengthening: Building empathy between teams or strengthening relationships between parties
2. Document what information you need in the form of questions.
Typically, there is a gap between your current state and the goal state you have just articulated. You need crucial missing information in order to move yourself and the team toward that goal. What are those missing pieces of information? Ask yourself, “What questions must be answered in order for me to move toward my end-state goal?” and document those questions. Questions may be quite specific or broad. Some examples:
Who is our audience?
What defines the ideal user experience?
What is the current state?
What kind of metrics will be used to measure success?
What user research do we have at our disposal, and what needs to be conducted?
What potential roadblocks exist?
Once documented, most likely there will be themes and patterns within these questions that can be grouped into segments; these segments will start to create a structure for the workshop.
3. Align processes to groups of questions.
The third step, and the last step in planning, before actually conducting the workshop, is composed of selecting workshop activities or discussions that align to each theme that emerged within the questions. At this point reflect on what types of processes — group activities or discussions — will help the group move toward answering the specific questions. Some examples:
If you need to help a group move toward consensus, you might choose a forced ranking or prioritization exercise, like dot voting.
If you need to generate new ideas quickly, you might choose a brainwriting activity, a post-it notes exercise, or some other form of brainstorming.
If you simply need to understand what research is available across the organization, you might have different groups do short readouts of pertinent findings.
4. Conduct the workshop.
The previous three steps of planning will adequately prepare you to guide the discussion, and understand if unplanned discussions that pop up are off-topic or meaningful tangents. Furthermore, once the outputs of the first three steps are translated into a formalised, shareable agenda, attendees will have a better understanding of the day’s goals when they can see where they are within the whole span of the workshop.
Analysing the information
Although it is dependent on the techniques you have used for gathering user data, more often than not, you will have a large volume of data to analyse. At this stage, I would suggest using statistical techniques in order to group data into more manageable chunks. Such chunks would be easier to analyse and hence extract from them certain traits.
It is recommended that this step is then sub-divided into 4 sub-steps. Each sub-step is a more detailed view of the previous step:
1. User Groups
Using the data that you have gathered, you can start building your user groups. As the name implies, user groups are groups of users who share similar characteristics. They are not specific users. These characteristics typically fall into 3 categories:
Personal: e.g. age range, gender and capacities
Academic: e.g. education, certification and computer experience
Attitudes: Attitudes towards the job and the task
The best way to represent user groups is using a grid as shown below. The actual characteristics in the grid can be added or removed, depending on how much you think that they are beneficial to identify a user group.
A grid which can be used to model each user group (Source: University of Hertfordshire)
Interestingly enough, the second column already helps in shedding some light on the requirement that the system must have in order to cater for the needs of entire user groups. For example if the visual capacities of your user group is typically 3% less than what normal users see (because of the age within the user group), then the requirement would be that the system needs to have large fonts and high contrast. Had the visual capacity been a range from 0% loss to 3% loss, then the requirement would have been that the system must have a facility to increase the font size and the contrast.
2 Personas
Invented by Cooper in 1994, personas are fictitious users that act as stand-ins for real users in order to identify their motivations, expectations and goals that drive their online behaviour. There are several advantages of using personas. First of all, they inspire lateral thought and exploration when building them.
A set of three personas who represent different types of users for a night beacon (Source: Taehok.com)
For example imagine you have stated in your user group that your users typically hold managerial and executive roles. When creating the persona of Mr. Bob, you would think about what type of car Mr. Bob drives and what hobbies he might have. In its role of specifying a user that falls within a user group, personas help in filling in holes that were previously unexplored. In addition to this, personas are less abstract and hence easier to use for communication purposes. They are also more manageable than thinking about an entire user group. Finally, and most importantly, personas will help you develop a system that users need (to help them achieve their goals) rather than developing a system that the users want.
While there is no strict framework for personas, at their very minimum they should contain:
A name
A photo
Demographics (age, sex, etc.)
A descriptive paragraph
Needs, goals and features
Other pieces of information that one may include are: a quote from the persona, frustrations, ideal features, need to know and behaviors.
A more complex example of a persona (Source: ChristinePoh)
3 Scenarios
Once you have developed your persona, place him or her in a scenario. A scenario is a narrative which describes how a user might interact with your system. Since there are several tasks that a user will undertake when interacting with your website or system, it is advisable to list those tasks and then create a scenario for each. In this way the scenarios would be more specific and more manageable.
Suppose that you have an e-commerce website from which you sell mobile phones and in Step 2 you have created a persona called Bob who is a 19-year old student who likes gadgets and would like to buy a phone but is on a tight budget etc. etc. In the scenario, you will put Bob in several “stories” based on the objectives that he would like to achieve when using your website. So, you might create a scenario in which Bob wants to achieve these objectives:
Searching for a mobile phone for his budget
Comparing the features of two different mobile phones
Purchasing a mobile phone
The following are some examples of scenarios:
Scenario Example 1 – A customer withdrawing money from an automated teller machine (ATM): It’s Friday afternoon and Joe is flying to Sydney. He doesn’t have enough money for a taxi to the airport, and he’s running late. He goes to the local ATM and identifies himself. He specifies that he wants $100 from his savings account. He’d like the money in $20 notes so that he can give the taxi driver the correct change. He doesn’t want a printed receipt, as he doesn’t bother keeping track of transactions in this account. (Source: Infodesign.com)
Scenario Example 2 – Changing an employee’s job title: Hanna Reed-Smith, Human Resources Specialist, receives an email request to change Josh Anderson’s job title from Personal Lines Analyst to Personal Lines Manager.
Action: She opens HRWeb and clicks on Search for Employee. Hanna then uses the task bar buttons to get back to her e-mail to get Josh’s employee number from his e-mail message. She uses the mouse to highlight the number, copy it, go back to hr Web, paste the number in the Employee ID field, and activate the Search button. She clicks on Employment Information. (Source: UI Access.com)
4 Task Analysis
The next step is to use each scenario to list the tasks that the user needs to perform in each. There are various techniques that one can use. My personal favourite is Hierarchical Task Analysis (HTA). UX Matters defines Hierarchical Task Analysis as a structured, objective approach to describing users’ performance of tasks, hierarchical task analysis originated in human factors. The advantages of using hierarchical task analysis is that it facilitates the:
Comparison of different approaches for achieving the same objectives
Understanding of how a system works
Reusability of user experience design
Generating Requirements
Functional requirements should be defined in the following way:
Requirement: The name of the requirement
Number: A unique number that identifies the requirement. Ideal for communication purposes
Description: A short description of the requirement
Rationale: The reason why this requirement is needed
Success criteria: What determines that this requirement has been well implemented
Level of importance: The importance of this requirement for prioritisation purposes. Usually a number between 1 and 5
This step is performed for each task until you have a list of functional and non-functional requirements for the entire system.