The User Interface:Establishing User Interfaces

The User Interface

Establishing User Interfaces

The success factors in analysis start with the established interfaces from day one. What does this mean? You must start the process by meeting with the right people in the organization. In the best projects, the process is as follows:

1. Executive interface: There needs to be an executive-level supporter of the project. Without such a supporter, you risk not being able to keep the project on schedule. Most important, you need a supporter for the political issues that you may need to handle during the project (discussed in detail later). The executive supporter, sometimes known as a sponsor (JAD reference), should provide a preliminary schedule advising the organization of what is expected and the objectives of the project. The executive supporter should attach a letter to the preliminary schedule and send it to the project team members. The letter must put the importance of the project into perspective. Therefore, it is strongly recommended that you draft this letter yourself or at least have influence over its content, since doing so can ensure that the message is delivered appropriately. The executive supporter should also establish regular reviews with the analyst and the user community to ensure that objectives are being met.

2. Department head or line manager interface: If appropriate, the department head should provide guidance about which individuals should represent the department needs. If several people are involved, the analyst should consider a JAD-like approach. Depending on the size of the organization, the department head might also establish review sessions to ensure compliance.

3. Functional user interface: Perhaps the most important people are the ones who can provide the step-by-step needs of the system. Figure 3.1 shows a typical organization interface structure.

Forming an Interview Approach

Your primary mission as an analyst or systems designer is to extract the physical requirements of the users and convert each to its logical equivalent (see Chapter 4 for a full discussion of the concept of the logical equivalent). The most critical

Figure 3.1 Established interface layers.

step in this mission is the actual interview, in which you must establish a rapport with the user(s) that will facilitate your obtaining the information you need. Your approach will dramatically change based on the level and category of the individual being interviewed. Therefore, prior to meeting with any user, it is critical to understand the culture of the company, its past experiences with automation, and most important its organizational structure.

The following five-step procedure will help guide you more smoothly through the interview process.

Step 1: Get The Organization Chart

Few things are more useful in understanding the chain of command and areas of responsibility than the organization chart. Depending on the size of the enterprise and the scope of the project, the organization chart should start at the executive supporter level and work down to the operational users.

Step 2: Understand Everyone’s Role in the Organization Chart

If there are any individuals not involved in the project who should be, given their position in the organization, first ask why and then make a notation for yourself that they are not to be included. Management may assume an individual or role should not be included and may often overlook their importance. Do not be afraid to ask why a person is not deemed necessary for the analysis of the system, and determine if you are satisfied with the reasons for their exclusion. Remember, you can still control and change the approach at this point, and management will probably respect you for doing so.

Step 3: Assume the Situation Is Political

Be sure you understand the personalities with which you will have to deal. In almost any implementation, politics among people becomes part of the process. To ignore its existence—and the constraints it is likely to impose—is to invite

failure. The question is how to obtain information about internal politics. The best approach is to start as high up in the organization as possible, typically at the executive supporter level. You might be surprised at the amount of information they have. Of course, you should not explicitly ask about the politics but rather phrase your question as follows: “Can you give me some perspective on potential department and personnel conflicts that may occur during the interview cycle and that I should be aware of?” You may not always get the answer you need, but if you keep asking the question during every interview, you will discover a great deal about the way the organization functions. And remember, only people make projects complex!

Step 4: Obtain Information About User Skill Sets

Starting an interview without knowledge of the user’s technical skills puts the analyst at a huge disadvantage. Having this information will allow you to formulate a plan of questions and to determine the best approach to the interview. If the user has no knowledge, the questions should be tailored to include a minimum of technical content. The following guidelines for preparing for inter- views reflect a common sense approach, yet it is amazing how many analysts fail even to consider such strategies!

1. Gather information before the session to allow the user—as well as yourself—to be prepared and to give you both a much clearer under- standing of what will be covered during the interview.

2. Develop a questionnaire. Technical questions should be phrased differently depending on the level of knowledge the user possesses.

3. Determine whether the interview will provide enough input to obtain the necessary information. This is not always the case; however, it happens more often than you might think. Understanding user capabilities before the interview may not only change the scope of the meeting but also suggest who, in addition to the user, should attend the interview.

Step 5: Arrange for a Pre-Meeting with the User

A pre-meeting may not always be possible. In any case it must be a short meeting, perhaps half an hour. The session should be designed to be high-level and provide a general idea of what will be covered during the actual interview. But more important, it will allow you to get a snapshot of the user. You might say you are obtaining a “comfort level” (or “discomfort level”) for that user, and such meetings can provide you with an idea of what to expect and how to finalize your approach. What do you look for? Here is some direction.

1. The pre-meeting should give you enough feedback to place or confirm the user’s technical level.

2. Look at everything in the user’s office or his or her environment. Is it sloppy? Is it tidy and organized? The state of the user’s environment will often be consistent with the way he or she provides information. The insight you gain from observing the environment should give you guidance about the types of questions to ask this individual.

3. Look for signs of attitude. The user’s level of interest should be evident.

Does he or she view the upcoming session as a waste of time, or is he or she excited about the meeting?

The information gleaned in the pre-meeting can provide you with helpful hints about what to expect from the interview and from the user in general.

Dealing with Political Factions

The importance of internal politics at the user’s site should never be underestimated. Perhaps the most common question raised by both professionals and student analysts is how to provide quality analysis when office politics get in the way. Here are some guidelines.

1. First, assess whether you are in the no-win scenario. Many of us hate to admit that the no-win scenario does indeed exist in many environments, but you should be on the lookout for the signs. If your manager will not support you, if the company is underpaying you, if the users hate you, if there are no automated tools to do the analysis, and if upper management doesn’t care, then you are in a difficult position. If you cannot change the situation, you must inform management that the results of your analysis will be significantly impaired by the lack of support and tools to complete the project properly. The techniques offered in this book assume that all parties are interested in providing the best solution possible, not in providing a system that is barely adequate.

2. On the other hand, do not be too quick to assume that you are in the no-win scenario. Most politically hampered projects need some strategy to get them on course, and most problems can be overcome if you know how to approach them. Here is a typical example of such a problem and some ideas you can apply to solve it.

Problem

The users who currently operate the system won’t talk to me. They are afraid either that the new system might replace them or that their jobs will significantly change. In short, they fear change.

Categories and Levels of Users

Establishing user interfaces represents the vehicle to formulate much of the interview approach. It is necessary, however, to go further into the characteristics of the people particularly with respect to the category and level they have within the organization. Figure 3.1 established the three general categories, called executive, department head or line manager, and functional. It is important to explore their characteristics. In order that we better understand each category, I have always asked the following question: What would be their interest in the success of the project, that is, what would make them happy with the new system? Let’s apply this question for each user category.

1. Executive users: Individuals at this layer are most interested in the concept of return on investment (ROI). ROI basically focuses on whether an investment will provide a financial return that makes the effort worthwhile to the organization. While there are many comprehensive formulas that are often applied to the study of ROI, our context pertains to the short- and long-term benefits of investing in building new software. There are generally five reasons why executives agree to fund software development. They are listed in order of significance to the investor.

a. Monetary return: Simply put, this means that the software will generate dollar revenue. An example might be the Internet software that supports on-line ordering systems such as Amazon has for book shipments. Their system not only provides the functionality to handle shipments, but provides a Web interface that can be directly associated with revenues provided by book orders through the Internet.

b. Increased productivity: Many software systems are unable to demonstrate direct monetary benefits. However, many of them are developed to increase productivity. This means that the system will allow organizations to actually produce and deliver more. Thus, the system allows the organization to derive higher revenues through increased productivity of its resources.

c. Reducing costs: Software projects are approved so that organizations can reduce their existing overhead costs. This typically relates to the replacement of manual activities with computer ones. While reducing costs appears to be similar in nature to increasing productivity, they are often implemented for different reasons. Increased productivity usually relates to organizations that are growing and are looking for ways to improve output because of very high demand. Reducing costs, on the other hand, can represent a defensive measure, where an organization is seeking to find ways to cut costs because of a shrinking market.

d. Competition: Software systems are created because the competition has done so. Therefore, producing software for competitive reasons is a defensive measure against someone else who has demonstrated its value. An example of this is in the banking sector. Citibank was one of the first banks to introduce automated teller machines (ATM). Other banks soon followed because of the success that Citibank had with proliferating ATMs throughout New York State. This does not imply, however, that competitive systems are always defense mechanisms. Indeed, many commercial Web sites are being introduced based simply on market forecasts for their potential to increase business.

e. For the sake of technology: While not the most popular reason, some organizations will invest in new systems because they think that it is time to do so or they are concerned that their technology is getting old. This way of supporting new systems development is rare, as it suggests the spending of money without a clear understanding of its benefits.

Therefore, the executive category of users is one that is interested in the value of the investment. These users have a global view of needs as opposed to the details. In fact, they may know little of how things are really done. The value of the executive interface is to provide the scope and objectives of the project against the perceived value they intend to get from the software. Another popular phrase for this is the domain of the system. Domain often refers to boundaries. Ultimately, what makes them happy is a system that delivers what was promised or the expected ROI.

2. Department head or line manager users: These users represent two main areas of user input. First, they are responsible for the day-to-day productivity of their respective departments. Thus, they understand the importance of meeting the objectives of the organization as set forth by the executives. Indeed, they often report to the executives. On the other hand, department heads and line managers are responsible to their staff. They must deal with the functional users and prescribe ways to improve both their output and their job satisfaction. These users perhaps provide what I call the best bang for the buck, a phrase that usually means for the time invested, you get the most payback. One can see that the department heads and line managers are responsible for most of what happens every day in an organization. Another phrase that can be used to describe them is your most valuable players (MVPs). However, beware: MVPs are the hardest to find and get for the interviews. What makes department heads and line managers happy is the most complex. They want a system that produces the output that they are expected to provide and they need a system that keeps their staff happy and productive.

3. Functional users: Also known as the users in the trenches, these people essentially do the operational activities. While they know a lot about their processes, they usually care little about the productivity and expected ROI. I often see these users as people who want little pain, and just want to work the hours they need to. Thus, fancy systems are of little interest to them unless they provide no pain—and no pain to these users means having a system that makes their job easier.

The next area to understand about users is their level. By level, I mean their understanding of computers. There are three levels of users:

1. Knowledgeable: The determination of knowledge can be tricky and is certainly based on someone’s opinion. I define knowledge in reference to experience. An experienced user can be defined as a person who “has been through it before.” A user who has been through the development of a new system can therefore be defined as “knowledgeable” within this context.

2. Amateur: The definition of an amateur is based not so much on experience, but rather on the type of experience the user has. Amateurs can be thought of as hobbyists who enjoy working with computers at

home, but have no professional experience in developing software in an organization. In this perspective, I believe that the meaning of amateur is globally defined as one who does not get paid for the work they perform.

3. Novice: These users have no experience with computers. While there are fewer such users than there were ten years ago, they still exist. A better way of perceiving a novice user is to consider my definition of knowledgeable. In this context, a novice user is one who has never been part of the implementation of a new system in a professional environment.

Perhaps the most problematic of the above levels is the amateur. I have found that users who are knowledgeable provide benefit to projects. They in many ways act as a checkpoint for the analyst in that they can ask good questions and particularly remember historical problems that actually can help the development process. Novice users add little value and also add few problems. They tend to do what you ask of them. Amateurs, on the other hand, tend to know enough to be dangerous. They also tend to have such a profound interest in the topic that they often go off on tangents about the technology instead of concentrating on the particulars of the project.

What is most important is the mapping of these categories and levels. An analyst might interview a knowledgeable executive, or a novice functional user. Each permutation can affect the way interviews are conducted. For example, an interview with a group of amateurs would focus the analyst on ensuring that the agenda is very specific. Otherwise, discussions could easily get off track. Therefore, the understanding about user levels and categories can only assist in the development of effective interview approaches.

Joint Application Development (JAD)

JAD is a process that was originally developed for designing computer-based systems. JAD centers on a three-to five-day workshop that brings together business area people (users) and IS (Information Systems) professionals. Under the direction of a facilitator, these people define anything from high-level strategic plans to detailed system specifications. The products of the workshop can include definitions of business processes, prototypes, data models, and so on.

Simply put, JAD is a method for holding group sessions with users, instead of individual sessions. You may have no choice but to use JAD when there are simply too many users to interview. JAD is also an excellent tool for use in highly political situations where obtaining consensus among users is difficult. JAD significantly differs from standard analysis in that it requires an up-front commitment from the user community. Specifically, the users must ultimately run the sessions themselves and make commitments to provide the requirements of the system. Finally, if prototypes are used, JAD is an excellent means of applying rapid application development (RAD). Both prototyping and RAD will be discussed in greater detail later.

The most important part of implementing JAD is the management of the process and the determination of the appropriate individuals to be involved. The standard roles used in JAD are as follows:

• executive sponsor: This individual effectively plays the same role as the executive supporter introduced earlier in this chapter. This person is typically at the vice-president level and ultimately has the responsibility for the business area. The ideal person for this role is someone to whom users will have to report if they plan to miss a session and who can reprimand them if they do. This thinking may seem harsh or cynical, but the risk is high that users may find more important things to do when the sessions begin. Such absenteeism can entirely undermine the process, and IS should not be called upon to police users.

• facilitator: In the best situations, the facilitator should not come from either the user community or IS, but rather from an independent area or consulting firm. This arrangement allows the session to be independent. That is, the facilitator of the JAD must be impartial and have overall responsibility for controlling the flow of the sessions. In the ideal scenario, the facilitator should report to the executive sponsor.

• scribe: This person is designated to record minutes and decisions and in many cases actually produces the models using a computer-aided software engineering (CASE) tool (see Chapter 7). A good scribe has knowledge of the business area, good analytical skills, and knowledge of CASE software. For these reasons, scribes often come from IS.

• IS representatives: IS personnel should be in the meetings not to provide requirements but rather to answer questions about the existing hardware and software. This information can be critical when discussing physical constraints of the existing systems and what data are currently available.

• participant: These are the users who have been selected to represent their respective areas. They attend the JAD sessions and are expected to come prepared to voice their opinions about what the system must do to accommodate the needs of their business unit. Participants are thus part of the “agree-to-agree” process and are empowered to vote on the actual specifications incorporated into the final software specification.

• session leader: This user is a participant who has been selected to lead the discussion on a particular subject. Such users must be prepared to provide specific topic issues so that the participants can openly discuss their opinions about what the session leader presents. The session leader may be asked to lead the discussion in a particular direction, or in some instances may have some preliminary work and may advocate a position on what the system should do. In these instances, the session leader may come to the meeting to ask for ratification from his/her peers.

• observer: These are users who attend the session to observe what is occurring, or in some cases to answer specific questions that may arise during the course of discussion. Observers are not empowered to talk unless they are asked. IS personnel, executives, and other interested parties typically attend JAD sessions to understand the process and learn from it. A special role exists when an observer serves as a “tiebreaker.” In this capacity, the observer can be called upon, either by the facilitator or the session leader, to make a final judgment on a deadlocked issue. While this role is effective in getting decisions made, it can damage the democratic process under which JAD sessions are suppose to operate.

Below is an example of an 11-phase implementation outline for a JAD session with approximately 60 users in 10 different business areas.

Phase I: Define JAD Project Goals

The purpose of these sessions will be to meet with senior management and other key organization people in order to:

• get a clear understanding of the history of the project;

• finalize the scope and time frame requirements of the existing plan;

• understand the current organization and whether political or other constraints exist;

• jointly determine the number and size of the JAD sessions to be held;

• determine the best role of Information Systems in the JAD;

• define which key users and other managers should be interviewed individually prior to the JAD.

Produce a management guide after Phase I. Its purpose will be to define management’s purpose, scope and objectives of the project. That is, it communicates management’s direction and commitment. The management guide will be approved and issued by upper management to the participating users and information system personnel.

Phase II: Meet with Key Users and Managers

Estimate that you may need to interview about 20 people from key organizations prior to the JAD. These key users and managers should typically represent three levels of the organization. The purpose of these meetings will be to:

• get familiar with the existing systems;

• validate the number of sessions and specific participants needed;

• assess the technical expertise of the participating users;

• determine what specific information can be gathered by the users prior to the JAD sessions;

• gather previous analysis and design materials and documents that may exist and explain user requirements;

• discuss types of agendas and length of sessions;

• focus on specific requirements of certain users.

Schedule interviews to last about 60 to 90 minutes and prepare an agenda that will put the purpose and scope of the interview into perspective.

Phase III: Meet with Information Systems

Get a technical overview of the existing analysis performed and state of all working documents. Gather information on:

• project history;

• potential problems envisioned in implementing the new system;

• proposed hardware to support the new system (if relevant);

• IS representatives to participate in the JAD sessions;

• models and information that can be used in the JAD sessions.

Phase IV: Prepare JAD Approach

Prepare a complete JAD program that will outline recommendations for the number and types of sessions to be held. The JAD approach will also consider the modeling tools to be used and the methods for getting user sign-off. You should focus on the following specific issues:

• the number and type of preparation sessions necessary to get users familiar with the modeling terminology;

• what business processes have already been previously modeled and can be reviewed during the sessions. This is done to avoid discussing processes that users feel have already been defined from previous analysis sessions;

• the number and types of sessions along with specific users in attendance at each session;

• a Work Document of the proposed agendas for each type of session;

• overview of materials to be used such as overheads, flip charts and room requirements;

• proposed format of the user sign-off documents.

You should meet with upper management to review the proposed approach for implementation.

Phase V: Finalize JAD Organization Structure

Assign JAD Facilitators to specific sessions along with information systems support personnel (scribes, etc.). Determine the number of JAD facilitators required. You may need one JAD project leader to take overall responsibility for the entire engagement. A detailed timeline of specific deliverables and reviews should be produced for the entire project, including reports to upper management on the JAD session progress.

Phase VI: Hold Overview Training Sessions

Depending on the results of Phase IV, hold any necessary sessions to get users familiar with the methods that will be used during the JAD. This is typically a one-day course on analysis and includes an overview of modeling lingo and tools such as:

• business area analysis,

• process flow diagrams (data flows),

• entity relational diagrams and normalized data modeling,

• process specifications,

• activity matrices,

• state transition diagrams,

• decomposition models,

• object-oriented techniques,

• prototyping.

Phase VII: Hold JAD Workshop Sessions

Prior to these sessions, participants will be asked to come prepared with certain information they will need to assist in the process. This information may typically include sample forms and reports that they use or need. The workshop sessions will be held with a set time frame and an agenda of items typically including:

• examine assumptions: These will be reviewed with the users and opened for discussion. An assumption will either:

• stay as it is,

• be revised,

• become an open issue (if consensus cannot be reached).

• design business processes: Review the collection of activities relating to the business and the system.

• define data requirements: Data are defined to support the business

process. Data models are used, developed, and reviewed as necessary.

• design screens: The screens will typically use a series of menus or other branching techniques to define how users need to access the various functions. This is usually accomplished by identifying main menu and submenu selections.

• design reports: Report names are collected and completed with detailed

report descriptions. These normally include

• report name,

• description,

• frequency,

• number of copies,

• distribution list,

• selection criteria,

• sort criteria,

• data elements.

• identify open issues: These issues are added throughout the sessions.

Open issues are those that are not resolved after a period of discussion. These are kept on a separate chart.

Throughout the above processes, the scribe will be tracking minutes of the meeting as well as the open issues and new diagramming requirements.

Phase VIII: Resolve Open Issues

Prior to subsequent sessions, all open issues must be resolved, either by smaller work groups or if necessary by upper management. In any event, it is critical that this is managed by both the facilitator and upper management prior to moving to the next level sessions.

Phase IX: Prepare Materials for Workshop Review Sessions

The facilitator should produce a sign-off level document for review. Process and data models and process specifications will be reviewed and finalized. These sessions can also include prototype screens and reports.

Phase X: Hold Sign-Off Workshops

These workshops will be designed to review the results of the initial JAD sessions. The process and data models will be reviewed. If prototypes are used, the sessions will utilize screen walkthroughs as a method of gaining user acceptance. The exact number of review sessions will depend on the complexity of the system as well as the number of screens and reports to be prototyped.

During these sessions, user acceptance test plans may also be discussed and outlined for eventual submission to the responsible QA organization. This will typically involve a discussion of the minimum acceptance testing to be validated against the product and the mechanism for testing in the field.

Phase XI: Finalize Specification Document

After review sessions are completed, the Facilitator will prepare the final document to be submitted for approval and eventual implementation. If proto- types are used, the screens and reports can be moved into the software development (construction) phase. There should also be post-JAD reviews with the development teams to clarify information supplied in the final system specification document.

JAD is introduced and discussed in this chapter because of its generic inclusion in the user-interface phase of analysis. However, it should be noted that the above outline can be integrated with many of the subjects contained in later chapters of this text. The analyst may, therefore, wish to review this outline again after completing the book in order to determine how the other concepts of analysis can be used in a JAD session.

Problems and Exercises

1. Why is it so critical for the analyst to understand the “culture” of the organization?

2. Management support is a key component of the success of any project.

Sometimes management may unfairly dictate the terms and deadlines of projects. Provide examples of different possible management opinions and how analysts can prepare effective responses to them.

3. What are the benefits of obtaining an Organization Chart prior to conducting interviews with users?

4. How does politics affect the role of the analyst and his/her approach to the information-gathering function of the interviews?

5. Why does understanding user skills provide the analyst with an advantage during interviews?

6. Explain how meeting a user in their office or place of work can assist the analyst in developing a better approach prior to the interview.

7. What is the purpose of JAD sessions? How do they compare to individual interviewing? Discuss the advantages and disadvantages of JAD.

8. Define each of the roles necessary for effective JAD sessions.

9. What is the purpose of a Management Guide?

10. Develop a proforma JAD outline for a project of 20 users in 3 business locations.

11. Name and explain what is meant by user categories.

12. How do user levels assist the analyst when preparing for user inter- views?

Mini-Project

You have been assigned by your boss to interview Mr. Smith. Mr. Smith runs a department within Human Resources that essentially provides two tasks: (1) assigning employee identification numbers to new employees, and (2) sending applications for individual insurance to the firm’s insurance provider.

The following is a list of processes that were learned about Mr. Smith’s department procedures. It is dated January 1, 2005:

• The hiring department sends a copy of the hire letter to the department to notify them about a new hire.

• New employees must report to the department on their first day. The

employee must bring the original hire letter.

• New employees are validated and asked to fill out a new hire employee form. The form contains the necessary information needed by the department.

• After the form is filled out, employees receive an identification card.

Every identification card has a unique ID number.

• The insurance form information (on the new employee) is sent to the insurance company.

• The insurance company must accept all applications.

• The insurance company has 30, 60, or 90 days to respond to an appli- cation. The number of days depends on the employee’s level.

• The department will follow up on late acceptance verifications.

Insurance confirmations are returned to the department, but the actual insurance package is sent to the individual.

All information on the employee collected by the department is filed in an employee folder.

Mr. Smith has been running this operation manually for over 25 years.

Assignment

Prepare 15 questions that you would ask Mr. Smith during the interview.

Search This Blog

System Analysis and Design course