From HCI to Interaction Design

I just attended  a talk by Dr. Oli Mival; A professor at Edinburgh Napier University; which discusses in general sense the current HCI issues and how research is heading in the future. He also, discusses some of his project; especially ICE project.

Dr. Mival went over his big research project "Interactive Collaboration Environment (ICS)" which is an interactive meeting room designed to help in conducting a more engaging and effective meetings. He discussed design issues and obstacles that faced them when they started the project.  The idea of the meeting room is room equipped with different equipment's to enable participants in their meetings in better a way. The following is a list with what Mival indicated as a components in the ICE:

• Interactive multi touch large screen embedded in the meeting table, which can be controlled by different participants
• A control pannel can be connected with most of the common used devices
• Dropbox can be used to transfer files from and to the system
• Analog switch can turn on/off the whole system
• Three different cameras distributed around the meeting room to help when video conferencing with others
• Interactive touch screens placed on the walls for discussions which needs participants to stand and explain

One fact about this project, that I liked was the use of analog switch to turn on/off the system was a cleaver idea. I've been in the user shoe and I know how frustrated are users when they get around this type of systems.

Dr. Mival also indicated that spaces and places should be included in any user interface design. He closed his talk by indicating that now as the HCI research and industry is getting advanced, any further work in the interface design should consider all the following factors: people, places, activities, context.

Interesting facts and issues raised by Dr. Mival were:

• HCI and Interface design should adapt people tasks not the other way around. He gave an example about their ICE design, the multi-touch screen in the table was designed to handle mugs, laptops, etc in top of them. He mentioned that, you can't ask people not to bring coffee or tea in their meetings!
•  Hands wave gesture interfaces are not usable. Simply, user will get tired after a couple of minutes.

Here is a video about the ICE system. I thought it would be cool to share it with you:

Joint Application Development (JAD)/ Discovery Sessions

JAD session, is a meeting where analysts meet with all stakeholders in one room to identify the system requirements. It is similar to focus groups, except that in here all stakeholders brought together in one meeting to agree on system requirements. JAD session has a potential risk of undiscovered clashes. Typically, stakeholders with more power can resolve any disagreement in their favor (their point of view), so it is essential for analyst to understand that and to be aware of any potential risks.
JAD session is intended to capture requirements from multiple stakeholders. Additional tools may be used within JAD session to help in modeling requirements, and therefore help stakeholders to understand requirements being captured. Tools can be any modeling tools like: use-case diagrams, activity diagrams, etc. Brainstorming can be used on ambiguous points, also prototyping can be used.

According to our referenced book [3], a good JAD session should contain between 5-10 participants, but can go up to 15-20 if needed. Participants can be categorized under the following types:

• The Facilitator: is the person who will guide the session and controls it. According to [3], this is the most important type to the success of JAD session. A good facilitator would stop any unneeded discussion, and will make sure that session is working as planned. Some of the facilitator roles are as the follows: timekeeper, mediator of conflicts, coordinate different groups within the session (if any), summarizing discussions.
• Business Analyst: the one who manage session goals, and should explain to the facilitator the goals up front.
• Scribe: the person who take notes during the meeting.
• User (customer).
• Domain expert (subject matter expert): sometimes it is important to bring some expertise in certain technology or certain thing needed to enrich meetings.
• Developer: this will bridge the gap between developer and customer needs.
• Sponsor: OF COURSE
• Observer(s): if you need to train someone about JAD session, we would call them observers. Note, that an observer could be someone who have an interest in attending the JAD session but will be minimally engaged.

JAD session can be conducted in four simple steps as shown in the figure below[3]:

• Establish Goals and Objectives: explain meeting goals and objectives to the participants.
• Prepare for the Session: making sure that participants are there, everything is in place, and all the needed tools are there.
• Conduct the session.
• Follow-up: to complete the documentation. Also, by presenting the results to the sponsor, and following up any issues, or outstanding issues.

In case of any non-agreed upon points, small JAD session might be assigned to some members of a smaller JAD session. JAD sessions will provide a good support from users since they were involved in the sessions, however as any other meeting types, JAD session can end up in generating conflicts between participants which makes it harder to be resolved.

Observation (Job Shadowing)

Observation (or job shadowing) is an effective way to elicit requirements from an end-user point of view [3]. Through this technique, requirement engineer can define what are the steps needed to perform every user task. This can be in details, or in an abstract view (as needed). Our reference [3] indicated three methods to conduct observation (or job shadowing) as the following:

• Job shadowing: analyst will be at the user site, and interact with user to understand how he/she perform his tasks. The analyst note the needed actions for every task.
• Videos: if available video recording of user activities which explains how user perform his/her tasks. Analyst can perform the observation offsite. Also, it worth mentioning that this method saves time.
• one-way mirror-type setup: this type is in between the two above, analyst will observe a real time activities of a user on a medium; like live video camera (with user permission). The advantage here is to observe more than one user at a time.

Observation is a great technique to capture the current requirement or workflow, however it might have the following drawbacks:

• Sometimes, users tend to over act when they’re observed.
• Time consuming: Analyst may spend a lot of time to observe users.
• Analyst needs to be critical to ignore any user behavior outside the job being observed.

Interviews

Interviews [3]


Interviews is part of the Ethnographic Techniques, that I blogged about before. Here I will provide a detailed article about this technique.

Despite the fact that interviews are involved in any elicitation technique, what we’re discussing here is a stand-alone interview technique.
The basic form of interviews will aim to meet every stakeholder a one-to-one meeting to note his/her requirements, opinion, and assumptions about the system. This basic approach works handy when we have the following:

• Less disagreement between different stakeholders
• Stakeholders are geographically distributed and can’t meet togeather
• Some stakeholders can’t leave their workplace and engage in workshops and meetings

With the above in mind, it is important to keep the requirements shared between all stakeholders to eliminate any conflicts or disagreements. If any stakeholder disagree with requirements, then a formal walk-through would be needed with the disagreed stakeholder to verify and eliminate it.

Interviews can be categorized in two types as the following:

1. Open-ended interviews: requirements engineer (or interviewer) start the interview with an open-ended questions as the start point, the record the response and elaborate with stakeholder if needed. This type is useful when few we have few stakeholders, and when the interviewer is experienced.
2. Closed-ended interviews (Surveys): in this type, interviewer will design a survey; similar to survey technique; in which interviewer go on the survey questions by question with stakeholder and record the response. This type is beneficial when the interviewer is less experienced, and when we have many stakeholders (less time).

Interview process can be repeated until stakeholder understand and provide his/her best feedback. The following steps describes a good way to prepare an interview:

1. Keep in mind that you can’t interview all stakeholders, so use the stakeholders analysis to select the most important stakeholders (key users) to interview, then for each, identify a high-level goals for the interview; what you want to get from that interview; in which you will focus in the interview to capture a good requirements.
2. Schedule an appointment with stakeholders, and let them know how important are their feedback to the system.
3. Before meeting each stakeholder, learn something about their knowledge about the current system (or business workflow); and try to realize what area on the system they can provide a good feedback about.
4. Write some questions specified for every stakeholder according to their role and knowledge, and then refine the questions.
5. Send out the questions to the customer before meeting, so they can realize how important this meeting is, and how committed you are to the interview.

In addition to the above about preparation, a requirement engineer may use the following type of questions when designing an interview:

• Open-ended questions. When you want the customer (stakeholder) to express his/her opinion about some system process. This is also a useful technique to let the customer open up to you in an interview.
• Closed-ended questions. When you need precise and short answer from the customer.
• Probing questions. Used when you want the customer to elaborate about a requirement they mentioned. For example, if a customer said “ Our system should function 100% in our working hours ” , so you may ask “Can you specify what are the working hours?”.
• Validating questions. To go over requirements and models (i.e charts) and show them to customer and check their agreement, or disagreements.

The main point of interviews is to discover the unknowns. Reference [3] provides a step-by-step process to discover the unknowns throughout interview starting with the known. Steps are as the follows:

1. Interviewer should understand the problem boundaries and describe it using any method; [3] suggested using Functional Decomposition Diagram (FDD) see figure [3] below; then should explain it to the customer and make sure that customer understand it. This will help in bringing the customer in the same page.
2. Interviewer should define the problem being proposed to be solved here, either a system problem or a business problem.  
3. Identify the root causes for the problem being discussed. Interviewer need to be focus causes other than the main root cause which was already identified.
4. “Envision the future.” Discuss with customer what he/she and you think about the current situation (AS-IS) and what they think will be when this system is done (TO-BE).

At the end, interviews is a good elicitation technique, which provides an insight into details needed for good requirements. However, some customers may not be committed to those interviews, and sometimes its hard to control the interruptions in interviews.

Focus groups

Focus group is a structural guided meeting with sampled potential customers to determine their feedback about an upcoming product (or system) [2]. Typical session would take between an hour and two. Like brainstorming session, focus groups needs a moderator to lead the discussion about the product. To have a good results, the sampled group should represents the prospect users.

A business analysis book [2] suggested that the ideal focus group should contain between 6 to 12 people due to the non feasibility of large groups.

One major drawback of focus groups is that it depends heavily on the way moderator handles the groups discussion. People who participate might not share their true opinion when they discuss issues in the focus group.

Tabular Elicitation Techniques

In this category, we use tables to capture and note stakeholders requests to be met in the system. The nature of these technique makes it more precise and unambiguous. Two techniques under this category are widely used: decision tables and state tables.

A. Decision tables
According to [1], this technique is common tabular techniques. Rows  represent conditions, columns represents rules. This technique is useful when capturing business workflow or rules. One famous example is the tax tables [irs.gov], in the table rows are cases, while columns are conditions such as (single, marrid, etc). 



B. State tables
State tables is a technique that uses the idea of state machine (in computer science) to capture the process (or workflow). As state machines, only one start point is allowed, and one or more final state. Although book[1] classified this as elicitation techniques, I only can see this as modeling technique.

Quality Function Deployment (QFD) Method

QFD was developed by Mizuno and Akao in 1990. QFD goal is to identify customer needs to be translated into the product design. According to QFD Institute [http://www.qfdi.org/], QFD can do the following:

• Seeks customer needs spoken and unspoken.
• Discover qualities that impress the customer.
• Translate the above into design characteristics.
• Deliver product quality to achieve goals and customer satisfaction.

currently, QFD is often a part of Six sigma program[1].

Ethnographic Techniques (Surveys and Interviews)

Ethnographic Techniques are techniques originated from ethnographic research which focuses its effort on studying specific community or culture. The most common ways to conduct this type of elicitation techniques is through interviews and surveys. This method is very useful when studying large population where statistical analysis is used to represent the entire population.

Kano Modeling
Kano modeling is a survey model. According to [1] it is the most common survey method to analyze customer preferences in system features. Kano modeling has three variables: one-dimensional, expected, and attractive quality.

• One-dimensional (or linear quality) is when a system feature increases linearly with the potential customer value to the product. Example [1], in refrigerators, the more energy efficient, the more likely for customers to buy it.
• Expected quality is a feature that is essential to the successful of system.
• Attractive quality is a non required feature of the system, however if it was added it would give a good reason for users to use your system. Some attracted quality can be changed into expected with time, for example, cell phone camera used to be attracted but now its an expected feature.

One good fact about Kano modeling is that it is sensitive to the cultural differences. This means that values can change between different cultures and countries, and even states.

Surveys and interviews in general can capture the emotional and cultural responses and preferences to the end-users.

Note: Interviews technique is explained in this blog entry.

Brainstorming

Brainstorming Sessions are a common techniques to elicit stakeholders initial requirements for a system. Typical session would include many stakeholders to think and discuss the needed system together. This technique needs an experienced facilitator to manage discussions and conflicts between stakeholders. Typically, such sessions can take between one to two days [1,2].
Session time and duration should be agreed on before the start of the session. In the session, participants may start throwing ideas that they think are important to the product, facilitator can use sticky notes to note every idea on the board. The facilitator can use the following flow:

1. Allow everyone to bring up their ideas on the upcoming system (even if they're redundant).
2. group the ideas into different groups, and remove related ideas
3. assign ideas into categories with participants agreement (or the majority of them)
4. break brainstorming group into multiple groups to study in details each category.
5. in each group, ideas will be expanded and prioritize.
6. the meeting is concluded with the results being presented to the whole group and agreed on
7. If customer was not involved, further session might be needed.

The figure below gives an abstract view of the process:

Goal models

One important step in requirements elicitation is the identification of business goals [1]. This step can be ignored if not needed, however in most cases since business people are the driving force for software projects, their goals needs to be accommodated and put in mind when requirements are elicited. Goal modeling is a common techniques to elicit business goals. Goals can be break down into different levels. Typically, the higher level of goals would be more abstract and general, while lower level of goals would be more specific. In other words, the more levels you break goals, the more details you get. Goals can be conflicted with each other, thus once goals are collected it should be followed by a refinement step where those nonfunctional requirements can bring some important issues in regard to the system requirements. Goal model can be as simple or as complex as it needed. No standard for the level of details, it just the current need drive the modeling.
Another approach to use goal model is to use it along with quality assessment methods (QAMs). QAMs are used to identify identify the quality goals that meets business goals. The goal behind using QAMs with goals models is to make sure that important nonfunctional requirements are not missed. Also, to make sure that nonfunctional requirements can be tested.

The following figure contain a simple example of a simple goal model

Requirements elicitation

requirements elicitation: is the process of identifying and understanding the needs and constraints for a system that can be transformed into manageable requirements that meets stakeholders expectations [1].

Elicitation is sometimes confused with the analysis. Elicitation is to interact with stakeholders to write down their needs, while in the analysis, requirements are refined to meet stakeholders expected needs into more formal refined specification [1].

I will write different blog posts about different elicitation techniques. I've used the following sources books:
[1] Berenbach, Brian, Daniel J. Paulish, Juergen Kazmeier, and Arnold Rudorfer. "Chapter 3 - Eliciting Requirements". Software & Systems Requirements Engineering: In Practice. McGraw-Hill/Osborne. © 2009.
[2] Weese, Susan, and Terri Wagner. CBAP/CCBA: Certified Business Analysis Study Guide. Sybex. © 2011.
[3] Jonasson, Hans. "Chapter 7 - Ways to Gather Requirements". Determining Project Requirements. Auerbach Publications. © 2008.

I will refer to each source with its number between brackets.