0 Table of Contents

0 Table of Contents.........................................................................................................1
1 Introduction..................................................................................................................3
2 Joint Application Design.............................................................................................5
2.1 Overview..............................................................................................................5
2.2 Phase of JAD.......................................................................................................6
2.2.1 Phase 1.........................................................................................................6
2.2.2 Phase 2.........................................................................................................7
2.2.3 Phase 3.........................................................................................................8
2.2.4 Phase 4.........................................................................................................9
2.2.5 Phase 5.......................................................................................................10
3 Participatory Design..................................................................................................11
3.1 Overview............................................................................................................11
3.2 Techniques.........................................................................................................11
3.2.1 Visualizing the current workplace.............................................................11
3.2.2 Visualizing the possible workplace...........................................................11
3.2.3 Prototyping................................................................................................12
3.2.4 Time During the Development Life Cycle................................................12
3.2.5 Who Participates with Whom in What?....................................................12
3.2.6 Appropriate Group Size for the Practice...................................................13
3.3 PD Principles.....................................................................................................13
3.4 PD Advantages..................................................................................................13
4 Comparison of JAD and PD......................................................................................14
5 Comparison with Other Techniques..........................................................................16
5.1 Quality Oriented Methodologies.......................................................................17
5.2 Process Oriented Methodologies.......................................................................17
5.3 Agile Methodologies.........................................................................................18
6 Conclusion.................................................................................................................18
7 References..................................................................................................................19
1 Introduction
Joint Application Design (JAD) and Participatory Design (PD) represent two different
techniques that address user involvement through group sessions. In the software
development industry the success of a system is proportional to the degree of user
involvement in the project. Even though there is little empirical proof of this truism, it is
seen as axiomatic in the Information Technology (IT) community. Increased user
involvement in a project increases the level of complex social interactions. Often these
social factors can be difficult to deal with which is why group session techniques were
created, as a method of structured social interactions to gain the most benefit from
increased user and stakeholder involvement.

Methodologies concerned with user involvement differ in their degree of user

participation. Three styles of user involvement have been documented (Carmel 1993):
consultative design, representative design and consensus design. In consultative design
decisions are left to the IT staff working on the project, which consult users in order to
elicit requirements about the system. Representative design involves selected users who
work directly with IT to help make decisions about the system and provide system
requirements when needed. Consensus design assigns responsibility to users who are
continually involved in the project design process, working as a part of the project team.

Figure 1 - Spectrum of user involvement [Carmel 1993]

There is no strict mapping between the three styles of user involvement and standard
software development methodologies. In relation to JAD and PD, JAD falls in the
representative design style and PD in the consensus design style as represented in Figure
1. These methods attempt to apply abstract notions of user involvement to practical
implementations through various group session techniques.

Group session techniques recognize the importance of group interaction for requirements
elicitation. One deficiency of the majority of Software Life Cycles is their tendency to
ignore social factors in software engineering. Group sessions promote the sharing of
information among project group members by gathering them together to discuss the
project. By having key decision makers present project decision can easily be made.
Together the group can coordinate and control any shared objects in the project. As well
each group member achieves organization and gains common understanding of the work
process.

In a group session there are many roles taken on by members of the group. Roles such as
Record Keeper and Time Keeper are traditional roles present in most group settings.
Other roles such as Observer and Specialist may or may not be filled during a group
session. The Clients, Project Sponsor and Project Leader are important roles filled both in
the group session and during software development.

In a group session however the Facilitator fills the most important role. The Facilitator’s
job is to assist group members in performing their collective task as a group. They get the
meeting started, help to keep the meeting running smoothly and ensure a clean closure of
the group session. There are many techniques employed by the Facilitator to keep a group
session working all of which are based around social factors.

2 Joint Application Design

2.1 Overview
Joint Application Design originated in the 1970s at IBM. Developed by Toby Crawford
and Chuck Morris it evolved completely outside of the academic world and is viewed as
both a technique and a methodology. The four building blocks of JAD are:
  Facilitation
 Agenda
 Documentation
 Group Dynamic

Facilitation refers to the process of successfully running a JAD session. Facilitation is

one of if not the most important part of a successful JAD session. Without a good
facilitator and JAD session will not have a good chance of success. Agenda refers to the
structured nature in which the JAD sessions are run. With a group session like JAD you
need to have a set of objectives that allow the session members to stay focused. With the
agenda the team is able to make sure that all issues are dealt with and that they do not
spend too much time on a single issue since they are sticking to the agenda.
Documentation refers to the artifacts produced during a JAD session. A scribe is in
charge of recording down all relevant information that is brought up during the session. It
is important that that scribe make sure they take down the information without biasing it
with their own viewpoint. Finally Group Dynamic is the positive social interaction that
allows the JAD sessions to produce the needed system requirements. Without a good
group dynamic the JAD session will not run very well since people will not be
communicating well and thinking creatively. There are many team-building techniques
that a facilitator can implement if the team is having problems.

The team within a JAD session is composed of the following participants:

 Project Sponsor
 Business Users
 System Analysts

2.2 Phase of JAD

JAD has five phases, only one of which involves the JAD session itself. Each of the five
phases will be detailed further below.
2.2.1 Phase 1

Figure 2 – Phase 1 of JAD

The first phase involves the Project Definition. Here the JAD team is selected;
management is interviewed to help prepare a high-level Management Definition Guide
that provides the basis for the overall project. The management definition guide defines
the purpose, scope, and objectives for the project. The session then has to be scheduled.
The scheduled time for the session will depend on the overall project schedule and the
schedule of the session participants. The session should be scheduled far enough ahead
of time to resolve any scheduling conflicts.
2.2.2 Phase 2

Figure 3 – Phase 2 of JAD

With the Management Definition Guide completed the proposed system can be further
researched. This will involve gathering preliminary information that will be useful in the
JAD session. This information basically allows the background domain knowledge to be
gained through meeting with both business users and the technical staff. From these
meetings high level data and process models can be created. The session participants will
use these models in the JAD session to help speed along the understanding of the system.
Lastly the JAD session agenda is created for the meeting. As mentioned earlier a well-
planned agenda is crucial to a smooth running JAD session. The agenda should
breakdown the session, explicitly stating how much time is to be spent on different areas
of the actual session.
2.2.3 Phase 3

Figure 4 – Phase 3 of JAD

In the third phase all preparation is made for the JAD session. The research information
that was previously gathered is turned into a working document. This working document
will eventually evolve into the final document after the session is completed. A pre-JAD
session meeting is held to orientate everyone with the materials and to make sure
everyone is aware of how the JAD session will be run. During this time the scribe should
also be trained on how to properly record information that comes up during the session.
Any visual aids that are deemed necessary should also be prepared at this time. Some
examples of visual aids that may be helpful are:
 Flip Charts
 White boards
 Magnetics for use on a white board
  Overhead projectors
 Computer projection unit
The next step in this phase is to setup the JAD session room. The room should be setup
in such a way that it encourages group interaction and allows for the participants to easily
access the visual aids and models in the room. Figure X shows a typical JAD session
room.

2.2.4 Phase 4

Figure 5 – Phase 4 of JAD

The actual JAD session can last several days in some cases. The meeting basically
follows the agenda that was previously set. A typical agenda will first go over the
preliminary information in detail to get group participants communicating about the
system requirements. Open issues that were deferred during the earlier stages are
discussed. Any assumptions about the system are brought up for everyone to understand.
The participants use the data models and other preliminary information and the facilitator
runs the meeting. It is up to the facilitator to make sure that the session stays on track and
that everyone involved has his or her voice heard. The scribe takes detailed notes and
those along with overheads, charts and any other group collaboration documents created
during the session are combined as the artifacts of the meeting.

2.2.5 Phase 5

Figure 6 – Phase 5 of JAD

After the session has the final document comes out of the JAD session artifacts. The
document is assembled, reviewed and approved by management. Any changing
requirements may be fed back into the JAD process and discussed in another JAD
session. The final document provides system requirements that lead into a software
development design phase.
3 Participatory Design

3.1 Overview
Participatory design (PD) began in England with Enid Mumford in 1970s, and was
developed in Scandinavia by Pelle Ehn and Morten Kyng in late of 1970s (Harris and
Taylor, 1996). Participatory design focuses on the users/customers involvement,
compared with the technical centered approaches. PD has proliferated in European
countries however it is still in its infancy in North America.

PD is based around a union mentality. Workers should be given better tools as opposed to
having their work automated. Workers are also the best qualified to help improve their
work and work life. As such IT can only be properly addressed within the context of the
workplace otherwise it will ignore user’s perceptions and feelings about the systems they
use which in PD is just as important as technical specifications.

3.2 Techniques
Some of the techniques that can be used in PD are (Muller, Wildman and White, 1993):

3.2.1 Visualizing the current workplace

Immersion of designers and facilitators in the target workplace (hands-on
apprenticeship), games (structured activities and interactions)

3.2.2 Visualizing the possible workplace

Future workshops, metaphor based design site visits, storyboards, video productions,
brainstorming, improvisational theater and role-playing, and various types of graphic
illustration.

3.2.3 Prototyping
Presentation and Evaluation of concrete options: Cooperative prototyping, Props and
mock-ups of available materials (cardboard). The users actually work with a prototype
and experience it.
From above we can see that PD is a complex process involving technology and multiple
levels of organization. It is also highly dependent on specific organizational contexts. For
project participants, this means there are no programmatic solutions. To the extent that
PD projects have been documented to date, there is little evidence that a "standard" set or
ordering of practices has been decided. However, PD efforts in recent years have led to
the repertoire of flexible practices and general guideline. The figure below shows a brief
guide to PD practices for practitioners.

Figure 7 - Techniques Applicable in Participatory Design [Clement and Van den

Besselaar, 1993]

The graph in figure 7 shows many of the techniques that are available to use within PD.
As you can see they are numerous. Some of the key concepts from the above figure are
below.
3.2.4 Time During the Development Life Cycle
Some practices appear to be more appropriate at certain points within the development
life cycle or iteration. The horizontal axis of the figure provides a very approximate guide
to points within the life cycle at which each practice may be useful.

3.2.5 Who Participates with Whom in What?

The concept of participation is open to multiple interpretations. The vertical axis of the
figure spans one way of organizing the various approaches: the software professionals
can participate in the users' world (lower on the axis), or users can participate in the
software professionals' world (higher on the axis).

3.2.6 Appropriate Group Size for the Practice

Different practices are designed to work with groups of different sizes. Superscript letters
for each category of practice indicates appropriate group sizes: T (tiny, 2-4 participants).
S (small, 6-8 participants), M (moderate, up to 40 participants), and B (big, up to 200
participants). The group size recommendations are in some cases approximate.

3.3 PD Principles
Miller, 1993 proposes principles which embody PD:
 Workers and customers are intelligent, creative, and productive contributors to
organizations if they are empowered to express their insights, apply their
expertise, exercise their decision making capabilities, and given responsibility for
the impact of their actions.
 PD holds that good ideas are as likely to come from the bottom up as from the top
down. Front-line workers and customers know what works, what doesn’t work
and have lot’s of ideas on how to improve things

3.4 PD Advantages
Harris and Taylor, 1996 propose some advantages of using PD:
  involving users of different organizational groups and provide a forum in which
the participants can better understand boundaries and explore ways to overcome
them
 shared understanding and knowledge of the process enables individuals to
anticipate the consequences of their actions.
 increasing worker's influence on technological change
 participation in the design process also prepares people for changes
 participation was used as a tool to open up conflicts and negotiations throughout
the design processes

4 Comparison of JAD and PD

Comparing Joint Application Design and Participatory Design, the first comparison may
be made on the level of user involvement. There are three styles of user involvement that
create a spectrum of user involvement as seen in Figure 1. Even though it is difficult to
strictly map software methodologies to a single user involvement style JAD is considered
to be a Representative style where as PD falls into the Consensus style of user
involvement.

Both JAD and PD differ over whom the users are that are involved in the group sessions
and when they are involved. Both JAD and PD are weighted towards the Requirement
Engineering phase of the Software Life Cycle however this does not exclude them from
being used continuously throughout the software development process.

In the case of JAD, JAD Sessions may be held whenever there is a need to bring
everyone together to discuss an important issue. Due to the overhead involved in setting
up a JAD Session they are most effective when defining the system at the beginning of
the project and when any major changes in project direction and scope occur. At that
point the overhead involved is justified, as the decision is one that involves more than one
party.
PD may also be used continuously throughout the Software Life Cycle but since it is
most effective early in the design process when ideas are less constrained by exiting code
or infrastructure its focus shifts to evaluation of the project. Through cooperative
prototyping it is possible to have users help to design, refine and valuate to look and feel
of the system. These group session follow the Workshop approach but are structured to
focus on the system interface and promote feedback about it. Since these are the people
who will use the system everyday their input is viewed as very valuable and helps ensure
that the system will be used once it has been delivered. TO this end PD often excludes
management from the process focusing on the lower-level operational users who will be
the direct users of the system.

The second main difference looks directly at the structure placed around the group
session of JAD and PD. JAD uses a very structured approach to the group session. Of the
five phases of JAD only phase four involves the JAD Session, the first three phases are
used to prepare a details Management Guide and session agenda and the last phase is
used to prepare the outputs of the meeting for use in either the next JAD Session or the
start of the project design phase. The agenda provides a step-by-step plan to how the
meeting should run. This cookbook approach to running a JAD Session is further
constrained by the use of the Management Guide to keep the meeting discussion within
the scope of the project.

PD specifically avoids providing any step-by-step plans for the Workshop. It relies on the
Facilitator to improvise during the group session to guide it in the desired direction. By
focusing on the aspects of designing the PD Facilitator needs to understand the project
technically as well which leads into the third difference between JAD and PD.
The last major difference between JAD and PD revolves around the role of Facilitator. As
discussed the Facilitator is considered the most important role in a group session. They
are responsible for engaging the group to come with the requirements or design that was
the whole reason for having a group session.
During a JAD Session the facilitator controls the meeting completely. They are not there
to provide and answers about the system or to make decisions about the project but to
guide the group in attaining this information. The Facilitator adheres to the agenda and
tries to keep the JAD Session on track limiting the amount of time spent on each agenda
item. The Facilitator is responsible for identifying where key knowledge is missing and
requesting to have a Specialist brought in to cover the area, and to keep Observers from
participating in the meeting. Since JAD has a very structured approach to how the
meetings are run there needs to be an authority to keep the meetings on track and that
authority is the Facilitator.

In PD the Facilitator is called a Designer. Their role is both as a Facilitator and as a

technical advisor. Since the meetings are less structured the Designers role is to guide the
group session towards an end that will provide enough information to build the system. In
order to do this they need to have technical abilities to understand what aspect of the
system needs to be discussed and to what detail is required for the project to move into
the design and build stages.
There are many other differences between JAD and PD based on their creation and
history, focus and perspective on group sessions. They are listed in the following table:
Point of Comparison JAD PD
Background Theory Group dynamic, software engineering Labor relations, group learning
Goal Improved System Improved Workplace
Roots Industry, USA, Canada Government, unions, academia,
Scandinavia
Current Practice Consultancy for profit Consultancy on principle
Focal Activity The meeting, delimited by time and a set Group processes, agenda negotiable
agenda
Techniques Emphasis Structure Creativity
Perspective on Users Both operational workers and managers are Users are operational users.
“users”
Selection is based on competence criteria Manager group dealt with separately
or not included
Users are views on as on source of Users are viewed as the primary
knowledge source of knowledge

Table 1 – A Comparison of JAD and PD [Carmel, 1993]

5 Comparison with Other Techniques
Comparing JAD and PD to other methodologies there are three groups of methodologies
to compare against: Quality Oriented Methodologies, Process Oriented Methodologies
and Agile Process Methodologies. Similar to how it is difficult to map methodologies to
user involvement styles it is also difficult to group methodologies for the sake of
comparison as each method is different from one another. Rather then perform a direct
comparison between JAD, PAD and each method it is easier to recognize that there is no
strict mapping but that they generally fall under the selected grouping.

5.1 Quality Oriented Methodologies

Quality Oriented Methodologies include methodologies such as Cleanroom and Qualify
Function Deployment (QFD). These methodologies focus on defect reduction through the
use of high-quality requirements. By spending a lot of time performing up-front design
these methods attempt to discover the majority of problems before they enter the build
stage. They use other methodologies and techniques for requirements elicitation usually
starting their process with a set of requirements.

These methodologies do not focus on the social aspects of Requirements Engineering.

Instead they rely on the application to tools to the requirements provided to them. These
tools, such as the House of Quality (QFD) help to analyze and prioritize the requirements
to create a clean set that may then be used in later stages of the process. JAD and PD are
called methodologies however the term technique is more appropriate as they do not
cover the entire Software Life Cycle. Their use is heavily weighted towards the
requirements elicitation phase of a project. JAD and PD would work well as a “lead in”
to these methods providing the way of obtaining requirements in a requirements
elicitation phase.

5.2 Process Oriented Methodologies

Process Oriented Methodologies include Software Analysis Software Design (SASD) and
Soft Systems Methodology (SSM). Focusing on processes these methods use structure to
deliver the desired system. The methodology may be heavyweight as in SASD, covering
the entire Software Life Cycle in great detail, or as is the case with SSM provide a means
for a software development process to be defined within an organization tailored towards
the needs of the business and culture. These methodologies do not focus on requirements
gathering either and as such JAD and PD may be used in conjunction with these methods
to provide requirements elicitation just as in the case of Quality Orient Methodologies.

5.3 Agile Methodologies

Agile processes have many principles that are common with JAD and PD. People are the
most important asset in Agile programming as well as in group sessions. Their
involvement is key to the success of the system. Agile processes fall in the Consensus
user involvement style since they have a user representative available throughout the
entire Software Life Cycle. Communication among these people is the second critical
aspect to a project’s success. The better the communication the more understanding is
spread throughout the users about the system and the project.

Agile processes use a “stand up” meeting that is structured similar to JAD with a definite
agenda and goal. The daily Scrum is an example of this type of meeting. JAD Sessions
and PD Workshops last one or more days where as agile process meetings are usually
around fifteen minutes, but both highlight communication and the importance of face-to-
face conversations with people about important matters. Meetings may be called any time
in agile processes which holds for JAD Sessions and PD Workshops however the
overhead of JAD and PD means that their use will only happen should the problem be on
a larger scale. Finally agile processes cover the entire Software Life Cycle where JAD
and PD are more techniques that are most useful in the Requirement Engineering stage.

6 Conclusion
JAD and PD have distinct advantages over other methodologies due to how they take
social factors into account. Most other methodologies ignore these social interactions and
focus instead on the technical aspects of Software Engineering. However the needs of the
user community are not addressed which is why JAD and PD complement these
methodologies very well.
Both highlight the need to involve users in the project in order in increase the success of
the system. By empowering the user through improved communication a high level of
system adoption or “buy in” is achieved. When the project is completed and the system is
deployed the users know what to expect and are generally pleased to see their
requirements make it into the finished product. This also makes users feel like
stakeholders without assigning them any of the authority that goes with the role.

Both JAD and PD can be used anywhere in the Software Life Cycle but are generally
most useful in the requirement elicitation phase of the Requirements Engineering stage.
These methodologies require highly trained Facilitators, or Designers in the case of PD,
to run the meetings and generate outputs from the users that are usable in the later stages
of the software development process.

Finally it might be unrealistic to believe that all issues with be resolved in a single group
session. JAD Sessions and PD Workshops last a while however it is possible that not all
issues will be addressed or the session may focus only on a specific area Other sessions
may be required however the overhead of having them is fairly large, especially in the
case of JAD.

Overall group session techniques take social interaction into account where other
methodologies do not. They focus on user involvement in the project and to increase the
success of the project and promote adoption of the completed system.

7 References
 Carmel, E., Whitaker R. D., & George, J. F. (1993). PD and Joint Application
Design: A Transatlantic Comparison. http://web.njit.edu/~jerry/MIS-645-
Papers/Carmel.pdf.
 CM Solutions (2000). Joint Application Design (JAD) Sessions. http://cm-
solutions.com/cms/tools/application_development/joint_application_design-
jad.htm
 Davis, K., Titchkosky, L., & Werbicki P. (2002) Joint Application Design,
Participatory Design.
http://www.criticaljunction.com/werbicki/SENG613/Group/SENG613F02_JAD_
PD.ppt
 Gregory, S., & Tu, P. (2000). JAD, RAD and PD.
http://sern.ucalgary.ca/~phong/courses/SENG613/WebDocument.htm
 University of Texas (1998). Joint Application Development (JAD) - What do you
really want? http://www.utexas.edu/hr/is/pubs/jad.html
 Miller, E. S. (1993). From System Design to Democracy, Communications of
ACM, Vol. 36, No. 4, June 1993.
 Harris, G. B., and Taylor S. (1996). Participatory Design Using the Action
Workflow Model, Workshop on Strategies for Collaborative Modeling and
Simulation, Conference on Computer-Supported Cooperative Work, Boston,
MA.
 Muller, M. J., Wildman, D. M., and White, E. A. (1993). Taxonomy of PD
Practices: A Brief Practitioner's Guide, Communications of ACM, Vol.36, No.
4, June 1993.