Design and Implementation of Human – Computer Interfaces

Dr.Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology - Guwahati

Module No # 01
Lecture No # 01
Interactive Systems

Hello and welcome to the NPTEL MOOC’s course on design and implementation of human
computer interfaces. Today we are going to start the course with the first topic that is general
introduction to the interactive systems and brief history. Before we begin let us understand
the scope of this course. So here we are going to talk about design and implementation of
interactive systems.

In other words we will be actually talking about how to engineer quote unquote engineer and
interactive system.
(Refer Slide Time: 01:22)

So there are 2 things involved here one is interactive system or software specifically
computer software that are interactive. So we are going to focus here entirely on software that
is interactive what is interactive software? We will soon learn about those second concepts
that are important here is that word engineering. So here we actually refer to the fact that such
software can be developed in a very systematic manner involving stages and we are going to
learn about those stages.
(Refer Slide Time: 02:06)
Given this scope of the course let us being with the major the primary concept that is
involved here that; is interactive software or interactive system. In general where we will be
implicitly referring to software whenever we; are going to use the term interactive system.
Now these interactive systems whenever we mention this term automatically questions comes
to mind why we are labeling certain software’s as interactive and how these are different from
other software.
(Refer Slide Time: 02:49)

Let us try to understand that little bit in depth so let us begin with the very concept of
computer why never we mention the term computer? What comes to our mind?
(Refer Slide Time: 03:02)
For those who are part of an earlier generation the term computer immediately brings to mind
desktop or Laptops most likely.
(Refer Slide Time: 03:21)

For younger generation the term computer may also refer to along with desktop and laptop
may also refer to smart phones or tabs or even some wire able devices.
(Refer Slide Time: 03:35)
Now this desktop, laptop, Smartphone, tabs are those only the examples of computer let us
see.
(Refer Slide Time: 03:49)

The answer is unequivocal no there are many more computers that we may be using without
being aware of them.
(Refer Slide Time: 04:04)
In fact we are surrounded by such computers let us see one simple example a digital
Pedometer. Is it a computer? To understand this question or to answer this question let us first
go with the definition of a computer. What is a computer?
(Refer Slide Time: 04:21)

According to oxford English dictionary a computer is an electronic device which is capable

of receiving information data in a particular form and of performing a sequence of operations.
In accordance with a predetermined but variable set of procedural instructions which is also
known; as program to produce a result in the form of information or signal. So in a nutshell a
computer take some input apply some program to convert it to some output and the program
performs some operations on this input and this program is pre-stored somewhere.
(Refer Slide Time: 05:11)
Now let us comeback to digital Pedometer whether it is a computer or not. So what a
Pedometer does?
(Refer Slide Time: 05:18)

The main objective of a Pedometer is to identify that the wearer is working or not? Of course
now a day’s Pedometer also have many features but let us only focus on the key function of a
digital Pedometer which is trying to determine the walking speed and the walking distance.
So essentially it tries to identify whether you are walking or not. So in order to do that; it
must differentiate between walking and standing how a device can do that?

When we are trying to do it we visually see the movement and then accordingly our brain
produces the understanding whether somebody is standing or walking. But in that case of a
digital pedometer how it can do that?
(Refer Slide Time: 06:14)

That is one issue second issue is typically digital pedometers are known to keep count of
number of steps.
(Refer Slide Time: 06:27)

So that is another function but as you may understand or as you may try to understand
counting the number of steps is not an easy task. Because you are likely to walk at different
steps at various instance of time in fact as a though exercise you can yourself try to do it try
to count the number of steps that you are performing while walking. And you will understand
the difficulty involved.
(Refer Slide Time: 07:05)
So the pedometer first tries to understand that you are walking then it try to count the steps
the number of steps. And finally from the number of steps it tries to compute the total
distance covered. So how it does that? It has to know some formula for this conversion and
based on that formula it can perform the conversion so, this formula as to be somewhere in
the device.
(Refer Slide Time: 07:43)

So there are 2 things involved one is trying to understand whether you are walking then
counting the steps and then converting it to a distance and the second thing is storing the
relevant formally as well as performing the actual computers. So if we now try to compare
the activities of a pedometer with the definition of a computer we will see that pedometer
accepts as input.
Some sensor information processes it based on the algorithm which is nothing but those set of
formulae. And based on that algorithm it produces some output which is the distance covered
or the walking speed etc. So it perfectly fits the definition of a computer so digital pedometer
we can say is a computer.
(Refer Slide Time: 08:42)

Let us see another example microwave oven many of us might have seen this in our kitchen.
So is it a computer?
(Refer Slide Time: 08:58)

Now if we look inside the oven we will see that it consist of various components broadly
these are the components who are likely to find inside a microwave oven. A magnetron tube,
turn table plate, beeper, door, front panel, display and light these are the components. And
then there is some embedded hardware and software to operate these peripheral devices. As
well as generate certain output those devices.

So here also we can see that it receives some input say for example input from this front
panel in terms of the temperature duration. Then it produces some output on the display as
well as some sound output and it performs certain operations depending on the input provided
based on stored program. So it also is an example of a computer as per definition.
(Refer Slide Time: 10:16)

A third example is a smart TV whether it can be considered as a computer or not.

(Refer Slide Time: 10:25)

Here also there are lots of components involved let us have a look at the software or the smart
TV app which can be understood in terms of layered view of the software where you have
HTML, CSS, Javascript layer, media layer and on so and so forth. So the user provides some
input to the app through some interface then the TV itself has the software which is
connected to some servers to fetch information.

And then that information is processed and displayed on the screen again it takes input
processes based on the stored program and produces output. So as per definition this also is a
computer so these examples so that we are surrounded by computers.
(Refer Slide Time: 11:33)

Now all these are actually examples of interactive computing systems and the interaction
takes place between the computer and the user. Now the most important factor is that these
users are not experts, these users are layman users. Anybody can be the user of the digital
pedometer or microwave oven or a smart TV without any specific qualification. So that is the
defining characteristic of any interactive system or interactive software or interactive
computing system.

That these are systems that are used or interacted with by a user is a layman user who does
not have any specific qualification to be a user of the system. So whenever we will be using
the term interactive system will be referring to such systems where layman users are the users
of the system rather than somebody who has special training to use the system.
(Refer Slide Time: 11:33)
Now this brings us to the next question that we should try to answer is it necessary for the
users to know about the technology behind. So I said that for an interactive system users need
not have any specific qualification. In that case to operate or interact with an interactive
system does, the user need to have any specific technological knowledge.
(Refer Slide Time: 13:24)

Let us see another example some of you may by familiar with this type of display. It used to
come in some earlier operating system, version where they are used to some error messages
displayed in this form. So this is actually an example of an error message produced by an
operating system which used to be there same time ago what it says that? There is a header
which says system error status some number which is actually in hexadecimal code.
And then what it says is that a particular system, a particular app or application initialization
failed because some device attach to the system is not functioning click ok to shut down and
reboot into safe mode. Check the event log for more details and there is only one button to
select which is okay. So whether you like it or not you have to press ok to move forward now
what this message actually tells us.

If I do not know anything about this terms or what is the hexadecimal code what is event log?
What is system accounts manager or security accounts manager? I will not understand
anything from this message although it is shown to user of the system but the user is expected
to have certain level of knowledge as is evident from particular output.
(Refer Slide Time: 15:06)

Now if I do not have that knowledge then I am not going to able to figure out what is that
error and what I am suppose to do. So that will lead me as a user to anxiety. Did I do
something wrong what is that wrong thing I did? How to get out of it? And should we refrain
from performing anymore thing so that such error messages do not come again and again.
That is anxiety that I will have if I do not know the meaning of those messages.
(Refer Slide Time: 15:06)
Now this anxiety or this kind of confusions in the mind of the user may lead to the loss of
motivation which is very important loss of motivation of further use. In effect this will make
the user think that such systems are not for me to use. So rather I should not use it which
actually will defeat the whole purpose of making the system used by the users.
(Refer Slide Time: 15:06)

So these concerns where we want to avoid the user being forced to lose to motivation or
being forced to have confusion because certain knowledge is not there. This concern actually
brings us to these important concepts of user centric design.
(Refer Slide Time: 16:43)

The principle objective for interactive system should be that the system should not force users
to learn about the underlying the technology that should be the guiding principle for any
interactive system otherwise the user will not be motivated to use the system. So accordingly
the system should be designed.
(Refer Slide Time: 17:10)

Now the main concern here is how to design the system so that users find it easy to use. So
that is the main challenge to a interactive system design.
(Refer Slide Time: 17:28)

In order to have a better understanding of this challenge let us discuss an example system
which is ubiquitous most of us have seen it. This is an example if a, TV remote control now
probably all of us have used one of such remote controls.
(Refer Slide Time: 17:56)
What are the activities that are typically with such a device? We can control brightness,
contrast, gamma correction and many more things with the device. We can input channel
number typically 3 digits but it may be different in different locations. To select a particular
channel you can control voice level. We can do certain other things like watch movies from
external devices attached to the TV or watch or view photos or watch videos from our digital
camera after attaching it to the TV. And all these things we can do by interacting with the TV
through this remote control.
(Refer Slide Time: 18:52)

So in the example remote control that we are discussing let us see which portion deals with
which of these activities. Now this top region shown in red circle typically has buttons for
channel change, volume control additionally it also has couple of buttons for change in input
source as well as power on off button.
(Refer Slide Time: 19:28)

There is another group of buttons in the middle of the device which are used occasionally to
navigate various menu options.
(Refer Slide Time: 19:46)

And finally there is a third group of buttons which are rarely used actually many of us may
not even be knowing what are the purpose of these buttons. Because either we never use them
or use them so infrequently that we forgot. So among these 3 groups the first one involving
buttons for channel change or volume control is likely to be most frequently used group of
buttons. Whereas the third group of buttons is the list likely to be used buttons.
(Refer Slide Time: 20:26)
But the thing is that in the same device all these buttons are provided. So this third group
actually supports many more functionalities which we may not require frequently. In fact in
most of the cases we never require it.
(Refer Slide Time: 20:47)

Now the thing to be noted here is that in the same device we have all the buttons are put on
the same device. So same device contains every control options considerable and supported
by the TV when is the result for such a design? It actually succeeds in scaring away many
potential users initially. But of course since it is a very simple device with few days of usage
people tend to learn.
But again as I said this third group of buttons will never be learned because those are very
infrequently used or not used at all. Whereas the first group of buttons is likely to
remembered and used most frequently so what could have been done?
(Refer Slide Time: 21:38)

Instead of designing it in this way it could have been designed in such a way such that the
most frequently used buttons are kept in very prominent way and the least frequently used
buttons are not given the same prominence as the most frequently used that would have
probably emphasized the relative weight of the or relative importance of the buttons to the
users and accordingly the user would have tried to learn them.

So this example tells us that user centric design is very important where it refers to the
process to design products which are computers in which the user needs an expectation are
taken care of by considering their characteristics. So we should know who, are users of this
remote control likely to be everybody what are their needs and expectations as I have already
mentioned.

Mostly they require this first group of buttons accordingly we should have designed and we
probably should have kept the other buttons not in a very prominent position. So that the user
should not; have been intimated it by the presence of so many control options.
(Refer Slide Time: 23:10)
So this remote control we can think of as an interface to the television rather than TV itself.
(Refer Slide Time: 23:21)

Now if we again consider this example so since user centric design is our focus so if we again
consider this example let us try to understand what we are trying to design? What we are
trying to do differently so that this product becomes user centric? Now the remote contents
buttons which we can call as elements of the interface to a computer which is the TV.
(Refer Slide Time: 23:56)
That is the first to note second thing is these buttons are placed in a particular way which
actually defines the geometric layout of the interface.
(Refer Slide Time: 24:11)

That is the second thing to note a geometric layout of the interface then when we interact
with the TV using the remote. For example to select a channel we visually perceive the
system state and its change from the TV screen or from the display so that is the third element
of an interactive system. And finally we continue the performing the operation till we are sure
that till we are achieved what we wanted?

That is the system state matches with our goal state as per our perception so when we are
talking of designing a user centric product or system there are 4 things we should consider.
One is the interface element their geometric layout the perception of the system state and
matching of the system state with our goal state. So these are issues that we should be
concerned about while going for designing a user centric system.
(Refer Slide Time: 25:25)

That means in other words so 4 things we should take care of in user centric design. First
thing is design the elements that are acceptable to the users not the word acceptable then
design layout that meet user expectations. So any layout is not good so first we need to know
the expectation of the users and accordingly we need to design it.
(Refer Slide Time: 25:25)

Then help the user perceive the system state so design the display in such a way. So that the
state of the system from the users point of view is easily understandable.
(Refer Slide Time: 26:10)
And finally design interaction that fulfils the needs of the users by taking them to the desired
system states. So design element, design layout, design display interaction these 4 are the
primary things that are designer of the interactive system should be aware of or should be
conscious about while going for a user centric design.
(Refer Slide Time: 26:41)

So with that let us learn a little bit of how this field that user centric design evolved over time.
So we will briefly mention about the mile stones that have been achieved during this journey
of last few decades.
(Refer Slide Time: 27:05)
So let us briefly learn about the historical evolution of this field of user centric design. So this
evolution we can broadly divide into 4 phases, not very distinct there will be some overlaps
in this phases but we can still broadly divide it into 4 phases.
(Refer Slide Time: 27:33)

The first phase is we can turn it as pre-history which is the period between the nineteen
forties to nineteen seventies in the last century. This is before the advent of the so called
personal computers. So during this phase also as we will see several developments took place
that advanced this field of user-centric design.
(Refer Slide Time: 28:04)
Then comes the early phase which is roughly; from nineteen eighties till the early twenty first
century which is or can be considered as the era of personal computers.
(Refer Slide Time: 28:26)

Then the pre-modern phase late nineteen nineties to the; first decade of the twenty first
century. Now during this; phase widespread use of mobile personal computing devices have
been observed notably smart phones and tablets.
(Refer Slide Time: 28:46)
And finally we can think of the modern age which is continuing which is the era of inter
connected devices. Now let us see what are the mile stones that have been achieved in these 4
phases?
(Refer Slide Time: 29:11)

In the per-history phase that is between nineteen forties to nineteen seventies before the
advent of personal computer. We have several important milestones so in the 1950 the first
video display unit came out which is called the Sage system. Then 1963 one interesting
system was developer called sketchpad by E Sutherland. Now it introduced the idea of
graphical user interfaces and the concept of interaction.

Then can the online system or NLS proposed by Engelbart and team in 1968 which
introduced an important interaction device which is uibiquitous as the Mouse. The release of
first commercial microprocessor named Intel 4004 happened in 1971 which revolutionized
the computing landscape. And finally in 1972 one product was developed although it was not
commercially very successful the Dynabook by Allan Kay which is a precursor to the
personal computers.
(Refer Slide Time: 30:34)

As compared to this phase the early phase had less number of milestones it primarily consists
of the early personal computers Xerox alto which came in 1973 then Altair 8800 1974 Apple
1 1976 and apple 2 1977.
(Refer Slide Time: 31:05)

The most impactful development happened in 1981 with the advent of IBM PC or personal
computer. Then Xerox star in 1981 also introduced the concepts such as graphical user
interfaces then WYSIWYG or what you see is what you get concept then the idea of
metaphors which have profound impact in the development of user centric systems. Almost at
the same time in 1982 the concept of direct manipulation came into being proposed by
Shneiderman.

Then Apple Mac was released in 1984 again another important milestone in that phase the
idea of World Wide Web came about in 1989 and the first wave browser was developed in
1993. So all this actually have profound impacted the advent of the user centric design area.
(Refer Slide Time: 32:20)

In the pre-modern phase we had pump pilot in 1996 which is the first example of the
successful mobile device. Nokia 9000 which came in 1996, then in 2008 Android 1.0 was
released which revolutionized the smart phone landscape. Also during this period other smart
and intelligent consumer electronic products proliferated which again affected the advent of
user Centric design field.
(Refer Slide Time: 33:00)
Finally we came to the modern phase although in this phase the smart phones still there but
the main landmark even that happened is that. Now we are no longer talking about personal
devices the single device instead we are more concerned about connected devices in the
ubiquitous computing environment where the devices are connected to each other to given
better experience to the user.

Now this term was first proposed by Mark Weiser way back in 1991 and during this period
some other related developments happened which are closely related to each other namely the
development of internet of things or rather the development of the concept of internet of
things by Kevin Ashton in 1999. Then the Cyber physical system concept or CPS by Helen;
Gill in 2006.

All these referred to the idea that now the idea of personal computer has been changed from
one user one computer to one user many computers where computers are not treated as
computer rather they are treated as any other real like daily objects. And we just use them like
we use any other objects in our daily like. So we are actually using computers without being
aware of the fact that they are computers. Now this conceptual change happens in this
modern phase which is still going on.
(Refer Slide Time: 35:10)
So with that we have come to end of this first lecture to recap here in this lecture we learned
about what is an interactive system how it is different from other systems? What are the
issues that we should be aware of while going to design an interactive system? And what is
the basic idea of user centric design and a brief historical evolution of the field f user centric
design. The material that I have covered today can be found from this book have a look at
chapter 1 section 1.1, 1.3. So that is all for today see you in the next lecture thank you and
goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology, Guwahati

Module No # 01
Lecture No # 02
Introduction to Usability

Hello and welcome to the course design and implementation of human computer interfaces. So
today we are going to go for lecture 2 namely introduction to usability before we start we will
briefly recap what we have learnt in the first lecture in the previous lecture.
(Refer Slide Time: 01:11)

So earlier we talked about the very basic idea of interactive systems what it is and what are the
concerns while going to design interactive system? We also learned in brief the historical
evolution of the field and today we are going to talk about an important concept in the design of
interactive systems namely usability.
(Refer Slide Time: 01:40)
Now this course is all about design and implementation of human computer interfaces or
interactive systems so design is the key term here one of the key terms here. Now we already
have seen earlier the major design challenge when we are talking of interactive system. Today
we are going to elaborate a little bit on that major challenge from the point of view of a user
centric system designer. So what are the main concerns? In order to do that we will start with a
definition which will be beneficial for our subsequent discussion?
(Refer Slide Time: 02:29)

So it is a definition of the term human computer interaction so we are concerned here about
design and implementation of human computer interfaces a related term is human computer
interaction. So what it is? Human computer interaction is a discipline which is concerned with
the design, evaluation and implementation of interactive computing systems for human use and
with the study of major phenomena surrounding them. So this definition actually encapsulates
whatever we are going to learn in this course.
(Refer Slide Time: 03:17)

So the key thing to notice in the definition is that we are dealing with systems for use by the
human users. So effectively it points to the fact that we need to incorporate humans into the
design so that we can take care of their needs and expectations.
(Refer Slide Time: 03:40)
This brings us to the important consideration of human factors what it is and how they are related
to the design and implementation of human computer interfaces.
(Refer Slide Time: 04:03)

If you may recollect in our previous lecture we talked about designing for the layman users. Now
we also elaborated a bit on who are the layman users and how they are different from other users
of computers? Also it is important to note why to bother about such characterization why we are
trying to differentiate between users such as somebody are laymen somebody is non-laymen.
Why it is required?
(Refer Slide Time: 04:28)
Let us try to understand the need for such a differentiation with respect to an example.
(Refer Slide Time: 04:36)

Suppose we are trying to perform a railway ticket booking task here we may refer to a traveler or
an agent but the task is same booking a railway ticket.
(Refer Slide Time: 05:01)

So what the user is expected to do that is the first thing we should be focusing at the expectations
of the user.
(Refer Slide Time: 05:17)
So the user should be able to input the name of the station, check the availability of seats in the
train between stations. If it is available then the user should be able to book the tickets and
finally once the ticket booking is done he or she should be able to make payments. These are the
fundamental tasks that a user in this case a traveler or an agent is expected to perform in other
words the system is expected to help the user perform these tasks.
(Refer Slide Time: 06:00)

Now let us look at it from a different user’s point of view a DBMS manager or a database
manager who incidentally performs the database querying to get the same information from the
railway database. So here we have 2 types of user we are talking about one is a traveler or an
agent who is trying to get some information about tickets between station and trains. And another
user who is a database manager who is also capable of getting the same information using the
same database that is the railway database.
(Refer Slide Time: 06:54)

So the second user that is the database manager is he or she performing something different than
the earlier ones that is the traveler or an agent so are these tasks totally different?
(Refer Slide Time: 07:14)

If we look at it from a pure technical point of view they are performing the same task or same set
of tasks.
(Refer Slide Time: 07:23)

What are these tasks? So essentially what they are doing is querying the railway database? So
there is this railway database containing all sorts of information about train’s seat availability
ticket price booking status and so on. Now both the traveler or agent and the DBMS manager
both technically are querying the same database to get information for the same type of tasks.
Then both retrieves the information and both uses the information but for different purposes.
(Refer Slide Time: 08:11)

So what is different here they are performing same type of operations on same resource. So is
there any difference why should we differentiate between a traveller or an agent and DBMS
manager the difference is in terms of expectations and need of the user. So when the user is a
traveler or an agent his or her expectation and need are likely to be different than when the user
is a DBMS manager.
(Refer Slide Time: 08:50)

How so if you are a travel agent or if you are a traveller yourself then you are not bothered about
how the database is structured, organized, what are the languages to be used to retrieve the
information? What is the format of the information? How to interpret the format all these things
are not of any importance to you? Whereas these are important issues for a DBMS manager so
what you are bothered?

About is how to get the task done how to get the information about seat availability, about seat
price about trains, about booking status in some form which is understandable without any
specific knowledge required. So your expectation is that you will be getting this sort of
information in an understandable form which is also your need. Whereas for a DBMS manager
that is not the case for him or her, the information may come in different format through different
process and he may not be interested in knowing the actual information.

But how to use that information for some other purpose so the need is also different. So the first
thing that we should keep in mind while going for designing a human computer interface is
designing for whom who is the user? So the first thing is we should know the user that is very
important and crucial requirement for design and implementation of a human computer interface.
(Refer Slide Time: 10:35)

Now knowing the user is somewhat ill defined term so what do we mean by knowing the user?
So we can start by classifying the user into categories a very broad and simple categorization is a
3 way categorization of users. Note that here by the time user we are not referring to users like a
DBMS manager or someone who is technically sound. Instead we are referring to users like
traveler or travel agents who are quote unquote managers who need not know about the
technology behind.

So for such type of users we can divide them into 3 categories novice, intermittent and expert.
Now with this knowledge we will be able to actually build systems that will be more acceptable
to the particular user group.
(Refer Slide Time: 11:39)
How it helps? Again let us try to understand with another example so many of you if not all have
probably used a text editor to create a text document. Now while doing that often we need to
save our work how we can do that? If you have used any text document you know that there are
two ways to do it one is using a menu option where the save menu option is located in a drop
down menu typically.

And you need to select that with your mouse or through some other mechanism to save the
current work. Another option is you can use a key combination like control plus s together to
save it. So 2 mechanisms provided to do the same task one is using menu option other one is
using a hotkey combination in this case control and S these 2 keys pressed together will do the
job. Why that is so? Because anyone would have been fine but then I just mentioned so these
mechanisms are provided to cater to different user groups.

So when we are trying to use the menu based option we are trying to cater to basically the novice
users who may not know the hotkey combinations. So novice users are those who are first time
users of a system so every feature is not yet known to the user. Intermittent users are those who
as the name suggests occasionally uses the system so they may or may not be able to retain the
learnings during each use because they use it very infrequently although more than novice users.

Whereas expert users are those who frequently use the system now here the term expert does not
mean expertise in the background technology instead expertise in use of the system. So when we
are using a menu based option it is typically meant to cater to novice users whereas when we are
using a hotkey combination to perform a job like control and s to save that is typically meant for
expert users. So these different features are provided to cater to different user groups.
(Refer Slide Time: 14:25)

Now this is very important while going to design and implement a human computer interface we
need to identify the human factors and incorporate those in the design which requires knowledge
and expertise in many field of studies. So effectively what we are talking here is an
interdisciplinary field of study where we take help of knowledge and expertise from various
disciplines.
(Refer Slide Time: 15:00)
What are those disciplines? There are many but the important ones we can identify as computer
science is the primary discipline according to (())(15:07) definition. Psychology including
cognitive psychology that is another field human factors in itself it is a field then design
including industrial design, social science, anthropology, AI, machine learning, computational
linguistics.

These are only few of all the fields that may be involved in user centric design field which is the
primary concern in this course. But as I said although there are many fields involved our primary
focus will be computer science and engineering which is considered to be the primary discipline
in this case.
(Refer Slide Time: 16:10)
So the key concern here is how to consider the human in the design process?
(Refer Slide Time: 16:20)

Now to understand that we; should be also aware of different perspectives of design. This term
user centric design actually refers to different things to different stakeholders in different ways.
(Refer Slide Time: 16:47)
A typical creative designer to him or her, the term user centric design refers to the design of the
interface elements and layouts or in other words the creative design aspects the look and feel of
the design or of the system.
(Refer Slide Time: 17:13)

For a product designer particularly industrial product designer the term may refer to the form of
the product in other words the same, size, look of the product.
(Refer Slide Time: 17:27)
Similarly to an electronic engineer user centric design may actually mean adding more features
at the hardware level in terms of more sensors, smaller chips or a more power efficient battery
maybe so essentially some hardware features.
(Refer Slide Time: 17:57)

Similarly other stakeholders may view it in different ways but our concern here is from the point
of view of or the perspective of an application software developer. So this entire course is
actually meant to discuss how to build user centric software. So whenever we use the term user
centric system or human computer interfaces we are implicitly referring to a software product or
an application.
So our concern is the perspective of the application software developer who needs to follow a
development lifecycle that takes care of the user characteristics so as to better match the user’s
needs and expectations. So effectively what it says is? That from our point of view or the
application developer's point of view we should know about the development life cycle that takes
into account the users expectations and needs. How to do that? How to take care of users
expectations and needs in the development or in the software development lifecycle?
(Refer Slide Time: 19:19)

So that brings us to the important concept of usability.

(Refer Slide Time: 19:21)
In order to incorporate the factors or the users’ needs and expectations into the design of the
software we need an explicit measure to judge our design whether we have taken the factors into
consideration or not now this major is called usability. Let us learn more about this concept.
(Refer Slide Time: 19:54)

So it is a standard term there is an ISO standard definition of usability. Which; says that usability
is the extent to which a product can be used by specified users to achieve specific goals, with
effectiveness, efficiency and satisfaction in a specified context of use. So this is the ISO 9241-
210; 2009 definition of usability which is a very standard definition. So if you look at the
definition there are certain things that you should notice.
(Refer Slide Time: 20:52)
Namely 3 crucial aspects in the definition are the product is meant to be used by specified group
of users it is not meant for all. So that is a very important thing we should note that whenever we
are talking of a usable product we are talking of a product that should be used by a very specific
group of users and we are not talking about a product which is usable to all. So we need not
design a product as usable for use by all.

The second aspect crucial aspect is that the product should allow the users to achieve specified
set of goals again it is also very important to note that. If we are planning to put every
conceivable feature in a product so as to satisfy everybody that does not necessarily lead to a
usable product. A usable product by definition or by standard definition is supposed to satisfy
specific set of goals of the users.

So it is supposed to let the user achieve only specific set of goals it is not necessary that the user
can achieve every possible goals that he or she might have that is the second thing that we should
keep in mind.
(Refer Slide Time: 22:25)
There is a third crucial aspect also which says that the product should be designed for specified
context of use. In other words a usable product need not be so for all usage scenarios so we need
not try to design a usable product which can be used in any context. So it has to be usable within
some specified context of use not for every usage context.
(Refer Slide Time: 22:57)

Along with these three crucial aspects there are also 3 explicit measures that are mentioned in the
standard definition these are effectiveness, efficiency and satisfaction.
(Refer Slide Time: 23:17)
Jacob Nielsen in 2012 argued that usability alone cannot make a product useful. So there are 2
things one is usable other one is useful and we will distinguish between the 2. So usability is
about a perception that the product is going to be easy to use to the user whereas useful means
whether the product serves whatever the user needs to achieve. That is a very broad way of
distinguishing the two and according to Nielsen usability alone is not suitable to make a product
useful.
(Refer Slide Time: 24:09)

So according to Nielsen again so there should be 2 qualities in a product one is usability and the
other is utility together they make a product useful.
(Refer Slide Time: 24:27)

In addition Nielsen proposed 5 measures of or quality components of usability.

(Refer Slide Time: 24:37)

What are these 5 first is learnability that is the ease with which a first time or a novice user
performs basic tasks with the system so that is the learnability of a system.
(Refer Slide Time: 24:47)
Then comes, efficiency which is the speed at which the users can complete tasks typically
measured in terms of task completion rate.
(Refer Slide Time: 25:07)

Then memorability again the ease with which an intermittent or occasional user who returns to
use the system occasionally after some gaps can re-establish proficiency. But it says that for
intermittent users after one use there is a gap before the next use happens. Now by the time
whatever the user have learnt about the system may have been lost. So memorability quality
indicates how much of this learner can or the user can retain during the next use even if there is a
gap.
(Refer Slide Time: 25:56)

The fourth quality is errors or error rate which is the rate at which the users make errors. Along
with that the severity of those errors and the ease with which the users can recover from the
errors. So this quality errors actually contain 3 concepts one is the rate, one is the severity,
another one is the ease with which error recovery can be made.
(Refer Slide Time: 26:30)

And the final quality attribute is satisfaction or subjective satisfaction or user satisfaction that is
how pleasant is it to use the design.
(Refer Slide Time: 26:42)
Those are the quality attributes for usability on the other hand for utility the other attribute of a
system according to Nielsen it refers to the functionality that the design is supposed to serve. It is
a measure of the extent to which a design supports the functional needs of the users or in other
words how many features it support that actually serves the functional needs of the user?
(Refer Slide Time: 27:17)

Now if we compare Nielsen's framework to the ISO definition we observed that effectiveness
might be mapped to utility. So according to ISO definition effectiveness is one of the measures of
usability however if we compare it with Nielsen's framework we can roughly see the
correspondence between this major effectiveness and the definition Nielsen provided about
utility.
(Refer Slide Time: 27:47)

As a corollary to this comparison we can say that ISO definition therefore provided not 3 but 2
measures of usability efficiency and satisfaction whereas Nielsen's framework provided 5
measures of usability.
(Refer Slide Time: 28:14)

So it is likely that the 5 usability measures or quality components by Nielsen is likely to offer a
more precise measure. So accordingly we shall assume that these are the measures of usability
and we will subsequently use these to measure usability in our subsequent lectures. So that is in
brief what we can consider as usability so to recap we have this ISO standard definition which
talks about the nature of usability.

That is an usable product need not be designed for all or for all context of use or for all sorts of
tasks instead it refers to the fact that a usable product is supposed to be usable only for a specific
group of users working in a specific context and trying to achieve a specific set of goals. It also
says that there are 2 measures of usability whereas Nielsen's framework provides for 5 measures.
And we will go by the Nielsen's 5 measures as a more precise measure of usability.
(Refer Slide Time: 29:40)

Now with this knowledge now let us try to turn our attention to the concept of user centered
design.
(Refer Slide Time: 29:45)
Now this term user center design was first coined by Shneiderman in 1986. What is the objective
of this design process? The objective is to design products that increase usability. So when we
are talking of user center design so we are essentially referring to the fact that we want to
increase usability of the product by following this design approach.
(Refer Slide Time: 30:15)

Now this user center design approach indicates active or passive involvement of the end users in
the design lifecycle. So somehow we have to incorporate or involve the users in the development
process. Now that involvement either may be active that is the users are actively participating in
the design or it may be passive. That somehow we are taking user feedback in a passive mode
and then utilizing that to design the product.
(Refer Slide Time: 30:49)

There are few more related terms also related to this concept of user centered design one is
cooperative design proposed by Greenbaum and Kyng in 1992. Then participatory design
proposed in 1993 by Schular and Namioka then contextual design by Beyer and Holtzblatt in
1997. So all these terms are broadly referring to the same fact that we are involving the users in
the design process either actively or passively. Although there are minor methodological
variations involved but broadly they refer to the similar concept of user centered design.
(Refer Slide Time: 31:42)
There is also this ISO term used by ISO in its standards which is human centered design. So the
thing to note here is that all of them referring to the similar concept whether we are using the
term user centric design, user centered design, human centered design, and participatory design
cooperative design etcetera. What we are essentially referring to is that we are referring to a
process a stage by stage developmental process which involves the end users in the overall
development of the product.

Now this end user involvement may be active involvement that is the users are actively involved
in the development process or it may be passive involvement that is somehow we are collecting
input from the users and using that input to design and develop our product. So, how to do that
how to follow this user center design approach? Will; be the subject matter of our subsequent
discussions.

So with that we come to the end of this second lecture in summary what we have learnt today is
the important concept of usability and why we need to know it? Why it is important? To recap it
is important to cater to the need of layman users which are our primary concern in design and
implementation of human computer interfaces.

So if we do not make the product usable then it will not be acceptable to the laymen users so our
objective is to increase usability of the product and that is precisely what is called user center
design which term we have learned in our previous lecture. So here we gave a more formal
definition of this term and in subsequent lectures we will see how to implement this user center
design approach for development of human computer interfaces or user centric software
applications?
(Refer Slide Time: 34:21)

Whatever we have covered today the material can be found in this book you are requested to
refer to chapter 2 section 2.1 to 2.4.2 that is all for today thank you and goodbye.
 Design & Implementation of Human - Computer Interface
Dr. Samit Bhattacharya
Department of Humanities and Social Sciences
Indian Institute of Technology, Kharagpur

Module No # 01
Lecture No # 03
Engineering for Usablity

Hello and welcome to the NPTEL MOOCS course on design and implementation of human
computer interfaces. Today we are going to discuss our next topic that is engineering for
usability this is lecture number 3 in this course. So before we proceed as usual let us first
recollect what we have learned in the previous 2 lectures.
(Refer Slide Time: 01:12)

Earlier we have learned few things namely a general introduction to the field. So we have
seen what interactive system is and what are the core challenges in designing interactive
systems the issues and challenges? We have also briefly discussed the historical evolution of
the field of user centric system design and development. And we have also looked at the core
concern in the design of interactive systems namely the idea of usability.

So as I mentioned in my earlier lecture that our core concern here is to build interactive
systems that are usable. So we have to take care of the usability of the system. Today in this
lecture we are going to talk about how to do that? In fact, we will first learn the different
concepts related to implement user centric design approach for usable system design.
(Refer Slide Time: 02:43)
So our core design concern for user centric system design and implementation is design of
usable system. Now why we need it? We need it to cater to the needs and expectations of the
users remember. That here we are referring to layman users so our objective is to cater to the
needs and expectations of the layman users. If we are able to do that then we can say with
confidence that our system is usable.
(Refer Slide Time 03:19)

To achieve that what we need to do? We need to follow some sort of systematic approach.
There should be some step by step process to build user centric software. So that at the end,
whatever we get as output is a usable system.
(Refer Slide Time: 03:45)
Now this brings us to the concept of software development life cycle so software
development lifecycle or SDLC can be used to comprehensively capture and represent the
entire set of design and development activities. So we have to perform some activities to
design and develop a software now these activities together can be used to create a software
development lifecycle. So that these activities can be performed in a systematic manner.
(Refer Slide Time: 04:33)

So essential idea here is that we need to define stages of development for building the
software. And software development life cycles are nothing but the stage wise development
process followed to build a software.
(Refer Slide Time: 04:57)
Why this stage wise development is important? Because it gives us a way to systematically
look at the problem of software development. Let us try to understand the benefit of a stage
wise development process such as the one provided by software development life cycles with
an example. Suppose we want to create a calendar app a simple calendar for say a mobile
phone.

What we should do? If this problem is given to you, how you will start, where you will start,
how you will proceed, these are some of the concerns that will immediately come to your
mind.
(Refer Slide Time: 05:51)

First thing is of course we need to understand, what is required and then accordingly we
should go for design of the app so what we need? A grid like structure that is typically found
on a physical calendar. So all of us are familiar with a calendar at many places probably we
have seen it so there the dates are mentioned in the form of a grid similar thing we want to do
in our calendar app.

Along with the dates so there are headings representing name of the month’s. So that
information also we need to put in the grid like structure.
(Refer Slide Time: 06:41)

Now for each cell in the grid will represent a month. Now there are dates within a month so
for representing the dates or days, we need to create sub grid for each cell in the higher level
grid. So that is also required so create sub grids in each cell to hold the date or days. And
finally we need to render the entire structure on the screen. These are our requirements which
we have identified. Now to render it in the way we envisage the calendar there can be many
possibilities .
(Refer Slide Time: 07:30)
One more requirement can be there that is we may also highlight the current day and month
or the current date. That may be an additional requirement we would like to have in our app.
(Refer Slide Time: 07:50)

So there can be different ways to achieve this particular objective of having a calendar app.
One possible design can be like this, so here we are mostly concerned about design of the
interface how it looks like to the user? So we will mimic entirely the way physical calendars
are there so there will be this grid like structure so maybe a 3 by 4 grid representing 12
months. So each grid element is corresponding to a month for example January, February,
March. April and so on.

Within each grid element there can be sub grid elements representing the days of the month.
Since in a month there can be at most 31 days so we can have a sub grid of 6 by 6 structure
now to be able to hold maximum 31 days. So each sub grid element then will represent 1 day
of the month and in this scheme of things we can highlight the current date that is the day of
the month. This is one way to do things there can be other possible, so there is no unique
solution let us have a look at another way.
(Refer Slide Time: 09:43)

Now since we are building an app rather than a physical calendar we can utilize the flexibility
provided by a computing system and, we can mimic another way of designing physical
calendars, typically the tabletop calendars where we can change pages same idea we can
implement here. So on one screen we will have days for a month with swipe or with tap I can
go to the next or previous month like we change pages on a table top physical calendar.

So the entire screen will contain only the days for a particular month unlike in the previous
case. And here we will have grid where each grid element will represent one day of the
month. So with tap or swipe I can go to the next month or the previous month. And this
scheme can of course be implemented by considering the fact that when I am going backward
from January then I will end up in the last year or previous year. Whereas when I am going
forward from December I end up in the next year.

So accordingly the days can be chosen or designed, so this is another way of designing
things. In fact there can be a large number of alternative ways these 2 are not the only ways
possible so the next question comes is then if there are so many ways then how we can
actually decide which one to choose?
(Refer Slide Time: 11:50)
Our intuition may not be sufficient we probably have to take a systematic study of the pros
and cons of different designs to find out the best one among the possible alternatives. And
that systematic study is nothing but what we are referring to as software development life
cycles. So given a set of alternatives, it is possible to follow SDLC’s to determine the best
alternative that is one advantage of having SDLCs.

Apart from that of course there is this added advantage, that we can look at the problem in a
more systematic manner which will make things clearer and simpler to us to proceed.
Otherwise if we are dealing with building large software then the things will quickly become
messy if we do not look at it in a very systematic manner. And then it will be very difficult
for us to come up with a usable product. Having identified the advantages of software
development life cycles let us now learn a little bit on what are the different life cycles.
(Refer Slide Time : 13:10)
So there are actually many ways to look at the software development process accordingly
several life cycle models have been proposed over the years such as the waterfall model, the
spiral model, the evolutionary model and so on so we will have a look at some of these
models to get a better understanding of what we are meaning by software development
lifecycle models.
(Refer Slide Time : 13:46)

Let us start with the most fundamental of these models namely the waterfall model. This is
also the most well-known SDLC model although this is primarily used for pedagogical
purpose for teaching purpose rather than for actual software development. Now in this model
remember that we talked about software development life cycle to be a stage wise process for
building a software. Now in the waterfall model or rather the classical waterfall model there
are 7 such stages which we should follow to build a software.
(Refer Slide Time : 14:21)

First is feasibility study before we start on the software development process, we first need to
identify whether it is feasible whether we can proceed with the available resources, available
budgetary support, available manpower and so on? So that is the first stage of the process.
Where we first check for feasibility of the whole building process. If it turns out to be not
feasible then it is preferable not to proceed further or we need to modify our goals
accordingly based on availability of resources.

The second stage is requirement gathering analysis and specification. So we need to identify
what is required to build the software. Here the requirement is not in terms of resources rather
it is in terms of user requirements. So we need to identify and gather those requirements and
analyze those to find out what is possible to be implemented? The third stage is the design
stage here we go for designing the software.

Now later on we will see that the design involves 2 thing in the context of our focus. That is
human computer interfaces here design refers to both interface design as well as the design
of the system or code. Then comes coding or actual implementation of the system along with
that we may need to test the code also for identifying bugs and taking corrective measures
so coding and testing is the next stage.

Once unit level testings are done and codes are finalized. Then we go for integration of the
unit levels and then overall system testing and the final stage is deployment of the product. It
also includes maintenance as well which may be considered to be a part of this phase or can
be a separate stage. Now these 7 stages in different places you may find that they are
mentioned in different ways so for the sake of discussion in this course we will assume that
there are these 7 stages in the waterfall model.
(Refer Slide Time: 16:48)

Now when these stages are depicted they are depicted as kind of a waterfall. As shown in this
figure so first feasibility study next is requirement gathering analysis and specification. Third
is design, then coding and unit testing system integration and testing deployment and
maintenance. As you can see here either we can have 2 separate stages or single stage
covering both.

And the way it is depicted it appears to be like a waterfall so accordingly this name is given
to this particular way of looking at the software development process.
(Refer Slide Time: 17:32)
Now that was the classical model. Now waterfall model can also have an iterative version
where we can have iteration between the stages.
(Refer Slide Time: 17:45)

For example after feasibility study we go for requirement gathering analysis and
specification. There we may find that few things are not available. Then we may like to go
back to feasibility study. After design we may like to go back to requirement gathering stage.
After coding we may like to go back to design stage or requirement gathering stage. Similarly
after system integration and testing we may like to go back to coding stage or design stage or
requirement stage anywhere.

So this type of iterations can also be accounted for in the traditional or classical waterfall
model. If we are having iterations between the stages then it becomes known as iterative
waterfall model. So that is the basic idea about waterfall model.
(Refer Slide Time: 18:59)
Another software development lifecycle model is the spiral model let us have a look at this
model. Spiral model is actually a Meta model meaning it encompasses other SDLCS so it is
kind of Meta level SDLC.
(Refer Slide Time: 19:10)

So when graphically illustrated the model looks something like this. So there are 4 quadrants
identify objectives, risk assessment and mitigation develop prototype, customer evaluation
and planning. Now as you can see here each spiral covers all the 4 quadrant. So starting from
here it goes up to here that is one iteration then again it can start from here and till it covers
the 4 quadrants that is another iteration so on. So there can be unlimited number of iterations
as per the requirement of the development process.
(Refer Slide Time: 20:07)
So there can be multiple cycles each cycle is an iteration, so each spiral is one iteration. Each
iteration is divided into 4 phases or quadrants as depicted in the figure.
(Refer Slide Time: 20:28)

The first quadrant identifies objectives of the development of the product and the risks .So
objectives of the iterative phase are identified in this first quadrant of the iteration and also
risks associated with these objectives. These are also identified in this first quadrant.
(Refer Slide Time: 20:58)
In the second quadrant that is risk assessment and mitigation so the identified risks are
analysed in details. So in the first quadrant we have identified the risks those risks are
analysed in details and then steps are taken to reduce the risks. For example if there is a risk
of inappropriate requirement specification. Then a prototype system may be developed to
gather requirements which will mitigate this risk.
(Refer Slide Time: 21:41)

Third quadrant deals with the developmental phase. So in this quadrant we can go for
building or developing the product or the prototype. The earlier iterations and product was
the latter iterations after resolving identified risks. Also evaluate the product or the prototype
whichever is the case. So as I said there are multiple iterations so initially during the initial
iterations typically prototypes will be developed and during the latter iterations, when we are
almost coming to the end of the developmental process.
Focus will shift towards building of the product and during the iteration this product will also
be evaluated. If it is product the product will be evaluated. If it is prototype then the prototype
will be evaluated.
(Refer Slide Time: 22:48)

Then comes the fourth quadrant or the last quadrant. So here whatever results we have
achieved so far after evaluation with customer in the third quadrant, those results are
reviewed and we plan for the next iteration if required. So here we are primarily evaluating
the results achieved so far and plan for the next iteration if required. So these are the four
quadrants of a spiral model. As probably you have noticed by now spiral model is not a
fundamental developmental model like the waterfall model.

Instead it captures higher level concerns and activities that are required to implement a lower
level or fundamental level software development life cycle.
(Refer Slide Time: 23:54)
And through these iterations of the spiral progressively more complex versions or more
complete version of the software gets built that is the overall objective. So with these we get
some idea of what is the software development life cycle, so we discussed one fundamental
SDLC model and 1 Meta model to get some idea of what we mean by stage wise or
systematic development of a software.
(Refer Slide Time: 24:34)

Now our concern for building interactive software is that the software should be usable this
requires the developer to take users into account in every stage of the design in one form or
the other either in active form or in passive form. Now in order to do that if we go by straight
forward approaches then that will require lots of iterations.
(Refer Slide Time: 25:15)
Now these iterations although not impossible but it creates difficulty if we want to use a
traditional SDLC such as the waterfall model. That will create a problem as you probably
have noted when I was talking about the iterative waterfall model. So there between every
stages we probably need to iterate and it may be between 2 consecutive stages maybe far
away stages to take into account user feedback properly and completely.

So the resultant model when visualized will look messy and it will be difficult to follow. If
we follow the traditional models. In the next lecture we shall learn about an alternative model
for building interactive software which is although takes care of the iteration. But it does not
look messy as in the case of the waterfall model.
(Refer Slide Time: 26:45)

Whatever we have covered today you can refer to these two books to get more material on
these topics Rajiv Mall Fundamentals of Software Engineering as and Roger Pressman
Software Engineering of Practitioners approach. You may go through chapter 2 of the first
book or chapters 2 to 4 of the second book to get a better understanding of the development
process. And the process models that is all for this topic hope you have learned the basic idea
will meet again in the next lecture thank you and goodbye.
 Design and Implementation of Human-Computer Interfaces
Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology - Guwahati

Module No # 01
Lecture No # 04
Interactive System Life Cycle

Hello and welcome to the course design and implementation of human computer interfaces.
Welcome to lecture number 4, human computer interface development life cycle.
(Refer Slide Time: 00:58)

So in the previous few lectures we have learned about the field of interactive systems what are the
code design concerns in the interactive software development? And also we have got some idea of
software engineering life cycles or system development life cycle or software development life
cycles. Now these life cycles provide us a systematic way to think about developing a software
product. In this lecture we are going to learn the life cycle for interactive software development.
(Refer Slide Time: 01:40)
So earlier we learned about the waterfall model which is the most well-known and fundamental of
all the Software development lifecycle models. It consists of 7 stages 6 or 7 stages feasibility
study requirement analysis and specification, where we identify and specify the requirements
design, coding and code testing system integration and testing deployment and maintenance. So
with these 6 or 7 stages followed one after another, we can build and deploy any software that is
the idea.
(Refer Slide Time: 02:30)

Now our concern is software to be used by layman users. As we have repeatedly emphasized this
brings us to the concept of user centric or user centred design, where the software that we develop
should be easy to use in other words it should be usable for the intended users.
(Refer Slide Time: 02:58)
Now the classical waterfall model if we want to follow those stages to build user centric software,
the model actually creates a problem. Because our core concern here is usability in order to do
that, we have mentioned earlier that we need to take into account the users either in active mode
or in passive mode. Now taking into account the users is not explicitly the concern of the waterfall
model. Instead the model is designed to build efficient systems rather than usable system.
(Refer Slide Time: 03:53)

So what kind of problem it creates in order to develop user centric system. We require iterations
between stages because that is required to take into account the feedbacks we receive at each stage
of the design.
(Refer Slide Time: 04:20)
Now if we want to do that with the classical waterfall model then the model becomes rather
messy.
(Refer Slide Time: 04:27)

For example suppose, this is a linear flow of the process from feasibility study we go to
requirement stage then design stage, then coding, stage integration, stage deployment and
maintenance stage. Now in case of user centric approach we need to take into account users in
every stage now suppose in design stage. We find out user input which does not match with the
requirement specification we have obtained in the previous stage then we may have to go back to
this stage after coding while going for testing.
We find out some issue then we may have to go back to this stage. We may also need to go back to
this stage directly rather than going in the design stage after again system testing, we may need to
go back to unit level or design or requirement stage. So; too much iteration which makes it
difficult to visualize the overall process and creates confusion in the mind of the developer in
order to handle that we can refine this life cycle to suit our purpose.
(Refer Slide Time: 05:58)

So this figure illustrates such a life cycle for implementation of user centric design approach. Like
waterfall model it has several stages starting with the feasibility study. We have requirement
gathering analysis and specification stage now. From this stage we go to a design prototype
evaluate cycle stage. Here there are 3 sub stages design, prototype building and early evaluation
these 3 are connected in an iterative cycle.

Once that cycle stabilizes that means, we do not find any more issues to be resolved based on user
feedback, we can go for implementation, we come to the coding and implementation stage once
that is done, and we go for code testing. Now after code is tested that means our system is
executing as per our requirement. We need to go for another user testing which we are calling
empirical study or empirical research.

So in this stage the system is not tested for code efficiency. Rather it is tested for usability. Based
on the findings in this stage it may be possible that we go back to this cycle. Similarly based on
the findings in this cycle, it may be possible that we go back to requirement stage and the last
stage is deployment and maintenance like waterfall model.
Now this design prototype evaluate cycle to requirement gathering stage this cycle may be
required based on the outcome of this evaluation but still it is not very frequent it is expected to be
not very frequent. Similarly from empirical study we may have to go back to design prototype
evaluate cycle which again is expected to be infrequent although may still be required to refine
our designs. So the needs of building an usable software may be taken care of with the help of
these types of life cycle model. Let us briefly have a look at different stages of the life cycle.
(Refer Slide Time: 08:53)

Now in the requirement gathering stage since we are dealing with human computer interfaces. So
here we need to identify requirements from the user’s end users or layman users. Rather than only
the customer or client of the product that is very important accordingly we have to deploy
different techniques. Those are used to capture end user requirements such as contextual inquiry
ethnographic studies, cultural probes and so on.
(Refer Slide Time: 09:30)
Next comes the design prototype evaluate cycle so it involves 3 sub stages design building
prototype based on design and early evaluation. Now why this loop is required? It is required so
first we go for a design based on the requirement. We identified now this design is prototyped and
again user feedback is taken based on the feedback. It user feedback or some feedback is taken in
the early evaluation stage.

Based on the feedback we refine the design again go for prototype building. And so on till we find
out that no further changes in the design is required. That means the design has stabilized so at
that point we break the cycle and go to the next stage of coding and implementation. So in this
cycle it is expected that there will be much iteration accordingly; our early evaluation and
prototyping should be simpler to carry out. So those should be quickly achievable. So that less
time is required to build a prototype or to evaluate a prototype.
(Refer Slide Time: 11:01)
Now one thing we should note here, when we are talking of design, 2 concepts are involved. One
is design of the interface that is design of the interface and interaction from the point of view of
the end user. In that design nothing related to implementation or coding is involved. And when we
are talking of building prototype and quickly evaluating, we are actually referring to the design of
the interface and interaction.

So we first design the interface and our interaction to build a prototype get those prototypes
evaluated quickly refine our design and so on till we find out no more refinement is required in
the design of the interface. And interaction once that design is stabilized then we designs the code
or how to implement the system. We go for that design so that is also implicitly involved in this
cycle. Although that design of code is also iterative but that iteration does not require end user
feedback instead those iterations are performed within the design team.

And their prototype is not necessary so essentially that iteration involves designing the code and
evaluation by team other team members or brainstorming. To refine the design conceptually 2
different cycles are being mentioned. In this stage one is interface design and the cycle associated
with it. The other one is code design and the cycle or iteration associated with it. So the entire
cycle of design prototype early evaluation is important for interface design. To take into account
user input whereas for code design prototyping is not required and evaluation is basically
brainstorming within design team.
(Refer Slide Time: 13:25)
Then comes implementation, so now we are talking of implementing the code design that we have
achieved in the earlier stage. Now implementation can be done in traditional way that is by
writing code and testing the code or debugging the code. So here one thing to be kept in mind is
that before we go for implementation we try to get as good a design as possible. So that we do not
need to modify the design later then it will involve changing the code also which is technically
costly in terms of manpower.
(Refer Slide Time: 14:10)

So along with code we need to test for the code so there are standard techniques available the
other important stage is empirical study. So once the system is implemented and code is tested that
means the system gets executed without any flaw. We still need to know whether this overall
product is usable or not code testing will not give us that knowledge instead what we need to do is
to get it tested with the end users again.

And that requires a systematic and scientific approach which is generally called empirical research
or empirical study. So this is required to ensure that the product conforms to the usability
requirements. And this is not an ad hoc process it requires systematic testing approaches. But
these testing approaches are totally different from what we have employed for prototype testing or
code testing.
(Refer Slide Time: 15:23)
Again the earlier stages are very important because empirical study is also a costly affair .In terms
of time resource manpower cost. So we should ensure that before going for empirical study we
should ensure that the implemented product is as good as possible. There should not be too many
problems otherwise; we have to repeat this loop multiple times it can be repeated once or twice.
That is still acceptable but if we have to do it multiple times because the earlier stages we did not
do properly then that increases the cost as well as turnaround time of the overall system.

In fact it may lead to non-delivery of product also so to summarize, we have discussed a software
development lifecycle that is tailor-made for user centric design implementation. It involves
important cycles these cycles are important to take into account user feedback and ensure that the
product is usable. In subsequent lectures we will go through the details each of these stages.
(Refer Slide Time: 16:52)
Whatever I have discussed in this lecture can be found in this book. You are requested to refer to
chapter 2, section 2.1 to 2.4.2. So that is all for this topic looking forward to meet you in the next
lecture thank you and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology, Guwahati

Module No # 01
Lecture No # 05
Usability Requirements

Hello and welcome to the NPTEL Mooc’S course on design and implementation of human
computer interfaces. We are going to start a new lecture number 5 on the topic of usability
requirements. So essentially it will deal with how to gather requirements to ensure that our
product is usable here by product we mean a software application.
(Refer Slide Time: 01:21)

Before we start again as usual we will quickly recap what we have covered in the earlier lectures.
So we have talked about interactive systems, which is our core concern here interactive systems
and human computer interfaces will be using simultaneously and synonymously. So that term
human computer interface will be used synonymously with interactive systems and most of the
time we will be using the term interactive system for brevity which will refer to human computer
interfaces.

Now when we are talking of interactive systems essentially what we are referring to is a software
system which will be used by layman users. So earlier we have learned what are these systems
why we need to be extra causes while designing these systems? What are the things that we
should consider while designing such systems? In particular we have focused on the crucial
concept of usability.

Now in order to ensure that an interactive system is usable what we should follow that also we
have briefly discussed in our earlier lectures. So essentially what we mentioned is that there has
to be a systematic and stage wise process to develop an interactive system. Now this systematic
development process we are referring to as software development life cycle. So we have seen
one such software development life cycle tailored to cater to the need for development of usable
interactive systems.
(Refer Slide Time: 03:25)

Let us quickly have a look and recap the development life cycle as I mentioned earlier. So we
will be focusing on the individual stages of this life cycle throughout this course the details of
these stages will be the main content in this course. So what are the stages there present in the
interactive development life cycle? First stage is feasibility study where we first try to see
whether the development process is feasible or not with respect to the available resources that
includes manpower, cost, time computing resources and so on.

Once it is found to be feasible we go for the second stage that is requirement gathering analysis
and specification. In this stage we try to gather requirements end user requirements which will
help us develop a system that is going to be usable. Once that is done we enter into this design
prototype evaluate cycle. So, these 3 together constitute a stage now these sub stages in this stage
work in a cycle.

So first we go for designing the system particularly the interface and interaction that design is
prototyped for quick feedback on the quality of the design and usability of the design. Based on
feedback we refine the design then again refine the prototype or create a new prototype for the
revised design. Which again is evaluated and this cycle goes on until we reach a stage where no
further changes in design is required.

So once we stabilize on the interface and interaction design or rather once we finalize the design
then we go for code design. So essentially we have to build software so we need to design the
system so from the design of the interface and interaction we convert it to design of a system or
the code design part. That design is then implemented and the code the executable code that we
have implemented is then tested in subsequent stages.

Once the testing is over and we get a working system we then have to go for a final round of
usability study for the product that is an elaborate process which generally is termed as empirical
study or empirical research. In this stage it is possible that we may find some more issues with
our design of the interface and interaction. So it may require us although infrequently but still
sometimes we may need to go back to this cycle to refine our design and then again recode retest
and then finalize the product.

So once finalization of the product is done then we go for deployment of the product and also go
for maintenance. So that is in brief the life cycle stages for an interactive system.
(Refer Slide Time: 07:34)
Now in our discussion on these stages we will skip the first stage that is feasibility study we will
not spend much time. We will assume that whatever we discuss is on the basis of the assumption
that the further development is feasible already that is found out to be feasible. In light of that we
will start our discussion so first thing that we will discuss is the first stage after feasibility study
that is requirement gathering, analysis and specification.
(Refer Slide Time: 08:20)

So essentially we are starting our discussion on the life cycle stages with the second stage here.
Now note here that the term requirement actually is referring to usability requirements rather
than system level requirements we shall see the difference in subsequent discussion.
(Refer Slide Time: 08:39)

So once we try to understand the requirements for usability we have to keep in mind that here we
are talking of requirement gatherings from the point of view of user centered design or user
centric design. So the other approaches where user centricness is not so prominent we can refer
to it as system center design. So we throughout this course we will distinguish between these 2
approaches one is system center design or the traditional design of a software and other one is
user centered design or design where users concerns are explicitly taken into account in the end
product.

Why because we want to have a usable system where the system will be usable for lay persons or
layman users.
(Refer Slide Time: 09:50)
To highlight the difference let us see an interesting example. So probably some of you or many
of you may be aware of this famous comic character which is called Dilbert. Now this comic
strip is taken from one of this Dilbert's series so, here this is the Dilbert figure the character and
this person is his boss. Now Dilbert is a software engineer or IT engineer and he is tasked to
create a system.

Now as an engineer or developer he is asking his manager for opinion. The first way to develop
as per his Dilbert's opinion is that the system could be designed with a simple point and click
interface. That means Dilbert is time trying to convey the message that it should be simple to use
for the end user. It is also possible as per Dilbert to create a system where the user need to choose
among thousands of poorly documented commands each of which must be typed exactly right on
the first try.

Also in such a case if the customers face some issue then as engineer or developer they will
never meet a customer, ourselves to understand their needs expectations problems. And so on it
appears that the manager is supportive of this idea and he also adds along with this complexity in
the system that, make the system so. So that the customer have to reboot or the user have to
reboot after every typographical error.

So essentially what it says is that as an engineer Dilbert finds it more interesting to build a very
complex system which need not take into account the user’s needs, expectations, characteristics
because the engineer will never meet the users and the manager is supportive of that idea. So this
comic strip essentially indicates that developers may be having a tendency to go for a design or
development of a product in a way such that it is not correlated with the user characteristics.

Developer may like to develop as per his or her own or the teams own understanding of the user
rather than actually studying the user.
(Refer Slide Time 13:35)

If such an approach is taken which we are referring to as system center design the main concerns
of the developer are what can I as a developer? Easily build on this platform rather than what is
required by the user. What can I as a developer create from the available tools rather than catered
to the user’s needs and for that if required create new tools? What do I as a programmer find
interesting rather than which where to write a program or add features will help the users?

So essentially the concern is about the developers own expertise skill and interest rather than the
user’s needs this is what we are referring to as system center design. Where the requirements
from the user sides are not considered at all rather the requirements are framed to support the
skills expertise and interest of the developer.
(Refer Slide Time 14:46)
In contrast to this approach we have user center design where the design is supposed to be based
on a user's abilities, context, goals or needs. So these are crucial considerations here that what the
user is capable of doing what are their goals or needs and what is the usage context? The crucial
difference here with the system centered approach is that these considerations are not based on
only the programmer’s convenience rather these are based on the user’s actual requirements.

So we will clearly distinguish between these 2 approaches one is whatever programmer feels
required another one is whatever are actually required by the users.
(Refer Slide Time 15:40)
To understand this further let us go through 1 example scenario recall the calendar app which we
discussed in our earlier lectures. For this calendar app if you are asked to gather requirements
what kind of requirements you are going to gather what will constitute requirements? So first
question is what; are the requirements and how to gather that? In other words when we are
saying that calendar app is an interactive system and we want to build it through stages where the
first stage is requirement gathering analysis and specification. So first thing we should try to
answer is what are the requirements for the calendar app?
(Refer Slide Time 16:40)

Now note that the calendar app the way we discussed is a mobile app so let us try to see what can
be the requirements? When somebody asks you what are the requirements immediately few
questions may come to your mind. One of those may be we need to develop it for a mobile
platform or for mobile platforms. Can we call it a requirement that it needs to be developed for
mobile platforms we shall see.

Another question that may come to your mind while thinking of requirements for calendar app
may be what programming language are we going to use? Is it java or shall I develop with java
scripts or shall I develop with something else? Can I call this a requirement for building the app?
Let us consider a third question which may come to some of our minds? How we are going to
store the various, information needed?
For example reminders special events so in a calendar along with the date display we may like to
add or show to the user special events such as reminders for classes, quizzes, exams or special
events. Now in order to do that what kind of storage technique I should use? Should; I go for
RDMS tools where RDMS stands for relational database management system. So some RDMS
tools should I use for example should I use my SQL which is one of the DMS tools now if this
type of question appears can I call it a requirement.

So we are seeing 3 possible queries or questions that may come to our mind when we are asked
to find out requirements for developing the app. First one is related to platform we need to
develop it for mobile platform should it be considered as a requirement. Second is programming
language to be used to build it should it be considered as a requirement? Third is the storage
technique to be used and the question is should I consider it as a requirement.
(Refer Slide Time 19:33)

These 3 are not obviously the exhaustive list of questions that may come to our mind there may
be many more. Now how do we know whether these are or these questions qualify as
requirements to build the system?
(Refer Slide Time 19:53)
In fact the 3 questions that we have seen do not qualify as requirements why?
(Refer Slide Time 20:07)

Let us see among these questions some are related to feasibility of the system whether the overall
project for building the app is feasible or not. For example the first 2 questions that we have
mentioned are actually related to feasibility we need to develop it for mobile platforms. So that is
actually a part of the feasibility study stage rather than is a usability requirement. Also what
programming languages we should use that depends on the kind of manpower available and their
skill.
So again that is of part of the feasibility study stage where we study about the available
manpower resources etcetera. So this is again not a requirement as such when we are talking of
requirement we are implicitly talking of usability requirements, usability has nothing to do with
platform or programming language. So these are or these cannot be considered as usability
requirements or requirements which we are trying to find out in this lecture.
(Refer Slide Time 21:29)

There may be some queries which are more related to the design phase rather than requirement
phase. For example the third question that we have discussed how are we going to store the
information should we use some RDBMS tools? This actually relates to the design of the system
rather than requirement for the system. So while going for identifying requirements we should be
very careful whether what we are identifying are related to the feasibility of the project or design
of the system or testing of the system so everything is not requirement.

Requirements are different than what we are what probably immediately comes to our mind so
we should be very careful.
(Refer Slide Time 22:36)
So what is our objective then? Our objective is to identify requirements that ensure usability.
That is our core objective we need to identify only those requirements that ensure usability other
things that we identify are not related to requirement identification stage. Also along with
identification of requirements in this stage of requirement identification or rather requirement
gathering analysis and specification.

So there are 2 more components analysis and specifications so whatever usability requirements
we gather or identify we need to analyze them so that we can convert them to some specification
system specification. Which will make it possible to design and implement the system, so first
thing is we need to identify the requirements and second thing is we need to convert it to some
system specifications.

So that the next stages can be carried out namely design and implementation of the system. So
there are 2 objectives one is identification one the other one is specification which involves
analysis of the identified requirements.
(Refer Slide Time 23:58)
So then what we need we need to gather the requirements and we need to analyze and specify the
requirements these 2 things we require.
(Refer Slide Time 24:10)

Now one thing we should note here so when we are talking of usability requirements these come
under non-functional requirement. Later on we will see that there is another type of requirement
when we talk of system development particularly software system development that is functional
requirement. However usability requirements are typically considered to be under non-functional
requirements. So essentially we are trying to gather one type of non-functional requirement
namely usability requirements.
(Refer Slide Time 24:45)

So before we proceed further let us quickly learn about this concept of non-functional
requirements. So when we are talking of building a system so obvious thing is to identify what
we need to build that is requirement gathering. Now we have already seen that some things need
not be requirements they may be part of other stages of the development. However whatever are,
part of requirements can broadly be divided into 2 categories functional and non-functional.

So we will talk about first non-functional requirements because we are primarily concerned
about usability requirements.
(Refer Slide Time: 25:34)
So what are non-functional requirements? These are system characteristics that cannot be
expressed as functions now. When I say functions this is a loosely used term but it refers to the
general concept that whenever there is a function it takes some input and produces some output.
So if a requirement can be specified as a function where there is some well-defined input and
well defined output then we call it as a functional requirement.

When we cannot do that then we call it as a non-functional requirement. Typically such

requirements are related to the quality attributes of the system or the software.
(Refer Slide Time: 26:30)

Now these non-functional requirements can be of different types so there are few broad
categories of non-functional requirements. We have performance related non-functional
requirements, operating constraints which are considered to be non-functional requirements.
Economic considerations these are also non-functional requirements, life cycle requirements,
interface issues.

So these 5 broad categories of requirements are generally considered to be non-functional

requirements or NFRS. Among these our core concern is usability requirements which comes
under this fifth category of interface issues but let us also try to get some idea on the other
categories.
(Refer Slide Time: 27:36)
So the first one is performance related non-functional requirements there can be many such
non-functional requirements. One is reliability which says that how to ensure that the product is
reliable how we can ensure that. Security is another performance related non-functional
requirement and which typically refers to the things that are required to make the product secure.

Then response time another performance related non-functional requirement which includes
ideal response time and practical times. So, broadly these 3 can be considered to be performance
related, reliability, security, response time.
(Refer Slide Time: 28:37)
Then comes; the second category that is operating constraints so one of these is physical
constraints the size of the system. Then availability of personnel to maybe maintain, develop the
system, skill level considerations again to develop and maintain the system. These are few things
that we need to consider while building the system also system accessibility for maintenance. So
the extent of accessibility which is required to maintain the system that also comes under
operating constraints.

So these things actually we need to specify as requirements while delivering the product. Like
the size and how to manage then available personal skill set accessibility. So, that it can be
smoothly developed maintained updated and so on.
(Refer Slide Time: 29:59)

Then comes the third category economic consideration here the non-functional requirements
relate to immediate and or long term costs for design development and implementation these
three things. So, essentially these are also required to be specified as non-functional
requirements.
(Refer Slide Time: 30:31)
Fourth category is life cycle requirements under this comes the design quality requirement for
the design quality. Here by design we mean the design document that is obtained after the design
stage both designed for interface as well as design of the code. So this quality of the design is
measured in terms of maintainability of the design, enhance ability of the design, portability of
the design and so on. So we need to specify the requirements in terms of these measures
requirements for the quality of the design.
(Refer Slide Time: 31:24)

And finally comes the fifth category of non-functional requirements namely issues related to the
interface here we may add. That this is not only interface so whenever we are using the term
interface we are referring to 2 conceptual things one is interface one is interaction so this is
related to interfaces as well as interaction. Now this nfr deals with how system is to interface
with its environment users and other systems.

So it is not only related to user interfaces but also interfacing with its environment as well as
other systems. So it includes specification of this particular non-functional requirement includes
external system interface in terms of hardware and software requirements or in other words
peripheral devices or API’s. So how to interact with the external systems and usability
requirements that is what are the requirements to make the system usable.

So, these 2 comes under interface issues related non-functional requirements so our focus is on
the usability aspect of the interface issues.
(Refer Slide Time: 33:09)

So to repeat here we are dealing with interactive systems that are to be used by non-expert users
or lay persons and for them usability is very important. So we need to ensure that the system is
usable so that lay persons find it easy to use. And our whole objective for this stage of
identification of requirements is centered around; identification of usability requirements.
(Refer Slide Time: 33:41)
So in subsequent lectures we will see what we can do to identify usability requirements but
before going to that let us first discuss what are the advantages; of specifying non-functional
requirements. So if we specify this that then that ensures that software follows legal and
adherence rules these are very important to maintain some standard. It also ensures a product that
is reliable, available on demand; ensure performance as well as scalability of the system.

So if we specify non-functional requirements then these are ensured because we are specifying
what is expected out of the product it also helps us construct security policy of the product. So
these are obvious because the corresponding non-functional requirements are to be specified.
Together all whatever we have mentioned ensures that at the end we get a product which
achieves good user experience and ease of operating the software by the user as well as the
technicians who are tasked to maintain the software. Both are ensured if we specify
non-functional requirements properly those are the advantages.
(Refer Slide Time: 35:34)
Now if we do not do that then what are the disadvantages it may lead to unsatisfied users or
clients or both as well as unsatisfied developers. So developers will not be given clear idea of
what they need to develop then at the end if they are told that whatever they have developed does
not mean meet certain requirements then definitely that will not be very satisfying for them. So
at the beginning stage all these non-functional requirements should be clearly specified as much
as possible.

Not specifying the non-functional requirements properly or clearly may also lead to inconsistent
software which is not a desirable outcome. Also not doing so in time may lead to time and cost
overrun to fix certain issues later; which of course is not a desirable outcome because we did not
specify the requirements earlier. So we need to fix it later so then that leads to time and cost
overrun and it may even lead to not delivering the product at all total wastage of time and cost.

So these are significant and severe consequences; of not specifying non-functional requirements
in time or before the development begins. So we got some idea of what we want to gather? We
want to gather usability requirements; which is one sort of non-functional requirements.
Non-functional requirements are of many types usability is only one of those but as we have seen
in developing a product software product we need to specify non-functional requirements
properly so that later on we do not face any issue.
(Refer Slide Time: 38:02)
With that brief introduction to non-functional requirements we conclude this lecture and in the
next lecture we shall continue discussion on how to gather usability requirements. So we will
focus only on usability requirement gathering rather than gathering of other non-functional
requirements. Along with that we shall also learn in details how to specify such requirements.
Specify in a way so that it becomes easier to convert the specification to system design.

Now that specification is generally called as functional requirements. So we shall also learn
about functional requirements in subsequent lectures.
(Refer Slide Time: 38:53)
So that is all for this lecture whatever topics we have discussed today may be found in these
books. So for further information you may refer to these 2 books fundamentals of software
engineering or the second book software engineering a practitioner's approach. In the first book
you may refer to chapter 4 whereas in the second book you may refer to chapters 7 and 8 to get
more information on these concepts.

So with that I would like to conclude this lecture and hope to see you in the next lecture soon
hope you have got some idea on the concepts that we covered today thank you goodbye you.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology, Guwahati

Module No # 02
Lecture No # 06
Contextual Inquiry

Hello and welcome to the NPTEL MOOC’S course on design and implementation of human
computer interfaces lecture 6 on usability requirement gathering. So we are currently discussing
on the starting stage of interactive system development life cycle namely requirement gathering
stage where our emphasis is on gathering usability requirements. Note that we skip the first stage
feasibility study and we started with the second stage of life cycle namely requirement gathering
analysis and specification stage.
(Refer Slide Time: 01:33)

So we already learned about the idea of usability and its importance in interactive system
development life cycle. In this lecture we are going to learn about one approach through which
we can gather usability requirements for building and interactive system.
(Refer Slide Time: 01:57)
Just to recap we are currently in the requirement gathering stage we are currently discussing
topics related to this stage. And in this course in subsequent lectures we will cover the other
stages as well. So there are many stages in the interactive system development life cycle first
stage is feasibility study which we are not covering in details here. We are currently in the
requirement gathering stage then we have this design prototype evaluate cycle.

Involving the design stage prototyping stage, evaluation stage and design involves both interface
design as well as code design. Then we have this coding and implementation stage testing of the
code. A final stage to again ascertain the usability of the overall system through empirical study
and then, finally deployment and maintenance. So other stages will come in subsequent part of
the lecture currently we are focusing on requirement gathering stage.
(Refer Slide Time: 03:21)
So in this lecture we are going to learn about one specific approach to gather usability
requirements from end user which is called contextual inquiry.
(Refer Slide Time: 03:38)

So before we go into the details let us recall that in the conceptualization to implementation of
interactive system one very important aspect is knowledge about the user. So we should have the
motto of know thy user or know the user here by the term user we mean end users or laymen
users.
(Refer Slide Time: 04:11)
And again there is a definition for usability which would like to recall at this stage before going
further into the discussion on contextual inquiry. That is the ISO definition of usability which is
the extent to which a product can be used by specified users to achieve specified goals with
effectiveness, efficiency and satisfaction in a specified context of use. So the standard definition
categorically talks about specific group of users who wish to achieve specific goal in a specified
context of use that is the definition of usability.

So here note the term specified context of use so we have to somehow capture the use context
before we can think of building a usable product. So which will be the context of use of the
product along with who are the users and what are their goals. All these considerations we need
to address or we need to keep in mind before we aim to build a usable product.
(Refer Slide Time: 05:46)
Now let us come to the main topic of this lecture that is contextual inquiry so this is one of many
methods available to gather end user requirements for usable product development. So this
whatever outcome we get after the inquiry process is over after the contextual inquiry process is
over those outcomes can be equate it to usability requirements. And this is not the only method
but one of many such methods available together usability requirements.
(Refer Slide Time: 06:29)

Now the method as such is not very new so its importance in user center design was highlighted
way back in 1988 about more than 30 years ago. When the graphical user interfaces, and the
personal computers were dominating the same. At that time this technique used to be referred to
as phenomenological research method and by the end of the nineteen nineties it became well
developed and quite popular together end user requirements.
(Refer Slide Time: 07:15)

Now the same method is often referred to as a form of semi-structured interview or

semi-structured interview process. However it may be somewhat misleading because contextual
inquiry is not only an interview instead in contextual inquiry we have 2 things involved one is
interview and the other one is observations. Observations are the primary method used here
along with that interviews are used as a supporting mechanism of observations. So if we are
simply referring to it as an interview then that may be misleading.
(Refer Slide Time: 08:07)
So in contextual inquiry process the primary objective is to watch and observe the users while
they are performing tasks in their natural work setting or in other words the work context. So in
contextual inquiry what typically is done is that users are asked to perform their regular activities
in their natural work settings and their behaviour; are closely observed during their regular
activities.

Now during observations the observer may ask users queries or questions to clarify certain
behavioral issues or certain activities. So during observations the observer may note some
behavior or activities; which is not very clear and at that point of time the observer or in a later
time the observer can ask the user about more clarification of the particular behavior or the
activities. So in that sense interview acts as a supporting tool in the overall observation process.
(Refer Slide Time: 09:34)
Generally the contextual inquiry process continues for 1 to 2 hours along the duration may be not
very desirable because the users may not like to participate in the process for more than 1 to 2
hours. And also for a longer duration observations the observations may reveal similar things
without much gain in behavioural knowledge.
(Refer Slide Time: 10:10)

So what is the purpose now these observations that are made during the inquiry process which
include interactions with the users in form of interviews. Enable the designers of the interactive
system to learn about the task domain, work culture and physical and social constraints that are
prevalent at the workplace. So various idiosyncratic attributes of the workplace with respect; to
the user behavior and participation can be learned through these observations.

Now this knowledge is very important because the designer should be aware of the specific work
context which is part of the definition of usability. So by these observations the designer can
become knowledgeable about the specific work context and accordingly will be able to design
usable product.
(Refer Slide Time: 11:28)

In; order to understand the importance of observations in the development of usable product. Let
us recollect our calendar app example that we mentioned in our earlier lectures.
(Refer Slide Time: 11:47)
Now suppose the target group of users, are identified as the managerial staff of some
organization. So we have pinpointed the user group they are the managerial staff of some
organization and we made some observations about their behavior during their working hours.
(Refer Slide Time: 12:17)

Without any knowledge about the intended user behavior particularly in their work settings we
can come up with all sorts of possible calendar designs as we have already discussed earlier. So
earlier we discussed couple of alternatives for the design of the calendar app but their; these were
done based on our intuition rather than any specific knowledge about the target user behavior. So
that is likely to be the case if we do not have any specific knowledge we will end up with many
alternatives.
(Refer Slide Time: 12:59)

However in contrast to that suppose we now performed a contextual inquiry and observed that
the intended users perform 2 important activities during their working hours set meeting dates
and set reminders. Suppose we have observed this that they quite frequently perform these
activities then with this knowledge when we are going to develop the calendar app we know
what features to be kept in the app. So that it becomes usable to the target group of users namely
the managerial stuff.

So if we do not keep these features then the calendar app will not be very much usable to the
intended users because they anyway perform these activities and they have to take request to
other tools at their disposal to perform these activities. But if we keep the same as features in our
calendar app then they do not need to use other tools they can directly use the app and using
those features they can perform their activities.

So it will make the product more usable to that particular user group and the idea of this feature
comes from observing their behaviour in their work settings.
(Refer Slide Time: 14:35)
So that is the importance of having performed contextual inquiry before embarking on the design
of the system. So with that we got some idea of what is contextual inquiry? To repeat this is an
observation based approach to gather end user requirements where we observe the users in their
natural work setting. And observation can be supported by unstructured interview. The observers
can ask queries or questions to the users to get more clarification on certain behaviour or
activities that they might have observed during the contextual inquiry process.

Now the contextual inquiry can be performed in different ways so broadly there are 2 ways to
perform contextual inquiry.
(Refer Slide Time: 15:38)
The active mode and the passive mode in the active mode the observer is physically present in
the work setting where the users are being observed. So observer is physically present and
captures the observation in some form either handwritten notes or videography or something
whichever the observer feels comfortable with he or she captures the observations.
(Refer Slide Time: 16:22)

In passive mode the observer is not physically present instead the user activities are recorded or
videotaped and the observer reviews those videos or recordings at a later time. So in active mode
observers, are physically preset and observes in passive mode some setup is used to record user
activities and those recordings are observed later by the observer.
(Refer Slide Time: 16:57)
One crucial thing to note here is that contextual inquiry is not about lecturing the user what to do
and what not to do? Here during the inquiry observers should act as apprentice or trainees and
treat the users as masters. So this master apprentice model is a quite popular model to perform
contextual inquiry here it is assumed that the users are masters and the observers need to learn
from the users.

So they should act as apprentice for the purpose of learning from the users learning their
behavior. So purpose is to learn from users their behavior rather than to teach them how to
behave in a work setting. So occasionally there may be a tendency in the observers to teach or
lecture the users about how to do things while they are observing user behaviour so this should
be strictly avoided.
(Refer Slide Time: 18:12)
Now let us learn about different stages so contextual inquiry can be thought of as consisting of
multiple stages of activities there are broadly 5 stages.
(Refer Slide Time: 18:25)

What are those 5 stages? First stage is plan then the second stage is initiate then we have execute,
then close and finally reflect so there are 5 stages plan, initiate, execute, close and reflect.
(Refer Slide Time: 18:55)
So what is the plan stage? So here we generally create a plan on what to do or what are the things
that we need to do? So it involves identification of the goals of observation so what we want to
observe? Knowledge gathering about task domain some prior knowledge also arrangements for
recording the, observations how to record the behavior? Identification of users and the date time
and place of observation so identification of observational setup and users.

All these can be converted to a script and can be rehearsed many times before the actual
observation takes place so that it is smoothly done. So, all these are part of the first stage that is
planning stage planning for observation.
(Refer Slide Time: 20:04)
In the second stage or initiate stage although it may look simple but this is very important and
crucial phase of the contextual inquiry. Here we need to contact the authorities for permission
and open communication with the end users so that they willingly participate in the observation
process. So occasionally if we simply drop in and asked them to let us observe then people may
not agree.

So some sort of communication should be established between the end users and the observers
before the observation takes place. So that the users become confident and allows the observers
to observe them during their working this also requires prior permission from the management
staff which needs to be obtained.
(Refer Slide Time: 21:12)

The third stage is the actual data collection stage in this stage observation takes place and data
collected.
(Refer Slide Time: 21:14)
The fourth stage is the closed stage like initiate this is also a very important stage although it may
look simple and trivial. Here generally the observation is ended with a thank you note sent to all
the participants along with the authorities. Because if this type of initiatives are not taken then
later on suppose the data turned out to be insufficient and you need to collect more data or later
on during the empirical study stage you need to engage the same users for empirical study they
may not agree if this closed stage is not properly done.
(Refer Slide Time: 22:05)

The fifth and final stage is the reflect stage in this stage the data that we have collected through
observations are analyzed to identify the design goals. Now this is not easy at all as we shall
soon see with examples why? Because there may be lots of data and going through this data to
identify specific design goals are generally not very trivial. We can make use of tools and
techniques available to analyze the data and find out design goals one such technique is the
affinity diagram method. Let us quickly have a look at the method and how it can help in
analyzing the data?
(Refer Slide Time: 23:06)

Now this method contains five steps what are those steps? Generate idea, display ideas, sort
ideas into groups, create group header, by group header it means the create names for each group
and finally draw the finished Affinity diagram. So the method involves these 5 stages generate
idea, display idea, sort ideas into group, create group name or header and finalize the diagram.
(Refer Slide Time: 24:01)
Let us try to understand these stages in the form of an example. Suppose we are trying to build a
class note taking application which is primarily meant for college going students. So we have
performed contextual inquiry to identify the end user requirements so that the application is
usable. And we are now trying to make use of the affinity diagram method to identify the design
goals for this particular application.
(Refer Slide Time: 24:47)

Let us assume that CI is already done and some observations are recorded now 2 record
observations let us assume that three tools have been used to study the behavior, a physical pain
and paper based note taking, one web application notion dot so. And xournal++ desktop software
these three tools have been used to computer based tool and one pen and paper based traditional
note taking have been used to observe and record user behavior during actual classes or the
actual work setting.
(Refer Slide Time: 25:45)

Now these observations we want to analyze using the affinity diagram method. So let us see how
affinity diagram method can help us analyze the observations?
(Refer Slide Time: 25:59)

So among the 5 steps let us concentrate now on the first 2 that is generate ideas and display
ideas? So suppose we have collected some notes during our observation in this form sticky note
form. So one observation is multi-level organization of notes not possible that is one observation
we made during our contextual inquiry phase another observation may be free hand drawing is
not accurate during not taking drawing may be part of it.

But freehand drawing generally is found to be not very accurate or of high quality a third
observation that is made is navigation between different topics is cumbersome. Fourth
observation content relocation not possible in physical note-taking approach of course something
written somewhere is not possible to move to some other page because that is the limitation of
pen and paper based approach.

A fifth observation difficult to search keywords in notes another observation cannot insert any
images. All these observations are written down as notes with sticky notes and may be pasted on
a wall for analysis that is a traditional approach for brainstorming with the observations. Note
number 7 erasing contents is a difficult and daunting task that is another observation made by the
observers. Sorting of lectures by dates is torturous yet another observation made by the
observers.

One note says incorporating mathematical symbols not supported by one of the tools probably
that is not specified but this is one note written down to record observation. Text formatting
should be handy again with respect to probably one of the 2 computer based tools used to
observe behavior. Organization of course wise notes difficult that is another observation so many
observations have been made.

So this is only a subset of all possible observations that could have been met with respect to the 3
tools and user behavior. This is just to give some idea of what is meant by data collected during
the observational phase. So these are the data that we collected in the form of handwritten notes
it can also be in the form of video and handwritten notes after reviewing the video.
(Refer Slide Time: 29:23)
Now so many notes are or the observations are recorded so what we need to do now you need to
display the ideas. So this is one way of displaying the ideas so these ideas are pasted on some
surface can be wall can be whiteboard. So that other team members who are part of analysis of
the data can have a look and then give in their comments or feedbacks.
(Refer Slide Time: 30:00)

The third stage is sort the observations into groups; third stage of the affinity diagram method is
sorts it into groups. That means behavioural observations that are similar in nature should be
sorted into groups so among these observations that have been listed what are or which of the
observations can be considered to be similar which can be then put together into a group let us
see?

So these 2 observations multi-level organization of notes not possible and sorting of lectures by
dates torturous can be considered to belong to same type of behavior so that these can be put in a
single group. Similarly organization of course wise notes difficult belongs to the same group now
these 2 notes navigation between different topics cumbersome and difficult to search keywords
in notes points to similar problem faced by users during their activities and can be considered to
be pointing to same issue in the design.

Again content relocation not possible in physical pen and paper based method and erasing
contents is a daunting task. Again implicitly refers to similar problems faced by users so they can
be considered to belong to the same group of observations.
(Refer Slide Time: 31:49)

So in this way from the display of the ideas we can try to correlate the observations and then put
them into some group. In step 4 these groups are assigned some names or some headers for
example these 3 observations sorting of notes by dates is structure as multi-level organization of
notes not possible. Organization of course wise notes difficult these three observations can be
clapped together into a single group with a, header navigation in notebook or notebook
application.
So in step 4 we assign the header to this group of observations and the header actually gives us
some idea of the issues the design issues or the usability issues that need to be addressed to make
the product usable. 2 more groups that we have seen earlier; comprising of one group comprising
of these 2 observations and this is the header. The observations are difficult to search keywords
in notes and navigation between different topics is cumbersome.

So these 2 observations are combined together into a group with header navigation in notes.
Similarly erasing contents is a daunting task and content relocation not possible in physical or
pen and paper based note taking approach. These 2 observations can be considered to belong to
the same group and a header is assigned to it namely not organization. So in this way we group
different observations together and assign them headers so that is the fourth step in the affinity
diagram method.
(Refer Slide Time: 34:06)

The fifth step is once the headers are assigned and the observations are grouped we again display
or draw the final drawing. So all these notes are now grouped say for example these 3 are
grouped together with this header these 5 are grouped together with this header. These 2 are
grouped together with header another group with header there are 4 observations in this group
with header and 3 observations in another group with header.

So there are total 19 observations made after the contextual inquiry of course this is a small
number in practice it can be 100 and then these observations are put into 6 groups. So 19
observations 6 groups and for each group one header is assigned so 6 headers so that is the
outcome of the analysis method. So to repeat we first generate ideas after observations or during
observations.

If it is active mode then during observations we generate ideas if it is passive mode then after
observation during reviewing of the recordings we generate those ideas. Then we display them in
some manner maybe on some surface then brainstorm in a team to sort similar observations into
groups and then assign some headers to those groups. So this groups with headers the set of all
these groups with headers is the outcome of the method. So what to do with this outcome?
(Refer Slide Time: 36:52)

We can come up with a set of design recommendations. For example in this case in the note
taking application case based on the observations that we have made. We can come up with the
recommendations such as for correcting mistakes there should be a provision to erase the content
this would help in keeping the notes neat and tidy. This can be one design guideline provided to
the designer which is likely to take into account users concerns and make it usable how we can
say that?

We can say because we have collected these requirements through user observations in a
contextual inquiry method which is a usability requirement gathering technique. We can actually
also come up with some functional requirements by converting this type of design resonance. As
we shall see in later lectures one thing to be noted here is that here we are not talking about how
to take into account this design recommendation how to implement it?

Rather what we are talking about here is what we need? So our objective is what we need to
make the design usable rather than how to implement the particular thing that we need? So the
outcome of affinity diagram method is set of design rationales or it may lead to set of functional
requirements. So in our subsequent lectures we will see what, is functional requirement and how
it is important in system design? So affinity diagram output can be used to come up with
functional requirements which will take care of usability requirements implicitly.
(Refer Slide Time: 39:02)

So that is all for today is topic so what we learned? We learned about contextual inquiry what it
is and how it is done? We also learned about how to analyze the data that we have collected or
we collect during contextual inquiry. I would like to repeat again so contextual inquiry is not an
interview only it is primarily an observation to observe user behavior in their work setting. And
semi-structured interview can be used as a supporting tool to get clarifications on certain user
behaviors or activities that is noted during observation.

We have also got some idea of how to analyze the data through the affinity diagram method?
Whatever we have covered can be found in this book you are requested to refer to chapter 2
section 2.4.3 of this book. That is all for this lecture hope you have learned the topic and enjoyed
it thank you and goodbye see you in the next lecture.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology, Guwahati

Module No # 02
Lecture No # 07
Functional specification of Requirements

Hello and welcome to the NPTEL MOOC’s course on design and implementation of human
computer interfaces. We are going to start lecture 7 which is related to requirement specification
particularly specification of functional requirements.
(Refer Slide Time: 01:02)

If you can recall we are currently discussing the software development lifecycle stages where our
primary concern is to develop interactive software. Now interactive software again just to
recollect refers to a class of software that are supposed to be used by layman users who are not
experts in the technology. For them we need to take into account various things most importantly
user feedbacks at different stages of development.

And in order to do that we have a special or a specific software development lifecycle meant for
building interactive software and we are currently discussing different stages of the life cycle. To
recollect there are several stages requirement gathering, analysis and specification is the stage
from where we started our discussion. We have not discussed in details the feasibility study stage
which is not very relevant for our core concepts.
After requirement there is this design stage, prototyping stage and evaluation of prototyping
these 3 sub stages in a cycle constitute the design prototype evaluate cycle. Now here design
refers to both design of the interfaces as well as interactions and also design of the system in
terms of modules. Now those modules once finalized are to be implemented using programming
some sort of programming language that is the coding and implementation stage.

Once the system is implemented we need to test it test the code that is the code testing stage after
the entire system is coded implemented and tested. And we are to some extent assured of its
executability we still need to test it for usability. Which is one of the key concerns in our
interactive systems and that is done in the empirical study stage which is expected to be done
once or twice at the most because this stage is quite costly.

However there is a possibility that output of this stage can lead here and there can be a cycle. So
once this study stage is complete and we are assumed of the usability as well as executability of
the system we go for deployment and maintenance that is our last stage. Currently we are
discussing the requirement, gathering, analysis, and specification stage.
(Refer Slide Time: 04:11)

Now we learned about usability earlier which is one of the crucial aspects of the design of
interactive system. We also have learned about the usability requirement gathering why that is
important and how it helps building a system that is likely to be acceptable to the end users? We
have gone through in the previous lecture one method of requirement gathering particularly
usability requirement gathering that is contextual inquiry.

Again it may be noted that this is only one of many such techniques however we discussed this
technique contextual inquiry technique in some details.
(Refer Slide Time: 05:01)

Now contextual inquiry technique; is used to gather the requirements. And we have also seen
how these requirements can be analyzed whatever we have gathered during contextual inquiry
can be analyzed to identify design goals or some such things through the reflect stage using
various tools such as affinity diagram method. So we discussed in details affinity diagram
methods with examples to understand how the observations that are made during contextual
inquiry can be converted to some design guidelines or something that can help us design usable
product.

In this lecture our focus is actually how to specify those designs so that other team members can
make use of the specification in subsequent stages of the life cycle. So this lecture will primarily
focus on notations and conventions that are used for specification of system requirements that is
the subject matter of this lecture.
(Refer Slide Time: 06:20)
Now before we go to the actual subject matter let us quickly recollect that whatever we have
termed as usability requirement earlier is also known as non-functional requirements. This is a
term that is used to refer to requirements such as usability and some other things so usability
requirements are one type of non-functional requirements. So what are the other non-functional
requirements let us have a quick recollection of those types.
(Refer Slide Time: 06:58)

So there we can have performance related non-functional requirements operating constraints that
can be listed as non-functional requirements. Economic considerations which are again
considered to be non-functional requirements life cycle requirements and finally interface issues
that are non-functional requirements. Now among these interface issues both hardware and
software interface issues are used are referred to and the software interface issues are generally
termed as usability which belongs to this kind of non-functional requirements.
(Refer Slide Time: 07:44)

And we have repeatedly emphasized that usability is one very important non-functional
requirement that has to be taken into account while we are going to build an interactive system.
So we have discussed several non-functional requirements which are very important in the
context of system design.
(Refer Slide Time: 08:11)
And in particular we have discussed usability which is very important in the context of
interactive system design now they are of course important. But one issue with non-functional
requirements only is that these are difficult to formally specify and unless they are properly
specified. Unless we are able to specify the requirements in a proper way a suitable way it is
difficult to convert them to design requirements or into a proper implementation of the system.

So we need to somehow be able to specify these requirements in a proper way but unfortunately
non-functional requirements are not very much suitable to be converted to that proper way. So
that we can immediately be able to convert it to some implementation or some design of the
system.
(Refer Slide Time: 09:12)

In fact whenever we are talking of system requirements and this next stage is implementation
then our objective should be to have requirements which are easy to understand and implement
in the form of a program. That is one sort of requirement of the requirements so to speak that we
should aim at. And in order to achieve that what we need is some formal way to specify the
requirements that is required.
(Refer Slide Time: 09:50)
Now when we say that we want to formally specify the requirements that means we want to
make it easy for the team to implement the next stage of the development lifecycle by team I am
in the development team. And when we are able to do that when we are able to specify
requirements in a somewhat formal manner for quick implementation those requirements are
generally called functional requirements.

They have these properties that they are easy to understand and convert to codes we shall see
with some examples what we mean by these terms that convert to codes easy to understand and
so on.
(Refer Slide Time: 10:41)
Now as the name suggests so the name is functional requirement so as the name suggests
functional requirements specify a system or the requirements of the system in terms of functions.
What are functions? Mathematically functions are defined in terms of its input output and here
also we specify the requirements in terms of functions that take some specific input produces
some specific output and these functions also typically has some purpose mentioned in the
specification. So in functional requirement we have functions defined in terms of input output
and purpose.
(Refer Slide Time: 11:35)

So let us depart into the idea of functional requirement specification what are those and how to
specify?
(Refer Slide Time: 11:50)
Now before we are able to create a functional requirement specification we should be aware of
few things first of all when we are talking of functional requirement specification the main idea
is abstraction. What is meant by this term is that? We only need to identify black box functions to
be supported by the end product or the system. And in this black box functions we need to only
specify the input and output.

So, in other words abstraction tells us that identify only the need rather than how to achieve it. So
we do not know how the function can be implemented or defined rather only what input it will
take and what output it should produce. So the function in itself appears to be a black box with
only an input and output specified rather than how the function should be implemented? So that
is the first thing that we should keep in mind here we are trying to only identify functions as
black boxes rather than trying to design algorithms to implement the functions.
(Refer Slide Time: 13:07)
Second thing is decomposition and hierarchy so when we are trying to identify the functions we
should decompose the entire requirement into some sort of hierarchy of functions and sub
functions. Otherwise it will be difficult and too complex to specify the functions. If we can think
of hierarchical representation of functions and sub functions then it will be easier for us to
specify the function input and output much more easily than if we do not follow any hierarchy.

So essentially this decomposition into hierarchical levels and the levels of the hierarchy help us
better manage the description or the functional description of the system. So we need to have
abstract notion of function as black box with only input and output. And also we need to think of
the functions in the form of a hierarchy so that we are able to better manage it easily define it and
so on.
(Refer Slide Time: 14:22)
So what are the key points that we should remember while defining these functions? First thing
is we should avoid exploratory style of definition what it means? It should not be the case that
first we should think of implementing the functions and then from there we go back and think of
creating the functional hierarchy. That is exploratory style first we keep on implementing and
then from that implementation we learn about the presence of the functions.

It should be the other way around first we should think abstractly the functions and then think of
how to implement them in a letter design stage. Abstraction as we have already pointed out the
function should be thought of in a very abstract form. We should not start thinking about the
algorithm to implement the functions rather we should think of functions as black boxes and only
input and output need to be thought of plus the purpose of the function.

And finally it will be easier to manage the specification if we can think of the functions in the
form of a hierarchy of functions and sub functions rather than only one level that will make
things easier to manage. So these 3 things we should keep in mind we should try to avoid
exploratory style, we should think of functions as black boxes and we should try to think of a
functional hierarchy to represent the all the functions in the system.
(Refer Slide Time: 16:04)
Keeping these in mind we should come up with a functional hierarchy that should be our end
product in the functional requirement specification stage. And when we put these requirements in
textual form in some specified format what we get is called the SRS or software requirement
specification document. So SRS this acronym comes from these terms these words software
requirement specification.

Now this SRS document is essentially our quote unquote formal representation or specification
of the requirements. So our objective is to create an SRS document after this functional
requirement specification stage is over.
(Refer Slide Time: 16:59)
Now in SRS there are specific formats to be used generally what is followed is a hierarchical
structure with some name given to the hierarchy levels like r 1, r 1.1 and so on. And at each level
or r where r 1.1 etcetera which indicates the hierarchy each level represents a function with
clearly defined input and output and some description which is optional. So when we are trying
to specify SRS essentially we need to use these notations that; is a common practice that we
create hierarchy label.

The hierarchies each level of the hierarchy should be given a label with some name and some
description and these levels can further be decomposed into sub levels with similar notation.
Now let us try to understand this idea of creating SRS from a functional requirement hierarchy
let us try to understand this with respect to one example.
(Refer Slide Time: 18:33)

If you may recollect we introduced this example in one of the earlier lectures this is a class note
taking application where the primary users are likely to be the college going students. So earlier
we have seen how to create usability requirements for this application using the contextual
inquiry method. Now let us try to see how we can create a functional requirement specification
for this application.
(Refer Slide Time: 19:06)
What are the requirements that we can identify for this application? One obvious requirement
can be authentication that is for a user to access the app feature so the user needs to authenticate
which is common for all the apps. So we can have such a function as a requirement
authentication function now authentication function can further be decomposed into sub
functions.

For example there can be one requirement to create an account that can be one sub function
under authentication. Then there can be a requirement to login that can be another function under
authentication function one more function can be management of the account, account
management it can be treated as another sub function of the authentication function.
(Refer Slide Time: 20:13)
So diagrammatically we can put these functions and sub functions in the form of a hierarchy as
shown in this figure. So here at the top level of the hierarchy we have authentication function
then under authentication we have these 3 sub functions create new account login and update
password. So update password can be one sub function under authentication function.

Now update password can have sub functions under it as well for example there can be one sub
function send one time password can be another sub function set new password. So this can be
one way of creating a functional hierarchy for the authentication function. Of course it may be
noted that this cannot be the only way possible you are free to create your own hierarchy for
authentication you can add more functions edit some functions and so on. So this is just one
example of how such a hierarchy can be created.
(Refer Slide Time: 21:29)
Let us look at another high level function this is related to managing the notebook in the
application. So this can be a higher level functional requirement that the user wants to manage
the notebook. Now under these functions there can function there can be many sub functions
again it can lead to a hierarchy of functions and sub functions. For example there can be a
requirement to create or delete note, can be a requirement to open or close a note. Can be a
requirement for editing a note, can even be a requirement for viewing all the notes and so on.
(Refer Slide Time: 22:33)

So we can create another hierarchy for notebook management function graphically we can have a
representation like the one shown here for such a hierarchy. So at the top level we have notebook
management functionality under this there are some functions create note, create notebook, open
note, edit note, list notebook contents, delete note, delete notebook etcetera. Under edit note we
can have further decomposition add text, draw content, insert image, manage table, delete
content etcetera.

Under draw content further decomposition is possible like draw shape, freehand drawing etcetera
similarly under manage table further decomposition is possible with sub functions like create
table, edit text, insert row, insert column and so on. So what this hierarchy shows is that? It is
possible to create a decomposed functional requirement hierarchy which will make it easier to
understand the overall requirements.

Instead of this hierarchy if we have simply mentioned this top level hierarchy like notebook
management then it would have been difficult to actually specify input output as well as
description. What this is supposed to do? Because in that case it would have been very complex
to specify those things instead of that by decomposing we are able to better manage this
complexity by dividing it into sub function.

So then now what we need to do is basically specify only the input output for the sub functions
which is much more easier compared to specifying everything for only one function.
(Refer Slide Time: 24:49)
Let us see one more functional requirement example for the same application requirement for
searching in the notebook. Now this can again be considered to be a higher level functional
requirement top level and under this there can be several sub functions again creating a
hierarchy. Requirement for searching by text this is one possible sub function another possible
sub function can be searched by date.
(Refer Slide Time: 25:24)

Then we can have a hierarchical depiction of the functional hierarchy in this form where we have
search in notebook under which there are 2 sub functions search by text, search by date.
Similarly we can have another high level hierarchy search in note and it is possible to decompose
it further.
(Refer Slide Time: 25:55)
So then what we get what we get is a larger hierarchy so we merge these hierarchical
descriptions together to get a larger hierarchy to represent the functional requirements of the
system. Of course this is not complete but it will give you some idea of what we mean by
hierarchy. So, here as you can see we have top level functional requirements authentication,
notebook management, and search in notebook, searching note.

Then we have second level hierarchy create account login, update, password similarly create
note, create notebook and so on. Then we can have third level also one time password, set new
password even fourth level in this case draw shape, free and drawing etcetera. So there is no
restriction on up to how much level we can go the more decomposition is the better for
specification.

It will bring in clarity of thought if you have very less number of levels and everything in the
single level then it is generally considered to be not a good specification assuming. That the
system is complex for very simple system of course that multiple levels of hierarchy; may not be
required.
(Refer Slide Time: 27:41)
Now so far what we have discussed is just a visual depiction but that is not a specification as
such for the requirements. Now we need to have a textual description as I mentioned before so
textual description follows its own format with level numbers r 1, r 1.1 etcetera and function
name input specification output specification and some function description. Still considering the
function as a black box rather than describing the actual algorithm to implement the function.

For example let us consider this functional requirement create new account so this is as you can
see it is second level. So we can call this level 1 and then create new account can be termed as
level 1.1 the same thing we have used to denote in the textual description this is the level
indicator then we have given it a name which is the same name that we have used earlier create
new account.

Then there is one input specification so what input this function takes it simply mentioned user
information. So it can be any information so it is possible to keep it vague at this stage because
we are not going to discuss about how to implement? So the flexibility should remain output
specification also is required here it is mentioned that some message will be given as output. And
then there is this optional section on description of the function.

So it says what the function does purpose simply says create a new account using user details
and display account creation message that is simply the purpose so in this way we can specify
the functions in the functional hierarchy.
(Refer Slide Time: 30:00)

Similarly we can create specifications for other functions say for example the second function is
login so accordingly we gave it the number R 1.2 as you can see in the hierarchy. So the first one
if it is given R 1.1 then we can call it R 1.2 then R 1.3 then this 1.3.1 and so on. So we are
following this nomenclature note that this need not be the only way to represent levels and in
different places you may find some other ways to represent these levels of the hierarchy.

However here in this course we will follow this convention so the level number is followed by
the name of the function some name you have to give, then input specification, output
specification and description brief description of what the function does? Like it simply says
verify user credentials and provides access to user data. Note that nowhere we are referring to
any details related to how the function can be implemented.

For example here in login we are not telling how this function will produce the output with from
the input. So how this processing takes place or the algorithm to create the output is not specified
anywhere it only states the purpose rather than the actual way to implement it.
(Refer Slide Time: 31:48)
Some more examples R 1.3 update password then 1.3.1 send one time password input, output
and description. It is generally preferable that higher level also you specify the input, output and
description optionally for each level function you should do that not only for the leaf level notes
that are mentioned here. So for our 1.3 also you should specify what is the input? What is the
output and what is the description?

Then do the same for R 1.3.1 that is the sub function of 1.3 as well as our 1.3.2 this is the another
sub function of R 1.3 set new password input output description. So at each level for every
function you should ideally specify the input output and description for each and every function
in that level. One common mistake occasionally we perform is that when we are specifying the
output we also specify some functional words.

For example here send one time password output we may be tempted to write send one time
password. Now the with the addition of the word send it no longer remains an output rather it
becomes a process in itself so try to avoid using this type of action words in either input or
output if you are using action words then the description is wrong. So you must keep this in mind
and avoid using action words any sort of action words in the input and output. Otherwise those
will not remain input and output instead they will become functions itself.
(Refer Slide Time: 33:59)
So another top level note create note again input output description specification is given in a
similar manner. So you can now get some idea of what we mean by formal specification. So here
we are giving a level name, a label to the level name, name of the functional requirement some
idea of the input to be provided to the function in a very flexible and open manner. It should not
be very specific because here still we are talking of black boxes as functions so we are not going
into the details of any algorithmic design.

So our input should be kept as much open as possible like here we are simply mentioning that
provide as input location and name but in which format how all these details we are not
providing so that is a flexibility that we want to keep at this stage. Similarly for output we are not
specifying the exact nature of the output instead a broad idea of what the output should look like
and what it should what purpose it should solve rather than exactly which format it should be
produced in and how it should look.

So this idea of labels, names input, output specifications. As well as the idea to keep the inputs
and outputs flexible and open to interpretation for subsequent design and implementation stages
are key things that should be remembered while designing and specifying the functions.
(Refer Slide Time: 36:04)
Then comes open note R 2.3 again with input, output and description and this openness is here
also note location but not exactly in which manner whether it is a single number, coordinate that
we are not specifying. Similarly content what this content means it is left to be decided in later
stages rather than specified here itself and also a description broad description of what the
function is supposed to do?
(Refer Slide Time: 36:42)

In this way we can specify all the functions in the hierarchy for simplicity and brevity we have
omitted certain parts. Like here R 2.4 edit note the input, output and descriptions are omitted
only the lowest level note shown to have this description. But remember to add it for each level
like R 2.4, R 2.4.2 draw content as well as 2.4.2.1 draw shape which is a sub function of this
function which is in itself; as a function of this function.

So draw shape is a sub function of draw content, draw content is a sub function of edit note and
for each of these levels we should have input, output and description as shown here input here
output here and description. So when we have created this hierarchy our next task is to create this
textual description in the format shown in the examples. Again this is not the only way to specify
there can be a different; conventions followed however broadly it should convey the message of
the level which level the function is situated at then the function name, input, output and
description.
(Refer Slide Time: 38:17)

So you should note in the examples how the functions are represented name, input, output,
description, plus the level number all 5 are important. Then another thing to be noted here is that
the abstract nature of the representation. So none of the functions that we have seen in the
examples tell us anything about how to implement those how to convert them to notes? So
effectively what we are looking at is a black box where we provide the input and get the output
without bothering about how we get the output.

So that abstract nature of specification should be noted and the hierarchy of course how we
created the hierarchy to represent the requirements should be noted and should be followed in
problems that you face. Also as I said follow the naming conventions typically what we have
shown here can be followed but there can be other possibilities.

However anyone should be followed consistently throughout the life cycle. So we have shown
one convention where we gave particular level of the hierarchy and used name for the function
then input kept it open, output kept the scope open, some optional description part which should
be done for each and every function in each and every level. It should not be considered only
required at the last level even at the higher levels also for each function you should have ideally
input, output and description specified.
(Refer Slide Time: 40:16)

The example that I have shown of course is not complete and as a put forth thought you can
think of completing the hierarchy as well as the specification.
(Refer Slide Time: 40:30)
So with that we come to the conclusion of this topic so what we have covered today is what are
functional requirements? What are the things we should keep in mind while creating functional
requirements and how to specify those requirements? So one thing you should keep in mind is
that this, functional requirements need not be created based on end user studies. Some domain
knowledge plus some discussion with the clients may be good starting point to create the
functional requirements.

Then subsequently once usability requirements are available some of those requirements can be
converted to functions and put in the functional requirement hierarchy and subsequently included
in the SRS document. We shall see in a subsequent lecture how to do that, apart from that other
things we should keep in mind is that how the functions are specified? How they are decomposed
how they are labeled and what are the things to be specified in the SS?

To recollect we need to specify for each function at each level its level, its name input, output
and purpose. And in the input and output we should not be too specific about the nature of the
input and output rather we should keep it open for interpretation at later stages of the
development life cycle. Because here we are not bothered about how the functions are to be
implemented rather what the function should do?

Accordingly we can keep the input and output somewhat open ended and flexible to
interpretation whatever I have discussed today can be found in these books for further details you
can refer to chapter 4 of the first book and chapter 7 to 8 of the second book. With that we
conclude today is lecture I hope you have got some idea of what we mean by functional
requirement and how to represent it both visually as well as formally in textual format in the
form of SRS document.

In subsequent lectures we shall see how usability requirements can be incorporated in the form
of functions in functional requirements. So that our systems can have better usability that is all
for today see you in the next lecture thank you and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology, Guwahati

Module No # 02
Lecture No # 08
Case Study on SRS

Hello and welcome to NPTEL MOOCS course on design and implementation of human
computer interfaces. So in the previous few lectures we learned about interactive system
development life cycle and we started our discussion on requirement gathering analysis and
specification stage of the life cycle. So we will continue our discussion on this stage which is one
of the several stages that make up the whole life cycle.

Now earlier we have seen that in the requirement gathering analysis and specification stage there
are 3 distinct activities one is gathering of requirements which includes both usability
requirements as well as other feather related requirements from the clients. Then we have also
seen analysis of those, requirement gathering outcome so that we can finally come up with
specification of those requirements.

We mentioned that at the end of these activities what we get is a document which is called
software requirement specification or SRS. Now SRS is the outcome of the stage of requirement
gathering, analysis and specification this document is passed on to the next phase to the next
stage of the life cycle the design stage. Where based on this document we go ahead and build a
design document. So SRS creation is very important activity and subsequent activities of an
interactive system development life cycle relies heavily on this stage.

Now so far we have seen what are the different types of requirements? Usability requirements
which are one of non-functional requirements we have also seen functional requirements we
have seen how we can specify functional requirements. We have also mentioned that
non-functional requirements can be specified as functional requirements after conversion later,
on, we will see some more examples on this.
But in this lecture what we are going to discuss is a full SRS document how it is created what are
the components present in it how it looks. And so on because so far we have discussed the
concepts related to SRS document in a piecemeal manner. Let us now try to put them together
and see the whole document for better understanding of the documentation process.
(Refer Slide Time: 03:21)

So the document is supposed to have a cover page for example here we can see the cover page of
a document SRS document created for a specific system the system is student activity monitor
and alert generator. So this is the name of the system which, does few things namely monitoring
student activities and generate some alerts based on the activities. So we can name it as software
requirement specification for this system then note that few more things are mentioned like
person name.

So it need not be the case that the final document is the only document that is created it may have
undergone several changes and evolved over time before it is finalized. So, each of these
intermediate documents are given a version number to distinguish it from earlier and later
documents or versions. And that information is ideally to be conveyed to the reader of the
document through this convention the current version of the document along with the date on
which this document is created.

Then ideally in the cover page the persons or the team that created the document should be
mentioned. So you can mention prepared by so and so and so and so giving the name of the team
members. You can also provide the place where it is created for example here it is mentioned IIT
Guwahati so IIT Guwahati it has been created. And if there is any mentor who helped in creating
the document like here the way it is mentioned.

So, in the cover page then what we should keep first this title software requirement specification
doc for student activity monitor and alert generator which is the name of the system. Then
version number then date on which the version on which this version is created. Then the people
who have created it prepared by so and so place where it is created and finally if there is some
mentor. So this of course is optional and it need not be present everywhere but other things
ideally should be kept in the cover page or the title page.
(Refer Slide Time: 06:42)

Then comes; the content section so here for better organization ideally you should include one
content table of contents. Which; will list out the content of the document in the form of sections,
and sub sections as you can see here in this document there are several sections. Section on
introduction then overall description, then external interface requirements, functional
requirements other non-functional requirements and so on.

Now under introduction section as you can see we have several subsections named and labeled
accordingly say purpose of this document, document conventions, project scope, scope of the
project. Similarly under overall description we have several subsections product perspective,
product functions, user classes and characteristics, operating environment, design and
implementation constraints, assumptions and dependencies these are subsections under overall
description section.

Under external interface requirements subsections are user interface, hardware interface,
software interfaces and communication interfaces. So, all sorts of interfaces that are part of the
documentation process are covered under this section. Then for functional requirements so we
already discussed that in the SRS there are primarily functional requirements and also
non-functional requirements.

For functional requirements we have one dedicated section functional requirements where for a
different class of users the different functional requirements are provided. For this system there
are 2 user classes identified instructor and student this system is primarily meant to be used in a
classroom setting. So there will be an instructor and several students so for each of these
stakeholders of the system or the end users you have different functional requirements listed
here.

A separate and dedicated section is there on non-functional requirements such as performance

requirements, security requirements, software quality attributes and so on. So these are the way
the overall content of the document is organized in the form of sections and sub sections.
(Refer Slide Time: 09:49)
Next ideally you should include in your SRS some revision history. As I mentioned the
document may have gone through several iterations before it is finalized so each, iteration is a
version. So how many versions have been created a brief history can be given for example for
this particular document. This section revision history notes down or indicates that there are
there were three versions created version 1, version 1.1 and version 1.2.

So version 1.0 was created on this date it was the original document created then on a later date
version 1.1 was created based on the comments received from the mentor of the team. So this
second version is modification of the original document then in another later a third version,
version 1.2 was created which was the final version for the SRS document. So this is again after
some more comments were received from the supervisor or mentor of the team.

So ideally in a SRS document you should list this revision history for record keeping then the
actual content of the document starts.
(Refer Slide Time: 11:30)

So it starts with the introduction section as we have seen in the table of content section so there
are several sub sections. One is purpose what is the purpose of this document why we are
creating it here in brief you are expected to write the purpose. For example for this document the
purpose is written as the purpose of this document is to give a detailed description of the
requirements for the student activity monitor and alert generator software.
So that indicates the purpose it will illustrate the purpose and complete declaration for the
development of system along with the system constraints that is also one of the purpose for this
document. This document is primarily intended for intended to be proposed to a customer for
their approval and as a reference for developing the first version of the system for the
development team.

This is the more crucial aspect of the purpose that it is to be shown to the customer for their
approval and then it is to be shared with the development team for them to start design and
development process. So that is in brief you should include the purpose for this document. Then
if you are using some conventions in the document for easy understanding of the readers of this
document you should list those out in a separate subsection as shown in this document.

So there is a dedicated sub section document convention under introduction section where all the
conventions that are used in this document are listed. So it is a table having 2 columns one is the
term or the notation used another one is the definition of that particular term. For example when
the term instructor is used it is defined as person who shall be using the software for monitoring
purpose.

When the term student is used it is defined as person who shall be monitored by the instructor.
When the term device is used it is defined as an electronic device using which the instructor is
delivering their lecture. Then when the term DESC or DESC is used it refers to description of
something. Rat convention refers to rational the short from of DEP dep refers to dependency. So
these are some of the conventions short forms and terms used to indicate things that are listed out
in this subsection.
(Refer Slide Time: 14:49)
Then in the third subsection of the introduction section the project scope is reported. Ideally you
should do that also so it says that this software is meant to be deployed in an IT enabled large
classroom environment wherein the lecture delivered by the instructor is via a device through
which both audio and video are transmitted. This software shall allow the instructor to
conveniently monitor the attention of their students in real time so in under the project scope
subsection you explain the need and objective for this project in brief.
(Refer Slide Time: 15:39)

Then we move to the second section that is overall description note that first section we already
covered first section on introduction where the 3 components that are shown are supposed to be
present in your document. So ideally you should list out those things and the extent to which you
provide content under each of these subsections is up to you so it can be larger smaller but
ideally it should be brief and to the point.

Now let us move to the overall description part it again is divided into several subsections one is
product perspective which lists out or which explains the perspective for this product. This
software will be a top-up on the already existing system for communication between the
instructor and the students inside a classroom. In which the slides of the lecture are delivered to
the students devices along with audio which they can listen to via earphones.

So it is talking about some existing system where something is already done and this system is
meant to be a top-up addition to that existing system. The slide transition are handled
automatically by the existing system the responsibility of the proposed system shall be to
monitor the attention of the students and ensure that they are not chatting, slacking or are
indulged in entertainment.

So it clearly tells us what is to be expected out of this system? It tells us that there is already an
existing system few things that our, that this current system is going to assume are already part of
that system. And based on that assumption that those things are already working in with the
existing system we are going ahead and building this system whose sole purpose is to add to the
existing system rather than proposing an entirely new system where everything is to be done.

So that is the product perspective in this way you are expected to write the perspective for your
product as well. Then comes, the product leverages the sensors such as gyroscope proximity
sensor, accelerometer in the devices used by the students which determine factors such as
orientation, distance from user shaking frequency which enable the system to determine the
attention of students and alert the instructor accordingly.

So it tells us that what the product assumes to be available and what it does? So it assumes that
some sensory values are already available from specific sensors that are already part of the setup.
And if those values are available then only it will work and it will produce something which is
the objective of this system namely determination of attention of students and generation of
alerts. So determination of attention and generation of alert are the objectives but it depends on
the availability of sensory values that is clearly stated in this section product function.

The application should also allow the instructor to see the summary of the data collected during
lecture which shall be helpful during feedback sessions and grading. So apart from attention
determination and alert generation one more functionality is to be expected out of this system
that is it should allow the instructor to get a summary of the data collected during lecture for
certain purposes. So that also is mentioned here so effectively this subsection reports what the
system assumes and what it expects to deliver?
(Refer Slide Time: 19:50)

The third section is also interesting subsection user classes and characteristics so from the point
of view of this system which is a classroom monitoring system we require 2 types of users. Users
are divided into 2 classes the instructors and the students the students interact with their mobile
devices having the sensors which are used to determine their attention by the software this can
then be viewed by the instructor in real time or at his or her laser.

So in this subsection what is being told is that? Who are; the end users? So there are 2 types of
end users students and instructors. Students will use the system on their mobile devices having
those sensors specified in the earlier subsection and the data generated will be processed and
produced as output and displayed to the instructor which will list out relevant details to him or
her. Now that, details can be viewed immediately in real time or it can be viewed by the
instructor at a later time so that is also specified here.

So everything every aspect related to the product is supposed to be briefly introduced in this
document. The fourth subsection under this second section is on operating environment so what
is the operating environment for the intended product it clearly states that. The environment is an
IT enabled large classroom where both the above user classes carry their devices the lecture
slides are shared from the instructor through his her device to the students along with slide
transitions and audio which can be heard by plugging earphones into their devices.

So the students can get the instructors voice through headphone or earphones due to the presence
of a large classroom it is not possible for the instructor to observe all students and therefore we
have the need for an app which measures the attention of the student. So it essentially tells us
about why we need it the smartphones or the devices that the students are carrying, with them as
well as the instructor is carrying with him or her. With their sensors take various parameters like
device orientation and others into account in determining the attention of the student.

So the operating environment is an IT enabled classroom environment students and teachers

carry their mobile devices smartphones with them. And they are connected to each other through
the system when they are using the system these sensors present in the devices capture the data
sensory data and that data is processed to produce the output required for the teacher to monitor
the students. So that is clearly stated what is the operating environment under this subsection.
(Refer Slide Time: 23:26)
The next subsection is design and implementation constraints if there are any constraints that are
likely to be faced by the teams for the above purpose of implementing the app we are forbidden
to use the camera for measuring the attention. So it is explicitly mentioned that camera cannot be
used to capture the students themselves the students might exploit the sensors used to portray
themselves as paying attention even when they are not.

So what it tells is that? The attention can be monitored by the teacher by simply utilizing the
smartphone cameras present in each student’s device however that is forbidden. That is not to be
used because the students can manipulate the camera feed and create a feed which look like they
are paying attention whereas in reality they are not. So this gives a false positive in cases when
the student uses a stand to maintain the orientation rendering the accelerometer and gyroscope
functions redundant.

Effectively what it tells is that if we use camera then it may not give us correct results so ideally
we should not use camera and that is explicitly mentioned under the subsection on constraints
under which the production should operate should be designed and implemented. The next sub
section is on assumptions and dependencies that are to be considered while building the product
so it clearly lists out what are the assumptions and what are the dependencies.

So we assume the presence of IT enabled large classroom with the availability of a system that
can display slides from the instructor to the students along with slide transition is available. This
is the assumption that all these things are available one assumption about the product is that it
will always be used on mobile phones that have enough performance. Means efficient
performance wise efficient; mobile phone that is mobile phones with good configurations.

Here by mobile phone it is specifically meant to be smartphones because only the smartphones
have those sensors that are assumed to be present in the environment. If the phone does; not have
enough hardware resources available for the application. For example the users might have
allocated them with other applications there may be scenarios where the application does not
work as intended or even at all.

Also we assume that devices have sophisticated sensors to meet our requirements of measuring
even minute checking to make the software precise. So in order to make the product we require
certain prior data and the assumptions clearly list out what we require? We require good quality
smartphones having all the requisite sensors. And we also require the existing system which does
several activities so that our product can work.
(Refer Slide Time: 26:58)

Then comes the third section external interface requirements so at several level these
requirements can be specified first is user interfaces. The software in the device should allow the
instructor to have an option note here to have an option to connect with the devices of all the
students present in the lecture classroom. The students must also have a complimentary option to
connect to the instructor's device thereafter the instructor should have options getting real-time
statistics of the attention span of the attendees.

The UI should be more focused on being organized and work oriented rather than having fancy
style and animation the interface should have rigorous error management. So these are some
broad level user interface requirements mentioned here of course as we have seen usability
requirements can be done at a lower level and we will later see how to specify those
requirements.
(Refer Slide Time: 28:02)

Next is hardware interfaces what are the hardware interfacing requirements that needs to be
specified which is done under this subsection. The student’s mobile devices should have all the
necessary sensors like the gyroscope, accelerometer, and proximity sensor with enough
specification to handle the task at hand. Also the devices should have high performance and
space to be able to run the software as a background demand service.

These are some of the hardware interfacing requirements that are specified here the instructor's
device should also have high enough performance to connect to all the users the network should
have enough capability to handle the traffic of the large classroom. Of course here everything has
been mentioned in a very broad level high enough. Now it is up to you in your specification
document you can go to more course level and specify exact requirements rather than these high
level requirements
But high level requirements are also fine at this stage. Next is a software interfaces list out the
software interfacing requirements the data collected by the devices carried by the students has to
be transported to the device being carried by the instructor. The medium of transport shall be
deduced by the design team it could be using Wi-Fi, Bluetooth or some other wired connection.
The instructor device shall receive the data from all the student devices so effectively instruct a
device get data from everything in a connected system.

The system calls required for the communication would have to be invoked for gathering sensor
data the driver modules of the student devices would have to be cooperated with. So it tells about
what we need to do if we want to build the software how to get the sensory data, where to send
it, how to send it at a software level. The final interfacing requirements are the communication
interface that is also specified the transfer rate between the devices should be sufficient enough
for the instructor to reflect upon the findings of the application.

Since the application will be exposed to a limited environment thus the encryption concerns are
not humongous. These are some of the things that are mentioned with respect to this particular
system now one thing of course you have to keep in mind while going through this example SRS
is that not necessarily everything will be required in your case. So you have to take a call on
which interfacing requirements you want to highlight and which are not very relevant.
(Refer Slide Time: 30:51)
Then come, the main content of functional requirement which can be considered to be the major
component of any SRS. Now as we mentioned there are 2 user classes accordingly 2 groups of
functional requirements can be specified one is for one class of users. So let us start with the first
user class that is the instructors for an instructor what are the functions that are to be supported
by the system.

So we have already learned about the hierarchy of functions so we will follow that hierarchy
here. Of course when we discuss the hierarchy we used one notation here the notation used is
slightly different I will just point those out while going through the functions. So first function is
start class session it should be supported by the device by the system. So we should have an id
for this function top level function which is given something like FR underscore INS underscore
1.

It should have an input specified course name and class group, it should have an output specified
related course page. Now one thing you should note here is although it is mentioned related
course page is opened this part of the statement is not required because it is talking about some
process rather than an output. So when you are specifying some output you should not mention
about the process that this is open this is closed.

Instead you should simply say what is opened here related course page that is good enough
whether it is opened or not open that need not be mentioned. So this type of action words is to be
avoided in specifying output as well as input. Then DESC remember in the convention we
mentioned DESC refers to description. So description of the function is start, the application with
the details of the current course and lecture that is the description.

Then rat this short form represents rational as listed in the convention section so one rational part
is also added although we did not discuss it in our earlier lectures. It is optional like description
so what is the rational for this function the instructor might be taking multiple courses and
lectures involving different students. So the application needs to adjust to the circumstances
accordingly so this is the rational for this function.

So ideally in any function description all these components should be present. Now under this
top level function we have second level 1.1 establish connection for instructor. Now this is
having id FR INS 1.1 again input course administration details, output connection request to all
students present and acknowledgement for the instructor. So here like I said you need not
mention that connection request sent to all students so sent is an action what you should avoid.

Acknowledgement sent to the instructor again that is sent is action what should avoid so simply
you mention this. Then DESC description says establish connection with the students present
currently in the class and rational is without connection between the devices information cannot
be communicated so we need this function.
(Refer Slide Time: 34:43)

The next function which is under this second level function established connection is real time
individual student attention statistics. So by the numbering we can understand where in hierarchy
it stands so it is ID is FR INS 1.1.1 input is provided sensor data from student devices output is
also provided details of the student’s attention at that instant. Description is an option for getting
insight on real-time attention activity of the students on an individual basis and rational is for
monitoring an individual student.

Then under the same level 1.1 we have another function real time overall class attention statistics
with an ID for INN 1.1.2. Input sensor data from student devices output summarized pictorial or
textual portrayal of the class’s attention details at that instant. And description an option for
getting insight on real time attention activity of the students on an aggregate basis and rational is
for monitoring the class as a whole. So here this specification follows the hierarchical notation
that we have learned earlier with slightly different conventions than the one we have seen earlier.
(Refer Slide Time: 36:15)

So under, 1.1 there is one more function 1.1.3 end class session with ID, input, current session
tokens; output exits the current course page and closes all impending connections. Now here lots
of action words are used exits closes so this type of output is to be avoided. So it has to be
refreshed avoiding the action word so this is a bad way of writing so in this document I will
show you the good things as well as the bad things.

So you should note that earlier things that we have discussed are good things but there are some
bad things also involved in this document like using action words in specification of input and
output for functions you should try to avoid them. Here description is given as close the currently
opened connections and the application. So in description you can use as many action words as
you want but in input and output you should be more careful.

Then under the top level hierarchy there is second function connection error notification this is
again for the instructor. Having an ID an input specified data flow across instructors and student
devices now having an output specified error message in case of interrupted or stop data flow. In
fact when you are specifying output you do not need to mention it in this details you can simply
say error message. For, whatever reason you do not need to mention here that can be explained in
description part.
As done here notify instructor in case of connection drop or a particular of a particular student
for whatever reason. And rational is in case of faulty connection or inefficient instruments
appropriate error message should be generated that is the rational for this function. So that is
about top level function which has 2 sub functions under it one of the sub functions has further
sub functions as we have seen.
(Refer Slide Time: 38:41)

Now second top level function is overall class attention this is again for the instructor it has ID,
input, output, description, rational, all specified output everywhere you can see there is this
mistake of using action words like displays it is not necessary. You can instead simply say
attention span details of entire class or attention span details of a class for a lecture. You need not
mention that displays attention class details attention level details all these things so display is an
action word we should avoid.

Whatever action word you need to use you can put it in the description part and rationalize helps
the instructor during feedback session and grading process. So under 2 we have 2.1 so that is one
sub function individual student monitor with ID, input, output and description it is not necessary
to provide rational at every function, sub function in the hierarchy 1 or 2 places is good enough
for the whole hierarchy.
And as we mentioned earlier also description if it looks repetitive you can avoid because that is
optional. So if top level function description is repeated in the lower level function descriptions
then it is better to avoid rather than repeating. Like here 2.2 here description is avoided so it is
under the top level function of overall class attention level 2 second function under it upper
division threshold filter.

One function designed here ID is mentioned, input is mentioned, output is mentioned so no

mention of description and rational. Again in output displays word is used which is not a good
thing avoid it. Another function under second function is 2.3 lower division threshold filters with
ID, input and output avoid action word.
(Refer Slide Time: 41:09)

Here again some rational is given rat because it is different from other rational given under this
same hierarchy. Then 2.4 sort students by attention span with ID, input, output, description, no
rational given. So rational description these are optional but ID name, input and output are
mandatory. So that is about instructor class for that class what; are the functions that are ideally
to be present in the proposed system?
(Refer Slide Time: 41:47)
Now let us move to the second class of users that is the student so here again like instructor class
we can have hierarchy open course page ID, input, output, description, rat. Now everywhere you
can see that in this document this mistake has been made that is use of action words in specifying
input and output like entering course name not required. You can simply specify as input course
name and lecture details.

No need to use the action word then output mentioned that related course page is opened not
required then simply say related course page so this you can avoid. Description whatever you
need to put in you can put in start the application with the details of the current course and
lecture and rational also is given here. Under one there are some subs functions 1.1 establish
connection like for instructor with ID, input, output, description, rational.
(Refer Slide Time: 43:06)
Then we have under this function, sub function, sub-sub functions 1.1.1 pause monitoring with
ID, input, output, description and rational everywhere you can see that this mistake of using
action words has been done. For example here in 1.1.1 in output you can see put the connection
on hold and provide appropriate feedback message this is not a good way of writing output.
Instead you can simply write feedback message this can be the output rather than this whole
process.

Because put the connection on this refers to; actually a process rather than a specific output.
Avoid mentioning action words which indicate process rather than output. Then we have
description and rational similarly we have under this function 1.2 that is second top level
function error notification student with ID, input and rational.
(Refer Slide Time: 44:26)
Then for user class 2 we have another top level function student attention span feedback having
ID, input, output, description, rational everything mentioned as before. So these are the functions
that constitute the functional hierarchy for the product so functional hierarchy is the main thing
in any SRS document. Later on we will see how usability requirements can be converted to
functions and added in functional hierarchy.
(Refer Slide Time: 44:26)

Apart from functional requirements and SRS document should also contain details about other
non-functional requirements. So here it includes performance requirements, requirements related
to performance of the product something is listed here. Like the search enabling the instructor to
view the summary of a student and give his analysis should be clear and well understandable.

The program must update the real time statistics at a fast enough pace so that the instructor can
have a clear view on the current attention of the class. The program must be able to handle the
information of the entire class a full attendance almost 90 students and also individually without
any glitch. So it mentions some size of the full class which is having 90 students but that is of
course variable.

Time to give the error message on losing a particular connection should be minimal so it should
be fast response. So these are some of the issues that are highlighted here related to performance
of the product.
(Refer Slide Time: 46:18)

Then there can be security requirements listed these are all non-functional requirements like the
students enter their authentication to enable access to connection to the slides. Since the
environment is local or limited to the classroom no security precaution or encryption of data is
necessary because it is to be executed over a small area network. Then software quality attributes
can be listed out. Code should be modular and well written so as to facilitate further addition and
implementation of new features and improvements.
The system should be robust enough not to fail during the class. These are high level
requirements non-functional requirements that are mentioned. So what we have learned here that
how to create an SRS documents what to be kept one thing you should keep in mind is whatever
sections and subsections are discussed in this example document need not be present in every
document.

So you have to choose depending on your application area what are the sections and subsections
to be kept. Most important component is of course the functional requirements; which lists out
the functions that are to be there or to be supported by the product to achieve the objectives. But
equally important is also non-functional requirements. Here in this example document only a few
broad non-functional requirements ideas are given but in reality it has to be a little bit more
detailed.

As we have discussed during our discussion on non-functional requirements different

requirements can be listed out. And usability; requirements which is a non-functional
requirements has to be listed out in more details than what is shown here. Also keep in mind that
some of the usability requirements can be actually represented as functional requirements which
we shall see through examples in later part of the course.

Another important thing that you should note is how to write functional requirements because
that is the core component of any SRS. In functional requirements ideally you should avoid using
action words in specifying input and output. Action words make those look like processes rather
than inputs and outputs so that to be strictly avoided. In functional requirement you should have
this level identifier name of the function, input, output specified without any action words and
optionally.

Description where you can use as many action words as you wish as well as the rational for this
function; why we are going for this function? So both description and rational are optional but it
is better to keep it in your document. So with that I would like to end this lecture so I hope you
got some idea of what is SRS? How it looks? What are to be considered while creating SRS? We
will see some more examples in subsequent lectures to understand in better way how to create
good SRS’S.
So I hope you have learned the idea of V through this example and enjoyed the lecture I am
looking forward to see you all in the next lecture. So we will meet again in the next lecture thank
you and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology, Guwahati

Module No # 03
Lecture No # 09
Case Study (Usability Requirement Gathering)

Hello and welcome to NPTEL MOOCS course on design and implementation of human
computer interfaces this is lecture number 8. In this lecture we are going to talk about a case
study on usability requirement gathering practices. So we are concerned about the design as well
as implementation of interactive systems.
(Refer Slide Time: 01:11)

In other words of human computer interfaces as we have seen in the earlier lectures human
computer interfaces or the interactive systems are distinct from other software systems. In
interactive systems primary concern is to make it quote unquote easy to use to laymen persons.
Now easy to use has a more formal notion which we are calling usability which is more
standardized way of saying the same thing easy to use.

So the objective in the design and implementation of human computer interfaces is to design and
usable system. And usable system design requires us to take users into account while designing
the system due to the necessity of taking user input into account lots of additional activities we
have to do. To systematically represent the whole design and development process we take
recourse to what is called software development life cycle?

Which is a stage wise representation of the entire development process? For interactive systems
we are discussing one such development life cycle having several stages and sub stages. So
before we start let us have a quick look at this, life cycles and its stages. So we have requirement
gathering analysis and specification stage we have design stage, we have prototyping stage, we
have early evaluation stage.

And these 3 stages design prototyping and early evaluation these together constitute a cycle. So
from design we go to prototype it then go to evaluate it based on evaluation result we refine our
design and this goes on till we come to a design where further refinements may not be required
or necessary. This cycle is generally called design prototype evaluate, cycle we can refer to this
cycle as design prototype evaluate cycle.

One thing to note here is the design refers to both design of the system and design of the
interface and interaction. So there are 2 distinct things that we wish to specify here or we wish to
refer to here. One is the interfaces and interactions which is the way in which a user views the
system. The other is the actual system which is the way a developer or programmer views the
system.

So; design refers to both types of views so from the users point of view design of the interface
and interaction and from the developers or programmers point of view design of the system. In
this cycle we refer to both the design first we will finalize design of the interfaces and
interactions and afterwards we finalize the system design. Now once the system design is
finalized it may be noted here that system design may not require prototyping but interface
design requires prototype and evaluation all these other sub stages in this cycle.

Now once we finalize the system design we go for implementing the design in the coding and
implementation stage. Then the code is tested for bugs so code testing is another major stage in
the interactive software development lifecycle. So after code testing we may get a system that is
bug free and executes properly. However we still do not know with code testing only whether the
end product is usable. Code testing will not tell us about the usability of the system it will only
tell us about the execution efficiency of the system.

So in order to know the usability we need to carry out another type of test which is called
empirical test also known as empirical study or empirical research. Here we get our system tested
with end users through a systematic and scientific process. Now result of this test may reveal
certain issues of the system vis-a-vis usability. So in order to take care of those issues we may
need to refine our design in other words we may have to go back to this cycle.

But ideally it should not be frequent because usability study or empirical study is a costly affair.
So if we need to frequently revise our design and go for empirical study then it will lead to cost
and time over run. So ideally we should aim to identify major number of problems within the
cycle itself initially in the initial stages and maybe once or twice we may enter this other cycle
this bigger cycle.

Once this usability issues are taken care of and we are ready with the final executable and usable
product we go for deployment and maintenance. That is ideally what should happen when we are
going to develop an interactive system. Now we are discussing different stages of the system so
we started with the requirement gathering stage. So earlier we discussed how to gather
requirements?

Here by requirements what we are referring to are 2 types of requirements one is usability
requirements other one is functional requirement so both the requirements are important.
(Refer Slide Time: 08:15)
Now we have learned about what are these different types of requirements and how to gather
those? In this lecture we are going to reinforce our learning with one case study of gathering
usability requirements for a practical system.
(Refer Slide Time: 08:34)

So what is our example system that we are going to discuss that is a calendar app which we have
mentioned in the earlier lectures. Now here we are specifying it in a little bit more details. So our
objective is to build a calendar app which is primarily meant to be used by students with the
objective of helping them in their various academic activities. So that is the broad purpose of the
app so user group is defined which are, students and purpose is to help them in their academic
activities.

So in this case study we will try to find out how gather usability requirements for this particular
app along with that we need to specify those requirements so we will also see in this case study
how to specify those requirements.
(Refer Slide Time: 09:35)

So usability requirement is one sort of non-functional requirement along with many other
non-functional requirements. However our main focus here is only usability requirements so we
are not going to discuss about other non-functional requirements for the app. Now in order to
gather these requirements we need to perform certain activities. So there are different ways to
gather these requirements as we have learned earlier we have seen earlier.

One of those which we have discussed in details in earlier lecture is contextual inquiry. So for
our example system let us assume that we are going to perform a contextual inquiry and based on
some hypothetical data let us see how we can get the usability requirements.
(Refer Slide Time: 10:31)
So before we proceed further let us quickly recap what we mean by contextual inquiry? So
contextual inquiry is a process which involves 5 steps now this process is observation based
primary objective is to observe the users in their work setting or context of use. To aid the
observations the observer may occasionally take recourse to interviews to get clarifications on
certain behavioral aspects of the user system interaction in the work context.

Now there are 5 stages to carry out the observations to make the observations more systematic
and less prone to errors first stage is plan. So before we start any contextual inquiry process we
should plan what we are going to do in the process preferably in the form of a script. Where we
note down the step by step sequence in which we are going to perform the inquiry so that is the
first planning stage.

Then initiate in this stage what we do we start the process but not the process of data collection
rather. We start the process in the form of communicating with the potential users for their time
and to explain to them the purpose so that they are less anxious and willing to let us observe their
behavior. After these 2 initial stages come, the actual data collection stage or the observation
stage. This is called the execution stage or execute stage here we actually observe and record our
observations.

If you may recollect these, observations can be performed in either of the 2 ways either in active
mode or in passive mode. In active mode the observer is physically present in the work setting
and observes in passive mode the observer is not present somehow the observations are recorded
and the recordings are viewed later for gathering requirements. After execute stage comes the
closed stage.

So in this stage some thank you notes are sent to the participants so that they are formally
notified about the closure of the process as well as they are given some incentives so that in
future if required their services can be availed. And finally whatever data we have collected
during observations are analyzed and results obtained in the reflect stage that is the final stage of
the contextual inquiry.
(Refer Slide Time: 13:41)

How do we analyze the data? So as again we have learned in one earlier lecture that we can
follow different methods but one method we have learnt in some details that is the affinity
diagram method. So in this method what we do again let us quickly recollect the procedure for
affinity diagram method.
(Refer Slide Time: 14:05)
So this method involves 5 steps first is generate idea that means after observations whatever you
observe from there take note or generate ideas. Then display those ideas in some manner it can
be as simple as noting down the observational behavior in some simple textual format on a sticky
pad or sticky notes and then paste or attach those notes on a simple white wall or white board for
later brainstorming.

Third stage is brainstorming stage where the ideas which are displayed needed to be sorted into
groups then once the groups are identified we need to create the group headers. And finally we
need to draw the finished or final affinity diagram where we have ideas sorted into groups with
headers and arranged in some sequence. So these are the 5 steps through which we can analyze
the observational data as we have discussed in one of the earlier lectures.
(Refer Slide Time: 15:47)
Now let us come back to our example problem so we are required to build a calendar app for use
by students to help them in their academic activities. So for this app we need to identify what is
the usability requirements for that let us assume that we have performed one contextual inquiry.
Now in this inquiry we have observed some students during their activity hours maybe inside
class or outside class in their group discussions or some such other settings we can observe them.

And let us assume that they have used paper based calendars as one mode of calendar then
desktop based calendar and also mobile calendars. And we have observed them using these
calendars only for academic activities not for any other activities because we are interested only
for such work settings. So this is actually very important that the work setting that you have in
mind while building the app should be replicated during this observation process.

So ideally if your work setting is one specific scenario and you are collecting data for another
scenario then that data may not be relevant for the particular work setting that you wish to have
while the system is used. So replicating work setting is very important in contextual inquiry
method. And here accordingly we can assume that we have observed students use calendars
either paper based or desktop based or mobile based during academic activities only.

So we have made some observations and noted down those observations may be on a sticky pad
and then we use the affinity diagram method to analyze those observations. So let us assume that
some hypothetical observations are made.
(Refer Slide Time: 18:19)

So then let us go through the let us go through the stages of the affinity diagram method. First we
will discuss the observations that we have noted on sticky pad one observation is something like
this that the calendar is used by all the users to set reminders. Be it paper based or desktop based
or mobile based everybody used it in some way to set reminders for various academic activities.
Suppose we have performed the study with 5 users so one observation that can be made is 4 out
of 5 users used the calendar to check upcoming deadlines.

So that is another use usage behavior that we have observed and noted down duly on a sticky
note. We can have yet more observations for example 3 out of 5 users used mobile calendar app
to check day and date and set reminder for assignment submission. So majority of the users who
participated in the contextual inquiry process actually made use of mobile apps because that
probably is convenient to use.

However contextual inquiry has nothing to do with the explanation of the behavior rather only
observing the behavior. So we will not go into the explanation of why this particular observation
has been made we will just observe and note down. So the observation is a majority of the users
preferred to use mobile apps for checking what day it is and what date it is and accordingly set
reminder for assignment submissions.
We probably could have made another observation which is all users use the calendars in
whatever form either paper-based desktop or mobile to check lecture schedule on a particular
day. So that is another observation that probably could have been made with calendars. A fifth
observation that possibly could have been made is that again a majority of the users 3 out of 5
used the calendar to check meeting schedule on a particular day.

So the academic activities also include several meetings maybe with peers with supervisors so on
and so forth. And it is observed that majority of the students or users checked meeting schedules
with calendars for a particular day. 4 out of 5 users used calendars to check date and then
checked timetable for that date so 4 out of 5 users wanted to know the timetable.

So they checked it from the calendar and checked timetables for that particular day to get
information about the classes on that day. Again 4 out of 5 users were found to use the calendar
whichever calendars they have access to check meeting dates. So that is another observation that
4 out of 5 users used calendars to check meeting dates. So these are some of the observations that
hypothetically can be made with a contextual inquiry method for our calendar app.

Now there are 7 observations or 7 notes which are generated and displayed. So from
observations so note here the terms idea generation and display idea so idea generation means
from observations generate those ideas that are just that have been discussed in the previous part
of the lecture. So converting observations to such short descriptions is what is being referred to
as generate ideas.

And then putting up those ideas in some form so that they are easy to visualize is what is being
referred to as display those ideas so here to display we probably can use one wall on which we
can paste those sticky notes.
(Refer Slide Time: 23:38)
The step 3 of the affinity diagram is grouping so in this step we are expected to perform
brainstorming and sort similar ideas into groups or cluster similar ideas into groups. So; let us
see with this seven notes or observational ideas whether we can form group or not. So 2
observations are one is the calendars were used by all the users to set reminders and we have also
observed that majority of the users 3 out of 5 used mobile apps to check day and date and set
reminder for assignment submission.

So everybody used calendar majority used mobile calendars so these are for setting reminders
these appear to be similar ideas so we can combine them into a group as shown here with the red
circle. The remaining observations can be combined together to form another group so you will
have only 2 groups because number of observations are less. What are the remaining
observations 4 out of 5 users used calendars to check upcoming deadlines.

4 out of 5 users used calendars to check date and then check timetable for the date 4 out of 5
used calendars to check meeting dates 3 out of 5 used calendars to check meeting schedule on a
particular day. All users used calendars to check lecture schedule on a particular day again
apparently all these seems to be pointing towards similar concepts so we can group them
together so total seven observations can be divided into 2 groups, groups of observations.
(Refer Slide Time: 25:50)
The next stage is assigning some headers which convey the broad message in a group of
observations. So we have these 2 observations one is all users used calendars to set reminders
and 3 out of 5 users used mobile apps to set reminders these 2 we already grouped together now
let us try to assign a header to this group. So broadly what these notes or the observations that we
have noted refers to broadly they refer to the activity of setting reminders or reminder setting
activity.

So we can actually assign this particular header to this group the header can be reminder setting
under which these 2 observations will fall.
(Refer Slide Time: 26:49)
Similarly the remaining 5 observations also convey some message what is that message so what
are those observations. One is 4 out of 5 use the calendars to check upcoming deadlines, 4 out of
5 use the calendars to check date and then check timetable for that date. 4 out of 5 used calendar
to check meeting dates, 3 out of 5 used the calendars to check meeting schedule on a particular
day and all users use the calendars to check lecture schedule on a particular day.

So these, again seems to be referring to a broader concept that is scheduling of academic work or
work scheduling. So accordingly we can assign this group name to these groups group of 5 notes.
(Refer Slide Time: 27:46)

Now they can be different ways to perform the grouping of course what we have just discussed is
one way. Another way can be breaking those 5 observational notes into 2 groups rather than
having a single group. One group may refer to the broader concept of overall scheduling of
activities under which these 2 observations fall. 4 out of 5 users used calendars to check
upcoming deadline, 4 out of 5 users use the calendar to check meeting dates.

So; these 2 can be grouped together into a broader group which can be given a header like
overall scheduling. Then the remaining 3 that is 4 out of 5 users use the calendar whichever
calendars they have access to. To check date and time table for that date 3 out of 5 used calendars
to check meeting schedule on a particular day and all used the calendars to check lecture
schedule on a particular day.
These 3 may be grouped together and can be given a heading such as day wise scheduling so one
is overall scheduling one is device scheduling. So we have both the options so either we can
group all the 5 observations together and have a single heading or we can split them further
create multiple groups out of those observations. Obviously the latter grouping is better because
here we can get a better cohesion among the notes.

Whereas in the previous case, when we club together all the 5 observations the heading does not
reflect everything that these observations contain.
(Refer Slide Time: 30:01)

The last stage in the affinity diagram method is very simple stage that is we need to display the
final diagram affinity diagram. So we have one group, group header is reminder setting and there
are 2 group members which are notes pertaining to observations the 2 notes. Then we have
another group overall scheduling where again we have 2 notes pertaining to observations under
this group.

We can have a third group day wise scheduling where we have 3 observational notes one, 2, and
3. So this is how we can create and display an affinity diagram at the end of brainstorming
session. So that is expected to give you some idea of what you need to do to gather usability
requirements.
(Refer Slide Time: 31:21)
However with respect to this particular example we should keep in mind few things which are
applicable whenever you are also going through the similar mechanism. First of all whatever
observations we made are not universal truths that we should always keep in mind. The
observations are for all types of calendars used in the study if any calendar type is left out then
these observations do not apply to them.

Same observations we can group in different ways. We have already seen how to do that in one
grouping we have 5 observations grouped together in another grouping scheme we have 2 groups
which we have formed out of the 5 observations. So that is those are some of the things that we
should keep in mind that whenever we are observing something we should only claim the
validity of the observations with respect to the specific work setting.

And we should not claim that these observations hold true for any work setting. And secondly
grouping is very important because once we group them then we should find out a header that
aptly describe the nature of the group. Now the more precise the groups are the easier it is to find
out a header. So accordingly our grouping activity needs to be very carefully thought out and we
should keep always in mind that there is no unique way of grouping.

So whatever grouping scheme we think of there can always be alternative schemes. So we should
always keep our thinking open and try to come up with as specific and precise grouping as
possible so that we are able to assign suitable group headers. Now we have created this diagram
so that is the first stage that we have collected usability requirements remember that usability
requirements are non-functional requirements.

So this affinity diagram method gave us some way to indicate the requirements in the form of
groups and group headers. Next is what to do with the grouping so that we will cover in the next
lecture. So that is all for today and in the next lecture we will learn about what to do with the
output of the affinity diagram method. And how to specify the requirements, so that they can be
converted easily to implementable ideas that is all for this lecture. Hope you have learned and
enjoyed the learning looking forward to see you in the next lecture thank you and goodbye you.
 Design & Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Module No # 02
Lecture No # 10
Case Study (Other Requirement Gathering)

Hello and welcome to NPTEL MOOCS course on design and implementation of human
computer interfaces we are going to continue with the case study in this lecture number 9. So we
started the case study in the previous lecture on an application development and in this lecture
we are going to continue with the case study. So before we go further we will first have a look at
where we are in this course.

So we started discussion on interactive software development life cycle. As repeatedly we have

discussed there are many stages which form the life cycle. These stages are performed in a
particular sequence and sometimes the stages form a loop.
(Refer Slide Time: 01:55)

So if you may recollect the stages first one is feasibility study which anyway we are not
focusing, on second is requirement gathering analysis and specification, third, is basically a set
of sub stages performed in a loop manner. So the sub stages are design sub stage, prototyping sub
stage, and quick evaluation of prototyping that is another sub stage. So together they form a
cycle which we are calling the design prototype evaluates cycle.

So through this cycle we do 2 things one is we design the interface as well as interaction and also
we design the system. Now once the system is designed then we go to the coding and
implementation stages this is followed by the testing stage where we test the code or the
program. Another testing stage follows which is empirical user testing or usability testing
through this testing we get to know usability of the end product.

And occasionally it may lead to returning back to this cycle design prototype evaluation cycle if
we find some problems in the usability testing phase but that is typically very infrequent. And
once we are certain about the efficacy of the code as well as usability of the product we go for
the next test that is that is deployment and maintenance. So among these stages we are currently
covering the requirement, gathering, analysis and specification stage.

We have already learned what we mean by requirement gathering analysis and specification. To
recap so there are 2 things involved one is requirement for whom and then how to specify those
requirements? First question is for whom we are collecting the requirement? In typical software
development process requirements can be obtained through interviews with clients or customers
as well as based on experience of the designers.

However in this case along with requirements provided by the clients we also need to know the
requirements of the actual end users. So here we are distinguishing between the clients and the
end users. End users are layman users who need not have any technical expertise but they just
want to use the system for achieving certain goals. So when we said requirement gathering so we
focused on these 2 aspects.

First of all to gather requirements from end users which is likely to lead to usable systems these
requirements we are referring to as usability requirements. To gather those usability requirements
what we did we have gone through one particular method called contextual inquiry method. So if
we follow this approach and implement it then we are likely to find out some requirements that
lead to better usability.
Other thing is so usability requirements are nonfunctional requirements from the point of view of
a system developer there is another category of requirements which typically comes through
interaction with clients as well as through prior experience of the designer.

Now these are called functional requirements where we actually get to know the requirements
and get to specify those requirements in the form of functions with clearly defined input, output
and some optional description of the functions. We have briefly looked at what these functions
are how they can be specified and what they refer to in the context of a system development.
(Refer Slide Time: 06:48)

Now let us come back to our case study so we are currently discussing on a case study pertaining
to the development of a calendar application or app. Now this application is primarily meant to
be developed for students who are expected to use it for academic purpose. So our user group is
fixed students more specifically college going students or students enrolled for higher studies.
And the work context is also fixed that is academic environments which include classrooms
which includes PR discussion groups and so on.

And if these are specified then what we are discussing is? How to find out the requirements both
non-functional and functional requirements? So in the previous lecture we have discussed how to
find out the usability requirements through contextual inquiry. In this lecture we will try to see
how to find out functional requirements which can be specified in the form of functions.
(Refer Slide Time: 08:20)
So calendar app is our example application development scenario and as I said this meant for
students primarily students enrolled for higher studies in colleges or universities and the app is
meant to help them in their various academic activities. So their work setting is also specified
given this specifications let us try to find out what are the functional requirements for this
particular application?
(Refer Slide Time: 09: 02)

Now before we start discussion on functional requirement let us quickly review the basic ideas.
So when we are talking of functional requirements essentially we are trying to find out functions
with specific input, output and description. Now these functions are not to be specified in details
instead we will assume that the functions are black boxes whatever input is given somehow it is
processed and generates the desired output.

So we will assume that that output is generated the function is designed in such a way rather than
focusing on how to design the function so that the output is generated from the input. So this
black box assumption of function is what is called abstract way of looking at the function or
abstraction. So this abstraction is very important we think of the functions in a very abstract way.

Second thing is decomposition and hierarchy so when we are talking of functions we should not
think of complex functions instead we try to divide functions into sub functions up to the level
wherever we feel it necessary. And we should strive to create a hierarchy of such functions and
sub functions. As we have seen in one of the earlier lectures that hierarchy actually makes things
easier to understand and implement in subsequent stages.

So decomposition of a function into sub functions and creating a hierarchy is very much
desirable along with the way to conceive the functions or the abstractions. So both are important
and should be kept in mind while we are going to find out functional requirements.
(Refer Slide Time: 11:01)

Now let us see what can be the functional requirements for this particular app. So we will here
rely on our intuition although we may think of this intuition as coming from interview with
clients or customers who have told us to build the system. It may also come from the past
experience of the developer or the development team. So whatever be the case we can still
identify few functions for this particular first of all the app should display dates in specific
manner.

So; first requirement is how to display the dates in the calendar app which is suitable for
specified user group in specified work setting. Now there are many possibilities in which we can
display these dates. Our objective is to find out one of those possibilities and then specify that
particular possibility.
(Refer Slide Time: 12:18)

So we will see how it can be done next obvious requirement is support for a student’s academic
activities. Now this may include setting reminders for lectures, setting reminder for exams,
setting other academic event reminders. Such as peer meetings, talk’s seminars so on and so forth
now here the term event should be noted carefully. In subsequent part of this lecture I am going
to use the term event to actually indicate a host of things including lectures exams meetings
talks.

So everything will be termed as event without any further disambiguation and that is good
enough for our purpose.
(Refer Slide Time: 13:16)
Now these are some obvious requirements there may be some other requirements or some
additional functionalities. Synchronization with email may be one such functionality so in this
functionality what is required is synchronize with email accounts of the user. So that if there is
any extrinsic event created with the e-mail account then it is automatically reflected on the
calendar with specified date and time.

So even if you are not explicitly using the calendar but saved some specific events with your
email then the app should be able to fetch that information from account and then display it on
the calendar. There may be another cosmetic function that is set or reset the application
background for aesthetic purpose. So user may be given the freedom to set or reset the
background so that is another requirement that we can think of.

So once the requirements are identified our next task is to specify them. Now for specification
earlier we have seen that we can use a notation for specification and the resulting document that
we get is called SRS or software requirement specification document.
(Refer Slide Time: 14:56)
So the notation involves creation of function name with description and clearly specifying the
input and output of the functions. So for each function we need to do these things clearly
specifies input, output as also provides some name and description. So; for the functions that we
have identified for the calendar app. Let us see how we can create the SRS document so first we
will focus on how to specify the functions that we have identified.
(Refer Slide Time: 15:37)

So from this specification we will get the SRS document for the calendar app now let us try to
see how it is or how it can be done?
(Refer Slide Time: 15: 48)
So we will first have a look at requirements earlier we have discussed it informally let us now
formally discuss the requirements. Now for the requirement for a user to view dates with events
if there are any such events for the specific date. Then we can have further requirements like
requirement to view months, for a year requirement, to view days for a month and requirement to
view event listings for days for each day or a special chosen day what are the events that are
listed against it.

We may also need to jump to any date from the current date with events listed for that day so this
may be one additional feature or function that should be available with our calendar app.
(Refer Slide Time: 16:59)
So accordingly we can create a functional hierarchy for all these requirements. So at the top level
of the hierarchy we have display calendar function which is the top level function then under it
comes sub function display months, display days with events and specific date view that is the
last requirement jumping to any date. So if we jump how to display that particular date note here
the abstraction.

So we still have not discussed anything on how to implement these functions rather we are only
focusing on what are the functions and how they can be organized in the form of a hierarchy.
(Refer Slide Time: 17:54)

Now let us see how we can specify it? So since display calendar is the top level function. So we
give it a name display calendar along with this label showing the level of the hierarchy. And for
this top level function we provide an input that is year month or date as input and there is an
output which is specified which is corresponding months days or lists of events for a day. So if
we are inputting on then the output will be the months of the year.

If the input is month then the output then the output will be days of the month if the input is a
day then the output will be the list of events for that day. There can be a description also but as I
said earlier this can be optional but ideally it should be there to clarify the purpose of the
functions. For example in this case we can have a description like in this function the user can
view months of a specified year or days of a specified month.
The user can also view the events deadlines in a month or days of a month or on a specific day.
So this is the purpose of the function why we are designing it to serve this purpose so description
gives us that idea of the purpose. So here we have all these components name, input, output and
description and note that name is having a label this label is representing the level of the
hierarchy.
(Refer Slide Time: 20:06)

Now below the top level function there are 3 sub functions that we have mentioned in the
hierarchy. First sub function is display month so again here we have one name with label which
indicates the level of the hierarchy. Since this comes under display calendar function so we are
giving it a level 1.1 that means under 1 this is the first sub function. So in this case the input is
year, the output is months of the year and description is in this function the user can view months
of a specified year that is the description so it is as simple as that.
(Refer Slide Time: 21:18)
Then we will move to the next sub function that is display days with events. Since; it is the
second sub function as per our hierarchical display so we are giving it a level 1.2. Now in this
case input is month and output is days of the month along with day wise event lists if there are
any such events. Description in this function the user can view the days of a specified month for
each day the associated event list is also displayed if there is any such event so this is our second
sub function in the hierarchy.
(Refer Slide Time: 22:11)

Now there is third sub function accordingly we have given it a level 1.3 and the name of the sub
function is specific date view as usual. So under this sub function we will have input output and
description. Let us see what is the input? What is the output? And what is the description for this
sub function? Input is date, output is events and description is in this function the user can view
the events for a specific date.

So if there is no event then it will not show anything if there are events then the list of events will
be shown. So that was about one requirement let us move to the next requirement for event
reminder setting.
(Refer Slide Time: 23:12)

So for a user to set reminders for academic events day wise what we need? We need to create
device events, we need to edit device events and we need to delete device events.
(Refer Slide Time: 23:45)
So these 3 sub functions should be good enough to represent this particular requirement of
setting reminders for academic events. So let us see how they can be arranged in the form of a
hierarchy so that is quite straight forward. So top level we have set reminders as the top level
function then below it sub functions come first is create reminders, then edit reminders and then
delete reminders. So this hierarchy looks similar to the previous hierarchy that we have already
covered.
(Refer Slide Time: 24:45)

Now let us create the corresponding SRS or specify these functions in the form of textual
description as we have seen earlier. First is the top level function so since it is another top level
function so we have given it the level R 2 the previous top level function was R 1 and the name
is set reminders. Now as per requirement so we have to provide the input which in this case is
date and event details with time.

And we need to specify the output which is reminder for the event at the specified time on the
specific date. Finally there is this description which says that in this function the user can create,
edit, delete reminders for specific academic events on specific dates and times. So this top level
function talks about all the three sub functions create, edit and delete and then under the sub
functions will specify which of these activities are applicable.
(Refer Slide Time: 26:09)

So as per the hierarchy we have set create reminder as the first sub function so accordingly we
have given it a level 2.1. 2 because it comes under the second top level function and 0.1 or 2.1
because it is the first sub function of the second top level function. Then there is this input which
is date event name and time together constitute the input output is reminder for specific event.
And description is in this function the user can associate a specific date and time with a specific
academic event this is the description for this sub function.
(Refer Slide Time: 27:09)
The second sub function under top level function is edit reminder so we have given it a label
R2.2. In this we have input as date and reminder output as date with revised reminder and
description as in this function the user can modify specific reminders such as time or event name
for specific dates. So this is the second sub function under the second top level function.
(Refer Slide Time: 27:53)

The third sub function is delete reminder so we have given it a level R2.3 for the same reason
that we have mentioned earlier. Here input is specific reminder, output is date without the
specific reminder and description says in this function the user can remove specific reminders
associated with specific dates. So that is the description for this third sub function of the second
top level function.
(Refer Slide Time: 28:43)

We also mentioned some other functions for example set the background user can set the
background to make it look better quote unquote better as per his or her aesthetic judgment. So in
order to have this function we need to be able to add background and we need to be able to reset
background both are requirements for setting background task.
(Refer Slide Time: 29:20)
So accordingly we can create yet another hierarchy of tasks or functions and sub functions. So
top level function is set background and under this comes set theme and reset theme so these 2
can be considered to be 2 sub functions for the top level function set background. So let us
quickly have a look at how to specify these functions and sub functions using the SRS notation?
(Refer Slide Time: 30:11)

So top level function is set background name given is set background and label is R3 because
this is the third top level function we are discussing. Its input is image or set of image output is
tab background with choose an image. So ideally its input should be one image and output
should be the app background with chosen image so the image is the background. We can write
as its description text like in this function the user can set or reset app background. So both the
activities can be written in the description of the top level function.
(Refer Slide Time: 31:16)
Then we will specify the lower level of the hierarchy the first sub function that is set theme so
we are giving it a label 3.1 because it is the first sub function of the third top level function. Now
here input is theme image output is app background with choose an image and we can have a
description as in this function the user can set app background. So this can be a simple
description of the function.
(Refer Slide Time: 31:50)

Then for the second sub function we can have a label R3.2 and the name as reset theme it can
have an input again as a theme image in the form of a theme image and output will be the
background with the chosen image. So in both the cases input output is similar in nature only the
content varies description is also similar in this function the user can reset app background so we
can have similar way to specify input, output and description for this two sub function under the
top level function.
(Refer Slide Time: 32:42)

Setting background is one requirement then we can have one more requirement which we
discussed earlier that is synchronize with other email accounts. So that if something is listed and
linked to this account then it automatically comes to the calendar display. In order to achieve that
we have further requirements one is to add account to the application second one is to delete
account from the application. So I may need to remove the synchronized account so some
facilities should be provided for that also.
(Refer Slide Time: 33:23)
So we can create in a very simple manner hierarchy so top level function is synchronized under
this comes 2 sub functions one is attach account and the second is remove account. So the
hierarchy can be created in a similar manner in which we have created the earlier hierarchy and
once this is created we go for creation of the specification document or the SRS part for these
functions and sub functions.
(Refer Slide Time: 34:13)

So how the SRS should look for this top level as well as the sub functions for the top level
function we can give it a label R4 because this is the fourth top level function and the name
remains the same synchronize. Then we have input as details of account to synchronize with
output as synchronized reminders. And description in this function the user can synchronize the
calendar with his or her respective email ids.

So that any extrinsic event meeting created with the email account is also reflected on the
calendar with date and time. Slightly longer description however it conveys the purpose of the
function. Now again take a pause and have a look at what we are doing just for pointing that out
again we are specifying a function. But nowhere we are talking about what this function should
be doing only we are giving it a name so that is abstraction and a purpose.

That is again enforcing the abstraction idea then we are specifying input and output now while
specifying we are not specifying the exact nature of the input that is also important. Again input
and output is also specified in an abstract and flexible manner like here details of account is an
input. Now how to provide that detail should it be a textual string should it be an alphanumeric
string should it be uni-code compliant string should it be in some other format.

These details we are not providing and we are not interested also because those are
implementation details so those are not part of this stage of requirement specification. That is
very important for you to keep in mind that in requirement specification we do not bother about
implementation details such as in which format to specify and how to process the information?
So neither we are interested in finding out the algorithm for this function to implement nor, we
are interested in specifying the exact input and output format.

Rather we will keep it as abstract and flexible as possible so that later on designer can make a
choice depending on availability of platforms, resources, manpower and other things. So
synchronized reminders, is output but we are not specifying what it means exactly to be having
an output called synchronized reminders. So it simply states that the reminders are now
synchronized with the display and they are now visible on the display.

But what that exactly means and how that is done is not what we are specifying here rather only
the, what should be done what is expected?
(Refer Slide Time: 37:29)
Now under the top level function there are 2 sub functions that we have seen one is attach
account. So accordingly we have given it a level 4.1 because this is the first sub function and a
name attached account in this the input is details of account or maybe more than one accounts
that we need to synchronize with the app and the output is the synchronized reminders.

A description here can be simpler than top level function in this function the user can attach
email ids to the app for synchronization. This can be simple description of the purpose of the
function.
(Refer Slide Time: 38:25)
Then comes the other sub function that is remove account so the label given is 4.2 indicating that
it is the second sub function for the fourth top level function and the name is remove account. So
the input is details of accounts to be removed or unsynchronized and output is unsynchronized
reminder list. That means now the display should not contain events that is linked to the account
which is unsynchronized and the purpose again can be simply stated as in this function.

The user can remove synchronized accounts from the app so that events attached to that account
does not reflect on the display.
(Refer Slide Time: 39:25)

So then how the complete hierarchy looks like let us have a look so we have top level function as
calendar app that is the entire top level function. Under this we have one top level function
display calendar under which we have three sub functions display months, display days with
events and display date view specific date. Then we have set reminders as another top level
function under, which there are sub functions create reminder, edit reminder, delete reminder.

Third top level function is set background so under this top level function there are 2 sub
functions set theme and reset theme. And finally this fourth top level; function synchronize under
which we have attach account and remove account. So effectively what we can think of as the
SRS should contain R1 then R1.1, R1.2, R1.3, then R2, R2.1, R2.2, R2.3, then R3, R3.1, R3.2
and finally R4. Under which R4.1 and 2 now for each of these of course we have to specify like
R1 or R1.1 we have to specify the input output and description.
So once that is done this entire thing will constitute the SRS for the calendar app which will
specify the functional requirements for the SRS to re-emphasize the point. So these are only
considering the functional requirements we have not yet bothered about specifying the usability
requirements that we have discussed in the previous lecture. Now once we put in the textual
forms of the functional requirements that will constitute our whole SRS for the calendar.
(Refer Slide Time: 42:13)

So again here you should keep in mind and note in this lecture how we have represented the
functions in SRS namely kind of name given sort name 1 or 2 words. Then input specification,
output specification and description for functions at each level then the abstract nature of the way
we have identified the functions. So essentially our focus is what we need rather than how to
achieve the requirement how to do it?

So our objective is only to specify functions which we need rather than how to get what we need
or the algorithm for the functions so that is not required at this stage. And then hierarchical
organization of the functions so how the functions are organized in the form of a hierarchy? And
also the conventions that we used for naming the functions that we already mentioned earlier
labeling convention, names and naming convention.

So as I said we have not discussed anything about usability requirements in this particular lecture
here we concentrated more on how to specify the functional requirements? First of all how to
identify and how to specify? In the next lecture what we are going to do is to see how the
usability requirements that we have discussed in the previous lecture can be incorporated as part
of the SRS. So that we can implement it as functions and at the same time ensure that the system
is usable.
(Refer Slide Time: 44:16)

How to do that we will see in the next lecture. So with that we come to the end of this lecture
here we continued our discussion on the case study and we discussed specification of functional
requirements for the calendar app. In the next lecture we are going to expand the SRS document
by incorporating usability requirements as well. And how to do that because usability; is a
non-functional requirement how we can convert it to functional requirement.

And apart from such conversions is there any other way to make use of usability requirements?
Because usability requirements, is not necessarily convertible to functional requirements. So;
how to make use of the usability requirements? That we have identified through contextual
inquiry that also we are going to discuss along with how and if we can convert it to functional
requirements. That is all for this lecture thank you hope you have learned and looking forward to
meet you in the next lecture soon thank you and goodbye.
 Design & Implementation of Human - Computer Interfaces
Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute Technology - Guwahati

Module No # 03
Lecture No # 11
Case Study-Non-Functional Requirements of SRS

Hello and welcome to the NPTEL MOOCs course on design and implementation of human
computer interfaces lecture number 10. Here we are going to continue with our previous case
study on calendar application development. Before we begin we will again go through the basic
idea of the interactive system development life cycle for easier recollection and then we will
continue with the example.
(Refer Slide Time: 01:28)

So we are currently focusing on a particular stage of the overall interactive system development
life cycle which comprises many stages. What are those stages? Just to have a quick recap we
have the feasibility study stage, requirement gathering analysis and specification stage, design
stage, prototyping stage, early evaluation of the prototype stage, coding and implementation
stage, code testing stage, empirical study stage and finally deployment and maintenance stage.

So all together we have 9 stages that make this interactive system development life cycle. Now
as you can see among these stages some stages form cycles, which means they are generally
performed in a loop iteratively at many places we can find such iterations. For example in the
design prototype and evaluation stages create a cycle as shown here in this block. That means
that when we go for design then this design has is prototyped and quickly evaluated to find out
problems with the design and this process goes on iteratively Till we arrive at a design that no
longer has many issues.

Now, when we say it does not have many issues we essentially refer to the fact that the design is
now likely to be leading to a usable product another important thing that we should again keep in
mind is that when we are talking of the term design. We are actually referring to 2 types of
designs one is the design of the interface and interaction that is from the user’s point of view.
Another one is the design of the system which is from the systems point of view.

Now when we talk of the design prototyping evaluation cycle essentially, we are referring to the
design of the interfaces and interactions. In the case of the design of the system we may not
require prototyping and quick evaluation, however, there are other ways to evaluate system
designs quickly which are covered under the code testing stage. Similarly, there is another bigger
cycle that we can see from this design prototype.

Evaluate cycle to empirical study and back so this bigger cycle is likely to be infrequent.
Otherwise, it will lead to huge costs and resource requirements. So only once or twice may
happen there is even a smaller cycle between the design and requirement gathering. So if the
design is found to be having too many problems then we may like to have the requirement
gathering to refine the design so this smaller cycle may also be there.

Among these stages we are currently discussing the requirement gathering analysis and
specification stage so we have already covered the basic concepts and currently, we are focusing
on understanding these concepts in terms of one case study one example is system development,
which is a calendar application.
(Refer Slide Time: 05:30)
So in the requirement gathering stage, we learned what is the key requirement from the point of
view of an interactive system? So what we have learned is that the key requirement from the
point of view of an interactive system is the usability of the system now usability requirement is
applicable for interface and interaction design. It is not necessarily a requirement for system
design, so currently we are focusing on the interface and interaction design for which usability is
a key requirement.

Also, we have learned about how to find out functional requirements and specify it note here that
usability requirement comes under the non-functional requirement. Now there are other ways to
specify requirements these are functional requirements that can directly translate to features of a
system. So we have seen what are usability requirements? And we have also discussed how to
find them out through contextual inquiry?

In the case study, we have seen how to find out through contextual inquiry usability requirements
for the calendar application. Separately in another lecture, we have seen how to find out the
functional requirements for the calendar application? Now in this lecture, we are going to see
how these 2 requirements can be combined and a common specification of requirements can be
generated in other words.

Here we are going to talk about how to make use of the usability requirements? That we have
identified through the contextual inquiry method to generate functional requirements that can be
integrated into the software requirement specification document, which primarily consists of a
functional requirement specification.
(Refer Slide Time: 07:43)

So we will continue with the calendar application that we were covering in the earlier lectures to
recap so we are interested to build a calendar application. Now the application is meant for
students, primarily students enrolled in colleges and universities for higher studies, and the
application is meant to help them in their academic activities. So the user group, as well as the
user context, are specified with these statements.

Now earlier we have seen how to find out usability requirements for the calendar app from the
contextual inquiry which is one of the many methods available to identify usability requirements.
(Refer Slide Time: 08:34)
So we assumed that we performed a contextual inquiry to identify the usability requirements.
(Refer Slide Time: 08:41)

Just for a quick recap what is contextual inquiry? So it comprises it is a process that comprises 5
stages it starts with a planning stage where we plan for the overall inquiry process. Preferably in
the form of a script then initiate stage where we start the process by communicating with the
potential users from whom we will collect data as well as their higher authorities in the work
setting if any such authorities exist.

In the third stage now we go for actual data collection which means we observe the users and
take note of their behaviour, while they perform their tasks in the work setting. If you may
recollect contextual inquiry is primarily an observation of user behaviour in a work setting in
their natural work setting. And occasionally this observation can be augmented with
semi-structured interviews for clarification on certain observations.

So the third stage is the actual observation and data collection stage. In the fourth stage, we close
the observation process by sending preferably thank you notes to the participants and creating a
rapport, so that in the future their services can again be availed if such need arises. In the fifth
and final stage we go for analysis of the observed data. There are many analysis methods and we
specifically learned about one particular method namely the affinity diagram method.
(Refer Slide Time: 10:42)

Now in the affinity diagram method again there are 5 stages and through those stages, we can
analyze the data.
(Refer Slide Time: 10:52)
So what are those 5 steps or stages, first is generate idea from observation then display the ideas
on some place it may be a wall, may be some screen, it may be whiteboard anywhere. Now the
ideas can be displayed in the form 5 of sticky notes and then we need to perform brainstorming
in a team to sort those ideas into groups of similar ideas. In the fourth stage we have to assign
some group header to each group of similar ideas and finally we need to draw the finish diagram.

So these are the 5 steps or stages through which we can analyze the data that we have collected
during observations in a contextual inquiry process. Now as, we have mentioned in the earlier
lecture, where we discussed contextual inquiry for the case study.
(Refer Slide Time: 12:07)
We mentioned that we performed CI hypothetically with some students, where we assumed that
the students used a paper-based calendar, a computer-based calendar. Here by the term computer.
So, in the desktops Computers are referred to as calendars that are available on mobile phones
and they use the calendars only for academic activities.

So we ensured that the work setting remains the same and while they are using these calendars in
those methods so you observed their behaviour and noted down, whatever notes we needed to
take to record their behaviour. And to note down, we use sticky notes and then we performed
affinity diagram method to analyze the data where we created the affinity diagram from the
observations.
(Refer Slide Time: 13:18)
So we discussed in detail the final diagram and how we arrived at that diagram what
observations we made how we grouped them together and how we got to know the final
diagram? So we will skip those steps here and only reproduce the final affinity diagram that we
obtained after performing the method. So we managed to get a few groups one group contains 2
observations one is the calendars were found to be used by all the users to set reminders, and 3
out of 5 users were found to use mobile apps to check days and dates and set reminders for
assignment submission.

So these 2 observations that we have noted down were found to be related and we put them
together in a group with a group heading reminder setting. Similarly, we have made another
group of observations 2 observations where there 4 out of 5 users used the calendar systems.
Either physical or mobile or desktop based to check upcoming deadlines and again 4 out of 5
users use the calendars to check meeting dates.

So these 2 again are related and we put them together under a group with a group heading overall
scheduling. We have also created a third group of observations having 3 observations one is 4 out
of 5 users were found to use the calendars to check dates and then check the timetable for that
particular date. All were found to use the calendars to check lecture schedules on a particular day
and 3 out of 5 were found to use the calendar to check the meeting schedule on a particular day.
So in all the cases as you can see a particular day is a common link so accordingly, we group
them together these 3 observations and provided a group heading for day-wise scheduling. So at
the end of the affinity diagram method, we found 3 groups of observations with 3 headings
reminder setting, overall scheduling and device scheduling. So this is the output of the contextual
inquiry that we have performed for the calendar application development.
(Refer Slide Time: 16:22)

Now the question is what to do with this output? So we made some observations and created an
affinity diagram now how we are going to use this affinity diagram that is going to be useful for
the development of the system.
(Refer Slide Time: 16:43)
We can actually make use of these observations or rather we can actually make use of this output
of the process in either of the 2 ways. One is either we can come up with a set of design
guidelines or recommendations or principles to guide the overall design of the interface. So this
is one method one way of using the output the other way of using the output is to create
functional requirements.

So one is to create guidelines for design other one is to create functional requirements for system
development. Now when we say design guidelines we specifically refer to the design of the
interface rather than the system. So given the output that we have just seen for the calendar app
what kind of guidelines we can generate?
(Refer Slide Time: 17:50)

In fact we can frame more than one guideline from the output that we got at the end of the
process.
(Refer Slide Time: 18:00)
Let us concentrate on the first group of observation that is overall scheduling. Here we have seen
that 4 out of 5 users were found to have used the calendars to check upcoming deadlines as well
as meeting dates. From these observations we can make some guidelines one guideline can be
the app resultant app should support viewing of upcoming deadlines for assignment submission
for the current day and also for next 7 days this may be one guideline.

That is the app should have some support for a specific functionality which we can frame based
on the observation. Similarly based on the other observation we can frame another guideline that
is the app should support viewing of scheduled meetings for the current date. So in the group
there are 2 observations each observation can give us some idea about a particular guideline that
is going to be helpful in coming up with a product, that is likely to be usable.
(Refer Slide Time: 19:32)
Let us see the other group of observations the day-wise scheduling under this group there are 3
observations. Observation one 4 out of 5 users were found to use the calendar to check the date
and timetable for that date. Second observation all users were found to use the calendar to check
lecture schedule on a particular day. And the third observation is 3 out of 5 users were found to
have used the calendar to check meeting schedule on a particular day. So we have made 3
observations.

So let us see how from these observations we can again frame some guidelines? One guideline
which we can call guideline 3 can be the final product that should support viewing of the
timetable on any given day. Again this indicates what functionality the final product should have
rather than how to have that functionality. Similarly, another observation can lead us to frame
another guideline that is guideline number 4.

That is the calendar app or the product should support viewing of lecture schedules on any given
day. Again this comes directly from the observations that the users are likely to use these
functions quite frequently in their work setting which in turn is going to make the product usable.
(Refer Slide Time: 21:25)
So that is one way of making use of the output of the contextual inquiry process. That is the
framing of guidelines as we have seen we have framed 4 guidelines. These 4 guidelines can be
used to add functionalities to the final product or the calendar app which are likely to be used
frequently by the specified group of users that is the students in the specified work context that is
the academic settings.

And that in turn is likely to lead to more efficiency effectiveness and satisfaction of the end
product as per the standard definition of usability. Now there is as we have mentioned another
way of making use of the findings that is the addition of new functional requirements based on
the observations. So earlier we have seen that how to create the functional requirements that is
primarily by interviewing the clients or customers.

And based on that we can create a functional requirement and specify it using a specific notation.
The usability study also can lead us to identification of new functional requirements that we can
add to the other functions in the functional requirement hierarchy.
(Refer Slide Time: 23:11)
So in this case let us see what new functions we can add before that let us just quickly recap what
functional requirement hierarchy we have created for the calendar app? So there were 4 top-level
functions display calendar, set a reminder, set background, and synchronize. Under display
calendar we had display months display days, and specific date view under set reminders. We
have created reminders edit reminders and deleted reminders.

Under set background, we have set theme to reset theme and under synchronize, we have
attached the account remove account. So these are the functions that we have identified and the
hierarchy we have created along with the specification of the hierarchy.
(Refer Slide Time: 24:05)
Now based on the affinity diagram we can actually find out newer functions and add it to the
existing hierarchy. Let us see how we can do that? So based on the observations we can add a
top-level function view since it is a top-level function and the fifth function in the hierarchy, so
we are giving it a label R5. Now its input is any date and output is a specific view for that
particular date. Now the view map, the view may be related to the timetable view submission
deadlines view, or meeting list view.

And as we learned earlier so for this top-level function we need to add some description.
Although it is optional it is always preferable to add a description so in this case what we can do
is we can add a simple description like in this function, The user can check day wise time tables
of lectures or upcoming assignment submission deadlines or scheduled meeting lists that is the
overall purpose of this view function which is a top-level function. Now under view we can have
sub-functions depending on the purpose.
(Refer Slide Time: 25:33)

So one sub-function can be timetable viewed accordingly we have given it a level R5.1. Now its
input is the date and the output is the timetable for the day it can have a simple description like in
this function, the user can check the day-wise timetable of the lectures.
(Refer Slide Time: 26:03)
Similarly, we can have another sub-function deadline view the name is deadline view label is 5.2
because it is the second sub-function under the top level function view which itself is having a
level 5 because it is the fifth function in the hierarchy. Now again its input is date and output is
submission deadlines the description is quite straight forward. In this function the user can check
day-wise assignment submission deadlines that are the purpose of the sub-function.
(Refer Slide Time: 26:45)

There can be a third sub-function as well under the function view which is meeting schedule.
Accordingly, the level is 5.3 input is debt output is list of meetings scheduled on that day and
description again can be very simple in this function. The user can check the device meeting
schedule so what we have done? From the observations we identified is that this scheduling is
important and for that, the user needs to get the information to provide the information we can
add certain functional requirements to the functional hierarchy.

Now through these requirements, we are indicating to the design team that these are to be
provided as functions of the final product or as features of the final product which will be very
much beneficial to the end users and will lead to improved usability of the product. So we have
seen one addition of functional requirement top level addition that is a view along with its
input-output and description under view we have added 3 sub-functions for 3 activities. One is
viewing the deadlines meeting schedules and lecture schedules.
(Refer Slide Time: 28:22)

So now we can add it to the hierarchy. So we have already added these 4 top level functions
display calendar, set reminder set background and synchronize. Now a fifth top level function
along with its hierarchy we can add this is the views this is the fifth top-level function.
Accordingly, we have given it a level R 5 and then under it, we have time table view, deadline
view and meeting schedule view.

So accordingly these are labelled as 5.1, 2 to so here you can see how we made use of the
outcome of the contextual inquiry process which is in the form of an affinity diagram. To identify
and add a new hierarchy of functional requirements in the existing hierarchy, that is the second
way of using the outcome of the contextual inquiry process. The other way just to recollect is to
frame design guidelines for use in a later design stage.

Now here, of course, we have shown one example, only depending on the other observations also
we can add few more functions in the form of hierarchy and further, enhance the functional
hierarchy that we have just seen.
(Refer Slide Time: 30:19)

However will not provide any more details on those functions as well as the hierarchy and I
leave it for you as a take home exercise. So I would like to request all of you to go through the
observations and add more functions in the hierarchy to make it complete. So that is all for today
so what we have learned here is? We have gone through the final part of the case study to learn
about how to make use of the outcome of a contextual inquiry method.

To enhance the software requirement, specification documents by identifying and adding more
functions in the functional hierarchy. Now one thing you must keep in mind is that usability
requirements are generally called non-functional requirements. So it is not mandatory to be able
to convert such requirements into functional requirements however in many of the cases you will
find that that is possible for certain usability requirements.

And accordingly you should try to convert those usability requirements into functions. So that in
a later stage we find it easier to implement the overall system with improved usability but I
would like to re-emphasize the point that usability requirements are non-functional requirements,
so it is not mandatory to be able to convert those requirements into functional requirements. So
in a design situation if you find that you manage to find out some usability requirements but
unable to convert them to functional requirements you need not worry that is anyway part of the
overall specification process.

So for non-functional requirements we specify them separately then functional requirements for
which we follow a certain convention which we have discussed throughout the previous lectures.
So what matters most is? At the end you get a software requirement specification document
which includes both non-functional requirement as well as functional requirements. So if you are
unable to convert usability requirements into functional requirements then you can keep that
requirement as non-functional requirement in the SRS document, and have the functional
requirements specified as per the convention that we have seen.

With that I would like to end this lecture I hope you could understand the material and you will
be able to translate it into practice I also hope that you enjoyed the learning and I look forward to
see you all again in the next lecture that is all for this lecture thank you and goodbye.
 Design & Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Module No # 03
Lecture No # 12
Introduction to Interface Design

Hello and welcome to NPTEL MOOCS course on design and implementation of human
computer interfaces lecture number 11. In this lecture we are going to talk about the next stage in
the interactive system development life cycle namely the design stage. Before we begin we will
quickly recollect the life cycle stages that we are currently discussing.
(Refer Slide Time: 01:14)

So we have seen earlier one of the stages that is the requirement gathering analysis specification
stage. Apart from this stage there are many more stages which together constitute the interactive
system development life cycle. So we have feasibility study stage, then requirement gathering
stage, design stage, prototyping stage early evaluation of the prototype that is another stage.
Then coding and implementation stage, code testing stage, empirical study stage and finally
deployment and maintenance.

Now among these stages the relationships vary for example in the 3 stages design prototype and
early evaluation they are connected in the form of a cycle. So we first design then create a
prototype then evaluate the prototype based on the evaluation results we refine the design create
again another prototype based on the refined design again evaluate and this goes on in a cycle.
So this cycle we are calling as design prototype evaluate cycle.

The cycle stops when the design stabilizes that means no further problems are found in the
design after the evaluation of the prototypes. Now this design prototype evaluate cycle primarily
refers to the design of user interfaces apart from that the design stage also refers to the design of
the code or the program which implements the design. So both designs are referred to by this
design stage and in code testing we test the code for its ability to execute properly along
expected lines.

Whereas in empirical study we test usability of the end product by involving end users in the
evaluation of the whole product or software. So these are the stages and through these stages we
try to build one interactive system that is executable as well as usable. Among them we have
already discussed one stage that is the requirement gathering analysis and specification stage.
(Refer Slide Time: 04:04)

So in this stage what we have learned? We have about the idea of usability what is meant by the
term usability requirements? Also what are the other requirements from the point of view of the
system development? So the usability requirements are non-functional requirements and we have
also learnt functional requirements and learned how to create functional requirements from
usability requirements through one case study?
More specifically what we have learned are usability requirement gathering and one method. So
there are several methods for gathering usability requirements we have learned one particular
method that is contextual inquiry. Then we have learned the affinity diagram method which
works on the data collected through contextual inquiry to analyze the results of the gathering
exercise. So we learnt affinity diagram method for analysis of the requirements that we have
gathered during contextual inquiry.

Thirdly we have learned how to specify the requirements so we have learned about SRS or
software requirement specification document how to create it what are the conventions to be
used and so on which is required for specification of the requirements. So we covered the
requirement gathering analysis and specification stage by separately learning what you mean by
gathering what you mean by analysis and what we mean by specification?

Whatever we have learned in this stage we try to explain that in terms of one case study of an
application namely a calendar application. Primarily to be used by the student community who
are enrolled for higher studies in higher educational institutes including colleges and universities
and who are supposed to use it for academic purposes.
(Refer Slide Time: 06:30)

In this lecture we are going to talk about the next stage that is the design stage which is one of
the components in the design prototype evaluates cycle.
(Refer Slide Time: 06:42)

To recollect so we have covered this stage and now we are going to talk about the design stage
subsequently we will talk about the other stages namely prototype and early evaluation and how
the cycle is formed. So in this lecture we will get a general introduction to the idea of design in a
software development life cycle. So what we mean by design and what we should know and take
care of in the design process? So when we talk of design what are the primary concerns?
(Refer Slide Time: 07:21)

There are 2 major issues or broadly 2 issues that we should be aware of and we should try to
address in our design activities. What are those issues? The first most obvious issue is where to
start the process? Where to start so; essentially when we are asked to come up with a design we
should be very sure or we should be knowledgeable about the starting point.

Where to start the process otherwise it may lead us to nowhere and we may end up with a faulty
or incomplete design. The second major issue is once we have designed something the concern is
how to specify it how to represent it? So that later on in later stages when we go for
implementing the design or go for doing something else on the design we can communicate the
idea of design clearly to the other members of a development team.

So the second major issue is how to represent our design in other words which language to use to
represent the design. So there are these 2 major issues that we should be concerned about when
we are going to work on design. First one is where to start and second is how to represent both
are very important considering that the entire life cycle is a team effort. So; one output of one
stage should be passed on to the input of another stage which may be executed by a separate
group, separate person or separate members of the team.

So this input that the team gets which is the output of some previous stage should be clearly
understandable. So that the new member can start working on the idea without any problem
without requiring to, consult the member of the team which executed the previous stage that is
very important. And from that point of view we should keep in mind that communicating ideas
from one stage to another in a very clear and precise manner is very much important and part of
this overall exercise. So we should always be concerned about that issue how to represent and
where to start.
(Refer Slide Time: 10:07)
Let us now start with the first issue that is where to start where we should start the design
activity? Obviously when the term design is mentioned it implies that we have the freedom to
think in our own way. In other words we should have the freedom for creative thinking. So as a
designer we should be able to creatively think and come up with a design now that is one way of
looking at the issue.

Now creative thinking need not work in a vacuum so when we say we are trying to come up with
a design through creative thinking. Implicitly we may be relying on our intuition or our past
experience both may be aiding in our thinking process. So effectively when we are trying to
think in a creative manner we may be aided by the intuition which we may have and our past
experience or knowledge of the domain of the problem that actually influences our creative
thinking.
(Refer Slide Time: 11:26)
Now; that is a broad way of looking at things now let us come to a bit more specific issues. So
when we talk of UCD or user center design now here the design is not a single idea here design
actually encompasses 2 distinct concepts. One is interface design that means the user interface
that the user gets to see and interact with. Now interface design also includes design of the
interaction through with this interface.

That means essentially interface plus interaction design that is one aspect of the design and
second is the design of the system or code design. So we have these 2 concerns interface design
which includes interaction with the interface as well now this is primarily from the point of view
of the user. And code design which is primarily point of view of the system so both are important
for getting or for developing an executable and usable product so how to take care of these 2
concerns?

Let us first start with the idea of interface design to recollect when we talk of interface design
essentially what we are referring to? We are referring to the user interface. That means the
system interface through which the user gets to interact with the system. Now the term interface
implicitly contains the idea of interaction as well. So without interaction interface is not of much
use so when we say interface design we are actually referring to both designs of the interface as
well as the corresponding interaction.
So when we are concerned about design of the interface we should be very careful because our
primary concern here is usability and usability primarily depends on the design of the interface
and interaction.
(Refer Slide Time: 13:54)

So these 2 affects the usability of the product because these 2 are the portal through which user
gets to view the system perceive the system and achieve goals with the system. So here the main
concern is to come up with a design that increases usability of the product. Now let us come back
to the core issues of design where to start and how to specify?
(Refer Slide Time: 14:25)
So when we are talking of interface design where to start so we can start with creative thinking
as we have seen before. So this is actually a prime application of creativity. How the interface
should look like? How the interaction can be designed? How the interface elements should be
designed? How they should be placed? Creative thinking can aid us in making all these design
decisions.

And as we have noted earlier so this creativity can be added by experience so the designer may
have experience of designing similar products before. Now that knowledge that experience can
be used can be an influencing factor for coming up with a creative design idea. The creative
thinking can also be aided by our intuition but of course intuition again is a very complex
concept and intuition comes with knowledge with experience with wisdom.

So everything actually influences the way we tend to think we tend to create so the more
experienced we are it will be easier for us to come up with a creative design solution the less
experienced it will be difficult to come up with a creative solution. So there is no ready-made
rule to tell you how to come up with a creative solution it entirely depends on your experience
intuition and creativity.
(Refer Slide Time: 16:21)

However creative thinking is a specialized way of looking at things but there are methods that
are easier to understand and access rather than having exotic skills like creative thinking. What
we can do instead is? We can make use of some guidelines or thumb rules or checklists or
heuristics as starting point of design these can also aid in our creative thinking. So that is
something very important to note that there are guidelines framed to aid designers in better
design better interface design.

Similarly there are checklists created to aid designers ensure improved interface design there are
heuristics which have been developed to help a designer come up with a good design and there
are thumb rules. So; all of these terms actually refer to a set of guidelines or principles using
which we can create quote, unquote good design which is likely to be usable. Now why we say
that when we follow a guideline we can come up with a usable design because of the history of
these guidelines or checklists or heuristics or thumb rules whatever you call it.

These are developed based on a long history of application of such guidelines rules or checklists
on building usable products. So based on the knowledge gain these sets were continuously
revised updated so that at the end whatever they contain is proven to be useful for building
usable systems. Accordingly we can claim that whatever design we come up with based on these
guidelines or heuristics can lead to improved usability enhanced usability.

That is one way of looking at the issue of where to start so we can start either as a creative
thinker, creative designer or we can start with some set of guidelines which will aid us further in
our thinking process.
(Refer Slide Time: 19:21)
Now there are many guidelines which have been developed over time for various purposes.
(Refer Slide Time: 19:29)

Some guidelines are very generic in nature that means they patent to very broad aspects of a
design of a usable design and because they are very generic. So they are usually small in size that
means the number of guidelines is less in value maybe five to ten guidelines that constitute a set
of guidelines for design of a particular system. So these guidelines because they are generic
usually cover broad aspects of interactive systems at a rather high level again there are many
such guidelines.

For example the 8 golden rule are the 7 principles the first one 8 golden rules was proposed by
Ben Shneiderman, way back in 1986 the second one 7 principles was proposed by Donald
Norman in 1988. Now both these sets actually originated during the proliferation of graphical
user interfaces. You may be familiar with this term graphical user interfaces these are the
interfaces that contains windows, icons, menus and pointers or what we generally call wimp
interfaces.

Windows, icon, menus and pointers or wimp interfaces these were ubiquitous interfaces at one
time still they are very much around us. Whenever we interact with a computer desktop
computer in particular or laptop whatever interfaces we get to see are mostly wimp interfaces. So
these interfaces were developed way back in nineteen eighties at that time what we take for
granted nowadays was not so in at that time and the idea of usability was not that much
developed.

At that time these golden rules or principles were developed by the corresponding persons in the
case of golden rules it was Ben Shneiderman and in case of 7 principles it was Donald Norman.
So these were developed to help in building (())(22:21) that are going to be usable. So that was
the background of these guidelines and another thing that we should keep in mind is that these
guidelines did not appear suddenly out of nowhere.

So they were framed based on empirical data collected over a long period of time and after
analysis of that data some behavioral models were formed and out of those models these
guidelines emerged. So they were rooted in behavioral analysis of human users so whatever
guidelines are proposed if we follow them then we are likely to get systems that will help the
users use those systems now these are some generic examples of guidelines.
(Refer Slide Time: 23:30)

There are more detailed guidelines as well which are more specific and accordingly these are
large sets that mean each set of guidelines contains hundreds or maybe even thousands of
individual guidelines. Now these guidelines the detailed ones are intended to cover very minor
aspects of the design and most often they are specifically meant for specific products.
One example can be the human interface guidelines that was developed for the apple systems
this set of guidelines contained hundreds of individual guidelines which are primarily meant to
build products on apple platforms on apple OS. And primarily products that deal with GY’S on
apple platforms.
(Refer Slide Time: 24:36)

In subsequent lectures we are going to learn about the 2 guidelines that I mentioned earlier eight
golden rules of Shneiderman and Norma's 7 principles to get some idea on what we mean by the
guidelines in this case the generic guidelines.
(Refer Slide Time: 24:57)
So that is about where to start now the guidelines help us to start design but design of what. So
here we talked of 2 types of design one is interface design other one is code design. Now the
guidelines are helpful to get us a starting point for interface design the other aspect of the design
stage is the code design for which we need to take different approach so for code design let us
see what we can do?

To repeat when we reach the code design stage once, we complete the design prototype, evaluate
cycle and stabilize the design of the interface. So first we start with interface design we design
something prototype it, test it if some issues are found out then we refine the design again
prototype is test it. So this cycle goes on till we reach a design which is stabilized that means no
further issues are found in the design.

In that case we move to the next aspect of the design stage that is code design so now we move
to design of the system or code. Now code design is totally different than interface design.
(Refer Slide Time: 26:20)

In interface design primary concern was usability and the design guidelines were again based on
users behavioral characteristics and they were primarily meant to help us design usable products.
But those are not useful in code design where our primary focus is efficiency of the
implementation. Along with that our primary focus is to make the code manageable. That means
we come up with a design which other team members can understand and manage if required
modify also so that it can be implemented.
So the objectives changes and accordingly we should change our approach to address the main
concerns.
(Refer Slide Time: 27:11)

Now earlier in the requirement stage we saw that we need to create an SRS or software
requirement specification document as the end product of the stage. Code design actually is
based on the SRS that we create so we need to translate the functional requirement hierarchy to
the design of a system that can be implemented. So when we talk of code design there are 2
distinct phases are involved the first one is the preliminary phase or high level design phase.

And there is another one that is the detailed design phase also called module specification
document. So; any code design activity involves these 2 stages high level design and or
preliminary design and detailed design or module level specification document.
(Refer Slide Time: 28:24)
So in the high level design what we need to do we need to identify the modules? That means the
units which together constitute the overall system. Then define relationships between the
modules control relationships between the modules how the modules are linked to each other.
And also we need to define interfaces between modules how the modules talk to each other so
how they are connected and how they are able to talk to each other?
(Refer Slide Time: 29:12)

So all these things we need to consider in the preliminary design phase or high level design
phase in the detailed design phase. We turn our attention to the design of individual modules
particularly the data structures and algorithms to be used to implement individual modules. So
that is the second phase of the design activity code design activity that is detailed design phase.

So we started with 2 issues broader issues for any design activity one is where to start and how to
represent? Now earlier we saw that in interactive system design there are 2 types of design one is
interface design other one is code design. For interface design starting point can be creative
thinking or it can be use of standard guidelines. Another thing we should note here is that the
second issue that is how to represent the design? In case of interface design the representation is
done with prototypes.

So prototypes effectively give us a language to express the design we will learn more about
prototypes later. In case of code design our starting point is this phases, preliminary design phase
and detailed design phase in preliminary design phase we work with high level concepts namely
what are the modules broader modules? How they are connected? How they talk to each other?
And in detailed design phase our primary concerns are the data structures and algorithms to be
used to implement each module. Now let us shift our attention to what are the languages using
which we can specify our designs.
(Refer Slide Time: 31:12)

Now as briefly mentioned so when you talk of design language; we refer to specification of the
design. Like we have seen specification of requirements using SRS which is a convention in
other words we can call it a language. Similarly we need a language to specify our design and we
require different languages for interface and code design specifications.
(Refer Slide Time: 31:44)

Again as I just mentioned earlier to express interface and interaction design we do not do it using
natural language like English or Hindi or similar languages. Instead what we do is we make use
of prototypes we take records to prototypes. Prototypes are scaled models of the designs when
we create prototype we essentially express the design. So prototype gives us the language to
express our design so we can consider a prototype to be a language for expressing interface
design.

Now in a later lecture we will learn more about what are the different types of prototypes and
how to create those prototypes? Clearly we can see here that prototypes although we; are calling
it a language but they are not a very formal language as such it does not have alphabet or
anything. Rather we are using the term language here in a very loose manner whichever allows
us to express something we are calling it a language. And in that sense prototype can be
considered to be a language to express interface design.
(Refer Slide Time: 33:11)
How we can express the code design whatever we have designed through preliminary and
detailed design phases how we can express that. So what is the language we can use for
expressing system design or code design? We can actually take records to various ways so there
are different ways to specify a system design. Definitely we can make use of natural languages
although it will lead to ambiguity.

We can make use of semi-formal languages and finally we can go for formal languages with
clearly defined syntax and semantics which are mathematically defined. So each has its own pros
and cons if we are making use of natural language to express a system. Now that is very much
subjective. So when I create a description of the system in terms of a natural language I may be
using my literary skill to express it.

But later on when I pass on the message to somebody else when I pass on the design to
somebody else in my team the particular member may not be able to comprehend it or maybe
having lots of confusions because natural languages are inherently ambiguous. So natural
languages although can be technically used but are not suitable or preferable to express design
languages. This leaves us with 2 choices semi-formal languages and formal languages.

Formal languages are the best way to express any design however because it is a very rigorous
expression it requires mathematical background. And good skills in understanding the particular
notations and conventions and also understanding the logical deductions that follow from the
specifications. A middle ground can be found with a semi formal languages based specifications
which are natural language. Partly graphical language and rather informal way of expressing
things and easier to understand but at the same time it reduces ambiguity.
(Refer Slide Time: 35:53)

In this course we will focus more on this semi-formal language based specification of design
particularly system design. So we learn 2 such languages one is DFD or data flow diagram which
is a graphical language to express design in the form of in the form of drawings images. Second
one is also a partly graphical language where we can express design in the form of some
schematic diagrams this is called UML or unified modeling language.

First one is DFD or data flow diagrams as the name suggests it contains diagrams to express
design which makes it easier to understand and makes it easier to maintain as well. Second one is
UML or unified modeling language this is again partly graphical language of course in both the
languages natural language text is also used along with the graphical notations. So these 2
languages we will learn in subsequent part of this course.
(Refer Slide Time: 37:29)
So with that we come to the end of this particular lecture so here we got an overview of what we
mean by design? To recap we are now going to start our discussion on the design phase of the
life cycle now there are 2 types of designs are important one is interface designs other one is
code design. Code design is also referred to as system design so we will use the terms
interchangeably in subsequent lectures.

Now in both the cases what we should be aware of is what we should be concerned about are 2
issues one is where to start the design process and second one is how to specify the design? In
case of interface design starting point typically considered to be creative thinking aspects but we
can also start with the help of some standard guidelines. In case of code design we start at the
preliminary design phase and also complete the design in the detail design phase.

Now the specification languages differ for each type of design in case of interface design we can
consider prototypes to be a language quote, unquote language to specify the design. And in case
of system design we can consider different languages however we will focus on semi-formal
languages to specify the designs. 2 semi-formal languages will learn one is DFD or data flow
diagram and other one is UML or unified modeling languages.

In the next lecture we will start our discussion on the design guidelines these are the guidelines
that are useful to start design of interfaces. That is all for this lecture I hope you managed to learn
the concepts and enjoyed the content looking forward to see you all in the next lecture thank you
and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology, Guwahati

Module No # 03
Lecture No # 13
Schneiderman’s Golden Rules

Hello and welcome to the NPTEL MOOCs course on design and implementation of human
computer interfaces. We are going to start lecture number 12 on design guidelines. Before we
start let us quickly recap what we have learned so far so as the name of the lecture indicates, so
we are going to talk about guidelines for design. Design of what and where in the overall
interactive system development life cycle the design fits.

We have so far learned about the life cycle and the different stages of the life cycle. So, let us just
quickly recollect what are the stages? And where we are currently now?
(Refer Slide Time: 01:34)

So, if you may recollect, we have several stages in the interactive system development life cycle.
We start with the requirement gathering analysis and specification stage. Feasibility study
although it is shown as part of the life cycle actually is a stage where we decide whether to
proceed or not? Or if we proceed then whether; any modification in the plan is required or not so.
As such it is not directly involved in the development of the system.
So, we will treat it separately and in this course, we are not discussing in detail the feasibility
study stage. We started our discussion with requirement gathering analysis and specification,
which we considered the first stage in the interactive system development life cycle. After this,
we enter the design prototype evaluation cycle. Now, this cycle contains 3stages the design stage,
the prototyping stage, and the evaluation of the prototyping stage.

Now here, we mentioned that design involves 2 types of design the design of the interface and
interaction is a key component in any interactive system development and also the design of the
actual system or design of the code. So, when we are talking of the design prototype evaluation
lifecycle, we are primarily referring to the design of the interface and interaction rather than the
code design. For code design, we may not require this cycle.

So, in the interface and interaction design, we come up with a design, then prototype it. Because
we are dealing with user center design approach so, we need to take into account the user inputs
in as many stages as possible. So, to take into account user feedback, we create a prototype of
our design, then get it evaluated. If any issues are found, then we refine our design, recreate the
prototype, and get it evaluated again and this goes on in a cycle which we call the design
prototype to evaluate cycle.

So, once we reach a stable design that means a design, where not many significant or new issues
are found through prototyping and evaluation, then we stop the cycle there and enter the design
of the coding stage. Now, in the design of the code, we plan for the overall software system. So,
to speak and then we go to the next stage. The next stage is coding and implementation. That
means once we have a design of the system ready, we go to implement it by writing programs
that is the coding stage.

After we have implemented it, we need to test it. So, this is the code testing phase which comes
after the implementation stage. Now, in code testing of course there are several levels of testing
and several types of testing, which are related to the testing of the code. Note that in the
evaluation phase we talked about in the design evaluates prototype cycle here, it is related to the
evaluation of the design from the point of view of usability.
Now when we are talking of code testing, we are talking of evaluation of the code from the point
of view of execution ability. In other words, whether; the code can be executed efficiently and as
per the expectations. So, after code testing, we go for another round of usability testing now this
time for the whole system rather than a prototype, which we call empirical study or empirical
research.

Now here, what we do is test the usability of the system with respect to end users and if we find
some problems at this stage which is possible, then we may like to go back to the design stage
and traverse the other stages again. So, this can form another cycle although this should be a
minimal maximum of one or twice, more than that will affect the overall turnaround time as well
as the cost of the project.

So, once we are assured of the usability of the product as well as the execution ability of the
product we go for deployment and subsequently maintenance stage of the life cycle .So, this is
the summary of what we are talking about we have already discussed the requirement gathering
stage and currently we are discussing the design of the interface stage.
(Refer Slide Time: 06:50)

In earlier lectures, we got a general introduction to the problem of design. What are the issues
and how do we address those issues in the design of the interface? Now, there again we talked of
2 design problems here, one is interface and interaction design where usability is a prime concern
and code design or design of the system.
(Refer Slide Time: 07:25)

Now in this lecture, we are going to talk about the design of the interface where to start the
process that is going to be our primary concern in this lecture. In this regard we are going to
learn about design guidelines or guidelines for the design of interfaces and interactions so what
are the things that we should follow while going for a design?
(Refer Slide Time: 07:55)
When we are talking of design, if you may recollect 2 issues are of primary concept. One is
where to start and the second one is how to specify? The same applies to interface design where
we should start our design process? Now, if you are an experienced designer and also you have
sufficient experience in the design of similar systems, then you can rely on your experience
which again is influenced by your intuition and knowledge level, and skills to start the process.

Even if that is the case or if you do not possess such experience, then also we can start by taking
recourse to guidelines. So, guidelines provide a starting point in the design phase of the
development life cycle earlier we talked about several guidelines.
(Refer To Slide Time: 09:08)

So, there are different ways to look at the guidelines broadly there are 2 categories of guidelines.
(Refer Slide Time: 09:14)
Some are very generic in nature and since they are generic, they only refer to broader aspects of
the design, rather than going into the minor details of specific system design. And accordingly,
since they primarily refer to broader aspects of design which is generally true for any system
rather than specific systems. Generally, these are at a very high level and the number of such
guidelines is very less.

So, the overall set of guidelines is small we mentioned a couple of such guidelines such as the 8
golden, rules by Schneiderman proposed in 1986 and principles by Norman proposed in 1988.
(Refer Slide Time: 10:10)
In contrast to these generic guidelines, we can have specific guidelines also where the guidelines
are designed to build a specific type of system. So, the target is very specified and the guidelines
are very minute in nature. So, they deal with intricate details of the overall system design. For
example, human interface guidelines for the apple systems built for apple devices. So generally,
these guidelines are very large in number and the set size is big.

So in this lecture, we are going to talk about one of the 2 generic guidelines, that we have
mentioned earlier namely the 8 golden rules by Schneiderman’s guidelines for the design of
interfaces. In particular, these guidelines are applicable for the design of graphical user
interfaces.
(Refer Slide Time: 10:49)

So, these are called golden rules so there are 8 golden rules as I said, they are originally designed
for graphical user interfaces or GUIs. Now, the golden rules were proposed by Ben
Schneiderman way back in 1986. At that time, the idea of the personal computer was coming
into being and people were trying to develop graphical user interfaces for such computers.

So, it becomes popular and acceptable to the masses in that context, the golden rules were
designed. However, as it belongs to a generic set of guidelines so, they broadly refer to larger and
broader aspects of a design which makes them suitable partly or fully for other types of systems
and interfaces as well. That is the advantage of having a generic guideline set although, it does
not provide us with details of, what to do?
But it provides us, a very broad picture of what should be done, and since it provides a broad
picture. Such guidelines are applicable for systems or interfaces other than the ones for which
those were intended.
(Refer Slide Time: 12:50)

Now let us see what are these 8 guidelines or 8 golden rules. Rule number 1 the first rule first
golden rule says that we should strive for consistency. Now, there are 2 types of consistencies
from the point of view of this particular rule. One is internal consistency. Another one is external
or environmental consistency. So, what this guideline tells us or what this golden rule tells us is
that when we are trying to design an interface, we should strive for both internal as well as
external consistency.

Now, what does it mean? Internal consistency means that whatever symbols metaphors, icons,
texts, or tasks that we are designing for one part of the system should be consistently used in
other parts of the system. For example, suppose we are designing a GUI with multiple windows,
and to close windows, we are using a red circle with a cross inscribed inside it which is a typical
way of denoting the close button.

Now, for one window suppose we are using this red-filled circle with a cross and for another
window, we are using a green-filled circle with a cross. Now, both windows are part of the same
system. But, to close one window, we need to use the red circle with a cross, and to close another
window, we need to use a green circle. So, there is a lack of consistency. If we want to perform
the action of close, we should use consistent symbols or buttons or metaphors or icons to
perform this operation across all the interfaces in the same system.

That is what is referred to as internal consistency same thing should be used everywhere with the
same meaning. What is external consistency? Now, we may use some standards in our design.
However, in our day-to-day life, we get to see something, we experience something so whatever
we are defining for our system it ideally should not violate what we experience in our everyday
situations. If these, are 2 matches, then we have external consistency. If these 2 do not match,
then we do not have external consistency.

For example, we get to see traffic signals having 3 colours red to indicate stop, yellow to indicate
slow down, and green to indicate go ahead. Now, suppose in our interface, we want to indicate
stop or close and window. So ideally, we should use red colour to indicate this operation.
Because stop or close in the context of a traffic light, which we experience in our day-to-day life
is indicated by the red color.

So, in our system, if we are using red color, then we are consistent with our real-life experience.
Now, instead of red, if we use say green to indicate close or stop. Then, of course, that is
violating external consistency. So, you may note that we may maintain internal consistency but,
violate external consistency which is quite possible. However; ideally, for an interface to be
used, it is preferred that we follow both internal and external consistency which was rule one.
(Refer Slide Time: 17:24)
Now, let us talk about rule 2 this rule states that we should design for universal usability. Now,
universal usability is a term, to be noted it indicates that our design should cater to different
groups of users. Now, it should not be confused with the idea that the system that we design
should be used by everybody. Now, that is something that violates the definition of usability as
we have noted earlier.

Instead, what we are saying here is that? We should have a system, but for a specific group of
users, a specific interface should be used. It is not that everybody gets to see everything and gets
to use everything. Now, broadly we can categorize users as we have already seen in 3 groups
novice, intermittent, and expert. So, novice users are those who typically use the system for the
first time.

Intermittent users are those who occasionally use the system maybe in between there may be a
long gap, and expert users are those who use the system regularly, and frequently. Now, for each
category of users, we should have different features in the system. That is what is meant by
design for universal usability. So, our system should be usable for novice users, should be used
for intermittent users, and should be usable for expert users.

How by designing the features and functionalities provided in the system in a way. Such that,
each group is scattered and the corresponding features are only visible to that particular group.
All user groups should not be exposed to all features provided in the system. Then it affects
usability. An example can be the use of a text editor so, all of us have used text editors such as
ms-word or word pad.

Now, in such text editors suppose, I want to create a text and save it. How I can? Save so I can
use either of 2 ways. One is using a menu-based option. So, in the menu there is a file menu
typically under file there is a save option. So, I can select the file and the drop-down menu
appears and then I can select the save option, to save the text. Alternatively, what I can do is I
can use a combination of keys these are typically called hot keys.

For example, Ctrl +S is the most common hotkey combination used to save a file. So, I can either
be using a menu or I can either use the Ctrl +S. Combination of these 2 keys control key and S
key on the keyboard. Now, the menu-based option is typically good for novices and maybe also
intermittent whereas Ctrl +S this hotkey combination may be good for experts. So, the system
that we design should have facilities for both menu-based saving and Ctrl +S or hotkey-based
saving, and the user depending on the category can use the specific option to perform the task.
Then the interface will be usable to all the groups.
(Refer Slide Time: 21:10)

Now let us come to rule number 3 it talks about the fact that when we are designing something,
we should offer informative feedback to users, whenever a user performs, some activities with
the interface. An example is a progress bar. So, whenever the user performs some tasks and the
progress of the task is shown in the form of a progress bar, then the user gets to understand how
much of the task is done and how much is remaining?

This gives the user some sort of information about the completion time. Similarly, whether a task
has been completed successfully or not can also be indicated to the user by some informative
feedback. For example, a change in color on a menu option, so typically we use save menu
option to save some editing task. And this menu option is accompanied by a metaphor of floppy
disk, which is used to indicate storage device.

Now, before saving it comes with a color and after saving the color of the disk may change, it
becomes grays which indicate that save option is done and then based on that change in color
user may get to know, whether the save option is successfully done or not. If the color does not
change, that means save is not done. So, we have to save again. Otherwise, if the color is
changed that means the file is already saved. No need to do anything else. So, these are instances
of informative feedback that should be provided to the user ideally.
(Refer Slide Time: 23:03)

Rule 4 tells us, to design dialogues to yield closure of some operations. So, if the user again is
performing some operation, then apart from providing feedback there should be some sort of
dialogue between user and system, to take the user towards the closure of the operation to guide
the user. So in order to do that ideally, we should try to organize any activity into one of the 3
groups beginning part, middle part and end part.
So, activities can be grouped into beginning activities, the middle part of the activities, and
lending activities. Ideally, some feedback at the end of each group should be provided to indicate
that a particular part of the activity is over. For example, when we are trying to purchase
something online which; is a big complex task through some interface. Then, beginning of the
purchase task actual purchase, and ending or checking out of the website, we can divide all the
activities into these 3 categories.

And after each category, we should try to provide some hints to the user in the form of dialogues,
to enable the user to understand the current stage where he or she is. This actually the dialogues
complement the informative feedback.
(Refer Slide Time: 24:53)

Then comes the fifth rule fifth golden rule of Schneiderman which says that ideally, designers
should offer error prevention and simple error handling mechanisms in the design. So, any
designer should strive for preventing errors by the users, and if prevention is not possible, which
typically is the case then, how to come out of the erroneous situation that mechanism should be
provided. The objective should be to keep error rates low and there should be some error
handling mechanism.

For example, when we are performing some activity through some window the close and start
options should not be kept closer to each other. In that case, erroneously user may select close
instead of start or start instead of close which will increase the error rate. That is a very typical
example of how to keep error rates low. Also, once some error is made error happened then,
complicated error messages should not be shown to the users ideally.

So, the error messages should be in the understandable form in natural languages with as few
technical terms as possible that should be the objective of any design of interfaces. So, rule 5
deals with, how to deal with errors.
(Refer Slide Time: 26:34)

Rule 6 in continuation of rule 5, tells us to allow users to perform a reversal of actions. So,
suppose we have made some mistakes or some errors happened, we want to get out of this. Now,
get out and go where typically we should be able to reach a state where we are safe where things
were not as bad as it is in the current state. So, that is called reversal of action. So, whatever
actions we have done landed us into this current state, we want to reverse those actions.

We want to go back to an earlier state where such errors were not there. Rule 6 tells us that, our
design should support such reversal of actions, and nowadays these are taken for granted in any
GUIs or other interfaces you have heard of these terms undo operation and redo operation.
These; actually allows us to reverse immediate actions that these; operations allow us to reverse
actions that happened immediately before the last action.
(Refer Slide Time: 27:57)
The seventh rule is number 7 it tells us that designers should strive to keep users in control or
designers should strive to let the users feel that they are in control. So, this is very important that
the users should feel that they are in control of whatever operations are being done on the
interface. To get this feeling what is needed is that? The user should be able to perceive their
interactions and change in the system state.

For example, suppose the user wants to move a file from one folder to another folder through
command line if a move command is given then the system does the move operation. But the
user does not know whether or does not feel whether the actual file has been moved or not.
Instead, if the user can quote unquote, select a file representing it as a metaphor and drag it to a
folder metaphor representing the storage and then release the selected file inside that folder quote
unquote folder.

In other words, if the user is allowed toper form drag and drop operations to achieve the file
movement task in the system. Then the user actually feels that he is able to quote-unquote see
what is happening, he is able to select the file he wants, he is able to move it to the location he
wants, and he is able to place it in the location he wants this gives the user a feeling of being in
control of the system.

So, this type of visualization of the operations helps the user, feel in control and that should be
the aim of any designer of interfaces.
(Refer Slide Time: 30:23)

Finally comes, the last rule which is rule number 8. Now, this is a little different than the earlier
rules. What it says is that the designer should try to reduce the short-term memory load of the
user. Now, here it is assumed that a human being possesses 2 types of memory long-term
memory and short-term memory. Of course, this is a very simplistic way of looking at our minds.
But, from a practical point of view, it helps a lot.

So, when some interaction takes place, it is assumed that the knowledge relevant to that
interaction is loaded into the short-term memory and from there we make use of that knowledge
and perform the interaction. Now, if the interaction requires too much knowledge, then it creates
a problem. Because short-term memory is supposed to have a limited capacity it cannot contain
an infinite amount of knowledge.

So, within the limited capacity if the knowledge is restricted then interaction takes place
smoothly and usability improves. However, if the knowledge required to interact is more than the
capacity, then it affects usability and the interaction tends to be not so smooth. So, there is one
theory by George miller, which was proposed way back in 1956 says that it is known as the 7
plus minus 2 rule which says that our short-term memory can at a time hold between 5 to 9
pieces of information.
Now, these pieces of information of course are not clearly defined. But we can assume them to
be units of information that our short-term memory can hold between 5 to 9 units and it varies
from person to person. So, average number of pieces of information that can be stored in 7 varies
from 5 to 9 from 1% to another. So, what this 7 plus minus 2 rule, tells us is that a design should
not force users to remember too many things.

Suppose, somebody can hold seven units of information, then if a design requires the user to
make use of more than seven units of information then of course that interaction is likely to fail.
Because the short-term memory; capacity is exceeded and the user will not be able to bring in
that knowledge to operate the interface. So, we should be very careful while designing our
interface. We should not force the user to remember too many things which in turn is going to
affect the interaction.

So, these are the 8 golden rules proposed by Schneiderman and while going for any interface
design, we should take these rules as a starting point. Whatever our intuition tells us about the
design we should test it with respect to these rules and see whether these rules are violated if they
are violated, then we should refine our design and come up with a modified design. So, that is
how we should proceed.
(Refer Slide Time: 34:12)

Now, let us try to understand the importance of these rules in the context of a system design let
us try to understand it with respect to a case study. So, what is the case, the case here is a web
page for railway ticket reservation, to be used by a traveler. So, the traveler wants to book tickets
online through the web page and here of course we are assuming that the traveler is a
non-technology expert or in other words layman user of the interface. So, the interactive system
principles apply and accordingly usability concerns are very relevant in this case.
(Refer Slide Time: 35:07)

Now given this problem, we need a web page that allows a traveler to book tickets for traveling
by train. Suppose somebody proposed a design of an interface for railway passenger reservation
inquiry. It contains several option there is this top-level menu containing several options then this
middle part has several sets of menus, left side, central side and there is some other web real
estate used for some other purpose.

At the bottom there are some options again there is another menu at the very bottom of the
interface. So, each of these options is essentially hyperlinks after clicking we get to see a
different page.
(Refer Slide Time: 36:17)
So, whether it serves our purpose it can serve definitely. But what are the problems are there any
problems with this interface? Let us try to understand with respect to the task that is booking of a
ticket by a traveler. So, let us first try to analyze the task from the point of view of a traveler who
is the user of this interface.
(Refer slide Time: 36:47)

Now, the ticket booking task actually involves a series of sub-tasks. So, it is not a single task it
can be broken down into sub-tasks. In sequence what is the sequence?
(Refer Slide Time: 37:04)
The first user enters the source, station details, and destination station details. To know about all
the trains that is running between the stations. That is the very first information that somebody
needs to know before he or she proceeds to book tickets. Not only the trend names along with
their timings ticket fare and availability of seat all this information is required before someone
proceeds for booking of tickets.

So, the first task is to get that information in the second subtask, based on the train information
the user selects one train. So now, the second subtask is a selection of the train along with a
selection of seats. And finally, some payment is made to book the tickets so payment is made
online to book the ticket because everything is being done online. So broadly there are these 3
sub tasks one is first to get train information then select a train with seats and finally make
payment.
(Refer Slide Time: 38:35)
If we see carefully, we will see that each of these sub tasks can further be broken down into sub
tasks and usability concerns for each of these series of sub-tasks are there. For simplicity, let us
consider only the first sub-task that is providing the source and destination information. How do
we provide the information to get the train details using the interface? So, with that interface how
can a user provide such information? Let us see let us have a closer look at the interface to find
out how a user can do that.
(Refer To Slide Time: 39:23)

So, this is the interface again, now in the interface, there is a hyperlink as marked here. The
hyperlink says that trains between important stations. So, this is all the menu options or
hyperlinks that relate to something providing station details. All other options if you check have
no apparent indication that through those links, we can provide station details. For example,
there are other hyperlink trends at a glance.

But, as the name suggests it provides information about all trends running everywhere in the
geographic location, rather than allowing us to provide some station names to get specific trend
details.
(Refer Slide Time: 40:21)

Now, the textual description says trends between important stations. This option seems to be the
closest to what the user wants to achieve. So, in order to use this hyperlink, what the user needs
to do?
(Refer Slide Time: 40:40)
As the name suggests the hyperlink only allows users to search for trends between important
pairs of stations. Now, it may so happen that the station pair that the user is interested in does not
quote-unquote important. In that case, of course, there is no way out. So, if a traveler is traveling
or willing to travel from one unimportant station to another unimportant station then this
particular option is of no use.
(Refer Slide Time: 41:14)

In fact, such users are likely to constitute a significant population of the overall user population.
Because the number of important; stations is generally much less compared to the total number
of stations in a railway network.
(Refer Slide Time: 41:38)

Now, then appeared with a cursory look at the interface it may appear that for such users there is
no option. But, that is not true the designers also have probably thought of this issue and
provided a way out for such users. So, there is another hyperlink available that can allow such
user’s to perform the task. So, on the interface, it is very difficult to find out that hyperlink.
(Refer Slide Time: 42:11)

Let us see the interface again. If we give a cursory loop can we get it now one thing we should
keep in mind is that, if an interface is provided and it takes the user a lot of time to browse
through lots of options and find out the one he or she is looking for then definitely that is not a
good interface? Because it violates certain guidelines that we will see later here you can see there
are lots of options. In the top-level menu, there are lots of options, in the middle-level menu,
there is an even larger number of options than there are these things and the bottom-level menus.
(Refer Slide Time: 43:11)

So among these options, it is really difficult to spot such a hyperlink, which allows users to
provide details of any stations not only important stations where they can be. In fact, it is there,
at the very bottom of the screen it says train between stations as highlighted here in this image.
Now, see a cursory glance at the design tells us that the placement of this particular option
actually deprives a significant segment of the user population of easily finding out the option.

Maybe after some usage, it may become easier but for a novice user, it really creates some
problems. So, then if it is not very useful to an office user then that violates a guideline that is it
affects universal usability. Let us see what else we can find out.
(Refer To Slide Time: 44:07)
Once users select this hyperlink since it is a hyperlink, a new interface appears. Now, in this new
interface, there are 2 text entry fields.
(Refer Slide Time: 44:21)

The interface looks something like this where these are the 2 text entry fields and here each field
is meant to provide information about one station. So, the fast field is for the source station and
the second field is for the destination station. But here it is not asking for names instead it is
asking for codes of a station.
(Refer Slide Time: 44:50)
Now, the code and name are different. So, the name may be very easy to remember. However,
codes need not be easy to remember and codes are a typically shorter form of the name if you are
using station code names you may be aware of which is not very easy to remember.
(Refer Slide Time: 45:17)

Then what can be done? So, for those who cannot use the code names or cannot remember the
codenames for them a link is provided where after clicking on this link a page appears where we
can get to know the station code for a given station name.
(Refer Slide Time: 46:00)
So, in summary, to achieve the goal to perform the task of entering source and destination station
names what the user gets to do. First of all the user needs to locate the appropriate hyperlink on
the screen, which as I pointed out is not very easy for novice or intermittent users, it may be okay
with expert users. Then enter station codes for source and destination and use the hyperlink
provided on the interface to learn about station codes if not known already.

Now, this is related to only the first task which is to input the source and destination station
name. Just to do that so many things the user needs to perform on the interface.
(Refer Slide Time: 46:49)
Now, many users significant user population which includes intermittent users, and no-vice users
which may not remember which is quite natural remember codes for all the stations. Now, in that
case, they are forced to use another hyperlink. Now, that actually creates inconvenience. Because
again there is a screen change and too many screen changes create inconvenience for lay-persons
lemon users.
(Refer Slide Time: 47:29)

So, these design decisions were just to enter 2 station names either the user has to remember the
code or has to use another interface to learn the code or to place the option to enter station names
or station codes. In an obscure position on the screen which makes it is difficult to find out the
link in the very first place. These types of design decisions are not very good decisions they
actually violate some of the golden rules. So, if the rules were used then probably such decisions
would not have been made.

In particular, the design that we have just discussed violets the second rule design for universal
usability, we have already seen how so effectively the design by keeping the link in a very
obscure place makes it very difficult for novice and intermittent users to locate them in the first
place. So, whenever they use it they find it difficult to find the specific hyperlink to locate the
specific hyperlink.

So, it is not very useful to novice and intermittent users for frequent users this may not be an
issue. Secondly, it violates the seventh rule which is to keep users in control. So, when we are
asking users to enter station codes and if the station code is not known then forcing the user to
select another interface then from there find out station codes. This actually makes the user feel
that they are not in control of the overall operations on the interface.

If the users would have been able to simply enter the station names instead of doing so many
things then they would have probably felt it to be in control. However, the very design that was
conceptualized and proposed makes it difficult for users to feel in control. So, that violates the
seventh rule. It also violates the eighth rule which is to reduce short-term memory load. So, when
we are asking the users to enter station codes, there can be hundreds and thousands of
unimportant stations.

Users may like to choose any pair of stations. So, hundreds of thousands of codes need to be
remembered but all those things will not be possible to accommodate in the short-term memory
.Because of its limitations, it can hold maximum it can hold for some users 5 pieces of
information for other users 9 pieces of information on an average 7 pieces of information. Each
code we consider to be a piece of information then on average 7 codes is fine but that is not
practical.

There will be hundreds and thousands of such codes and the interface forces the user to
remember them otherwise the user has to do additional operations to know it. So, the user either
has to remember or so either has to put more cognitive effort into remembering the codes or put
more physical effort into selecting the other hyperlink going through the link, going through the
information on the page and learn the code.

Both affect user’s cognitive effort and in turn, it affects the eighth rule which is to reduce
short-term memory load. So, these 3 rules are clearly violated in the particular design. That we
have seen.
(Refer Slide Time: 51:34)
Now, the design is done and we have identified that there are these 3 issues with respect to the 8
golden rules. So, what to do? Design for universal usability requires us to put this particular
hyperlink of getting to input station details for any pair of stations on a prominent place
preferably in the central place which is a design modification required. The second thing is once
this hyperlink is selected and this second page appears where station codes need to be entered.

So instead of forcing the user to move to a third page, to get to know the station code within the
second page itself, there should be some support provided. So, that user does not need to
remember the code instead the system helps the user remember the code how that is possible?
(Refer Slide Time: 52:39)
One way to do that is to use a predictive interface. Where we can predict the text from a few
characters? So, in this case, suppose the user does not know the station code. Now user
remembers the station name, so from the name few characters of the name, once the user inputs
then the code appear automatically by prediction, which will help the user in a great way.
(Refer Slide Time: 53:05)

So, the user enters characters for the station name. As soon as the user starts entering characters
system predicts station name and code both so, that the user gets to understand that this code is
meant for this name and the prediction can appear on a drop-down list. So, suppose this is the
text field. Suppose I want to know the code for the station, Howrah the moment, I enter h than in
a drop-down list, it shows codes corresponding to the station starting with the name H. So, there
may be a station name and corresponding code.

Then I enter W so to refine the list enter W then this display changes to all the station names
having HO as starting 2 letters and the corresponding codes. As soon as I locate the code, I just
select it rather than, having to find it from a big repository of information. So, this type of
predictive text interface helps us to effectively nullify the shortcomings that we have identified.
(Refer Slide Time: 54:41)
So, this can be one way of doing things. So, here the user entered K corresponding to K all the
station names appeared, and beside the name, this code appears as shown here. So here then the
user does not need to select the hyperlink and open another page to browse through the name of
stations to learn about their corresponding code. Instead, the user can simply start entering the
station name and the code automatically appears through prediction on a drop-down list and the
user just need to select it. So, this alleviates the issue of violation of the golden rules.
(Refer Slide Time: 55:32)

So, that is in summary what we can do with the guidelines. So, guidelines just to recollect.
Guidelines are starting points. Now, we may be having some intuition about design and interface
design. So, we can always use intuition to come up with the design but then whether the design is
going to be usable or not, one way to do it is by going through the entire design prototype
evaluation cycle. But before that also our intuition can be guided by the guidelines to come up
with initial designs or if we have some initial designs, we can simply apply the guidelines to
refine the design before we prototype and evaluate it.

So, in that way guidelines provide us with starting points in the design prototype to evaluate the
life cycle .So, here in this lecture, we learned about the 8 golden rules of Ben Schneiderman
which is a very generic set of guidelines applicable primarily for graphical user interfaces. But
because of its generic nature can be applied to other types of interfaces as well. In the next
lecture we are going to learn about another set of guidelines namely the 7 principles of Donald
Norman which again was proposed almost at the same time, when the eight golden rules were
proposed.

we will learn in more detail about those principles and what they refer to in the next lecture
whatever we have discussed today can be found in this book particularly chapter 2 section 2.4.4
so that is all for this lecture I hope you enjoyed the learning and got to know about the guidelines
and how it can be used in practice hope to see you all in the next lecture thank you and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology, Guwahati

Module No # 03
Lecture No # 14
Norman’s Principles

Hello and welcome to the NPTEL MOOCs course on the design and implementation of
human-computer interfaces. We are going to start lecture number 13 on interface design
guidelines. So, we will continue with our discussion on interface design guidelines which we
started in the previous lecture before, we start let us quickly recap what we are discussing. What
are these all about? So currently, we are discussing the interactive system development life cycle.
(Refer Slide Time: 01:18)

In the life cycle, several stages are there we have already covered the requirement gathering
analysis and specification stage, where we have learned how to identify and specify requirements
for a system? Now, these requirements include requirements from the point of view of the users
or usability requirements as well as the requirements by the client or customer which are
generally called functional requirements or features in the system.

Now, usability requirements can also be converted to functional requirements as we have seen in
our case study. So, we have learned how to gather these requirements and how to specify them
and create SRS documents? So, that is the outcome of this stage SRS now, once that is there then
we enterinto this design prototype evaluation cycle. Here, we start with design in design 2
designs are referred to one is interface design other one system design.

So, first, we talk about interface design. How to design the interface and interaction so as to
ensure usability? Now that design has to be prototyped and evaluated to refine the design. Once
the interface design is stabilized or finalized go for system design, which we refer to with the
same stage name design. So, at the end of the interface design cycle, we geta design document
say interface design document and at the endof the next design cycle that is related to system
design.

We get the final design document as the output of this stage. Now, this design document is then
used to implement the system which ispart of the coding and implementation stage. Here we go
forward to implement the design in the form of executable programs. So, the outcome of this is a
code now, this code is tested to check for its execution ability and this execution ability istested
through different means, which is done in the code testing phase.

In the end, there may be a test document generated after that, we get a full executable system and
then we go for usability testing of the full system throughthis method called empirical study or
empirical research method. Where; we employ end users in a controlled experimental setup to
determine usability issues. Determine and resolve usability issues after the system is designed as
usable and executable, we go for the final stage which includes deployment and maintenance.

That is the overall life cycle for any interactive system development. So, we have already
covered requirement gathering currently we are continuing with the interface design phase.
(Refer Slide Time: 04:59)
Now, in the design stage, there are 2 issues of concern one is where to start andhow to express
the design. So currently, we are focusing on where to start the design of an interface. So, we saw
that the starting point can be our experience intuition and it can be added or it can be done with
the help of design guidelines. We have already discussed one set of design guidelines which is
Schneiderman’s 8 golden rules. In this lecture we will cover another set of guidelines called
Norman's 7 principles. So, this set of guidelines is named after Donald Norman who proposed
the set.
(Refer Slide Time: 05:46)
Now, before we actually turn our focus on the actual set of guidelines or principles, we should
note that these guidelines or principles are based on a descriptive model of human-computer
interaction. So, whenever a human user interacts with a computer system here, note that the term
human user refers to layman users. Then, that interaction can be modeled. So, one such model
was used to develop these principles.

Let us first try to understand that model. So, we will first try to understand the underlying model
descriptive model which gave rise to these 7 principles. Now, this model is called the model of
interaction by Norman or Donald Norman who proposed this model. Note that this is a
descriptive model which means it can explain interaction rather than predict future effects of the
interaction.
(Refer Slide Time: 06:59)

Now, the model was proposed by Norman way back in 1988. Almost, contemporaneous to the
golden rules by Ben Schneiderman’s, which was proposed in 1986. So, the setting was similar
basically, this model was proposed to explain interaction with GUI’s or graphical user interfaces.
Just to recollect at that point in time the GUI was coming into focus, those were being
extensively developed and used in personal computing devices that were coming up at the time,
particularly personal computers.

So, because of the popularity of those interfaces, it was felt necessary to study and analyze those
interactions and come up with better designs. In that context, such models and guidelines were
proposed that include the golden rules by Schneiderman’s, as well as the 7 principles by Norman,
which is based on the explanatory or descriptive model of interaction with GUI, which again was
originally proposed by Norman.
(Refer Slide Time: 08:14)

Now, the model essentially represents the behavior of a user here. The user should be understood
as a layman user or someone who is not an expert in the underlying technology. So the model
represents the behaviour of a layman user of interactive systems in terms of a series of actions.
So, the model is nothing but a series of actions that represent the behaviour of a lay person or
layman user when he or she is interacting with an interactive system.

Now, here of course although we are using the generic term interactive system, originally the
model was developed keeping in mind interaction with graphical user interfaces which is one of
the earliest examples of interactive systems.
(Refer Slide Time: 09:16)
Now, these actions are the series of actions that is the model these actions represent 2 things. The
cognitive activities as well as the sensory-motor activities of the users so, when we say that we
are trying to model the interaction essentially what we are doing is? We are trying to model the
cognitive behaviour that is the behaviour that goes on inside the mind and the sensory-motor
behavior of the user. Sensory motor behavior refers to behaviour that is taking place through the
use of sensory organs and motor organs.

What are our sensory organs? Namely, we have 5 sensory organs eye, ear, skin, tongue, and
nose.Through this we sense the environment, and what are our motor organs. Everything can be
a motor organ like the eye which can move the mouth, head, hand, and leg. So, whenever interact
we make use of our sensory organs to sense the system state and take mental actions to process
the sensed information and then perform some motor actions to interact with the system based on
the input which is sensed through the sensory organs.

That is in a very broad sense how we can view interaction. Now in this model of interaction by
Norman this broad idea is further concretized with a set of actions presented in sequence.
(Refer Slide Time: 11:16)
To be precise the model talks of 7 such actions covering the cognitive as well as sensory-motor
activities of the user while, interacting with a graphical user interface. Now, because there are 7
actions mentioned. So, the model is also often called 7 stages of action. So, in either way, we can
call it either model of interaction or 7 stages of action both refer to the same model.
(Refer Slide Time: 11:55)

Now, these activities or actions these series of actions can be divided broadly into 2 stages. This
idea stems from the fact that any interaction can be broadly divided into 2 stages. One is the
execution stage another one is the evaluation stage. Let us try to understand what are these
stages? And what they actually imply?
(Refer Slide Time: 12:25)

So, out of the 7 actions or activities that form the model our actions are part of the execution
stage.What are these actions establish a goal that is action number 1 formulate intention action,
number 2 specify action at the interface action, number 3 an execute action, number 4 the
remaining 3 actions constitute the evaluation stage. Now, these 3 actions are to perceive system
state, interpret system state, and evaluate system state with respect to the goal.

So, these are the 7 actions. action number 1 establishes goal, action number 2 formulate
intention, action number 3 specifies action at the interface, action number 4 executes action,
action number 5 perceives system state 6 interprets system state, and 7 evaluates system state
with respect to the goal. Out of these 7 actions, 4, 1 to 4, these 4 actions are grouped together and
called the execution stage of interaction. 5 to 7 these 3 actions are grouped together and called
the evaluation stage.

So, there are 2 broad stages of interaction per the model execution stage and evaluation stage. In
the execution stage, 4 actions are defined as part of the model, in the evaluation stage 3 actions
are defined as part of the model. Now, let us try to understand what these actions are?
(Refer Slide Time: 14:33)
So, in the execution stage as we have just seen we carry out 4 actions what are these actions? Let
us see, the very first action, that we perform it should be noted that all these actions have to be
performed in sequence it is not a random sequence. So whenever, we want to explain an
interaction, we have to consider these actions happening in the sequence these are shown. So, the
very first thing in that sequence of 7 actions is to establish a goal, which is part of the execution
stage.

So, what does it mean? It means that before we start interaction we create or establish a goal to
achieve in our mind. For example we want to interact with a GUI through a selection of a button.
So, our goal is to select a button on the screen that is the goal. We have not yet selected or done
anything physically, but we have established the goal. There is this button I have to select it. So,
that is the first action in the execution stage.
(Refer Slide Time: 15:51)
Once the goal is set, the next action in the execution stage is we formulate our intention to
achieve the goal. So, that is again another mental activity that we perform before we actually
start doing the physical activity. So, the first is one mental activity to establish the goal, second is
another mental activity to formulate our intention to achieve the goal. That means, we think
mentally that this is the goal to achieve this we need to do these things. So, that is our intention
and we do that in the second act.
(Refer Slide Time: 16:36)

Next, we translate our intention into a sequence of the real-world task. Now, this is important so
mentally we define our intention or set our intention, formulate our intention that we have to
achieve this goal, and in order to do that we need to do certain tasks. But, those tasks that we
thought of mentally need not be supported by the interface. So, the third action that we should
perform is mapping the mentally determining tasks to the tasks supported by the device or by the
interface, which will allow us to achieve our goal.

So, we need to translate our intention intothe sequence of real-world tasks. As an example, we
may have set the goal of selecting a button and formulated our intention as that to select the
button we need to select, we need to point to it, and then do something to select it. Now, this
series of sub-tasks that we need to perform to select it is our mental thinking. Now to point it we
have not concretized anything.

Now in the third stage, we can think of mapping these intentions of pointing a button or locating
a button, or selecting a button in terms of things that are supported by the system. For example,
grab the mouse drag the pointer to the button, and press the button. So, these are tasks supported
by the interface. So, our intention has to be mapped to these tasks which are supported by the
system or interface that is the third action in the execution stage.
(Refer Slide Time: 18:44)

The execution stage also involves a fourth action which is the actual execution of the tasks. So,
in the first action we set a goal, in the second action mentally we formulated our intention to
achieve the goal. In the third action we translated this intention to real-world tasks and the fourth
action is actually performing these tasks. That is actually grabbing a mouse, actually dragging a
pointer, and actually pressing a mouse button. So, that is the fourth and final action in the
execution stage. So, that is the execution stage.
(Refer Slide Time: 19:36)

Now, if you have noticed there are 4 actions out of which the first 3 actions are purely mental.
So, this mental or cognitive behaviour of the user is captured with the first 3 actions. The last
action involves human motor action the last action actually captures the motor action of the user.
So first, 3 capture the cognitive behaviour, and the last action captures the motor behaviour.
(Refer Slide Time: 20:14)
Let us now move to the evaluation stage. That is the second stage of the interaction with an
interface in this context a graphical user interface. So, in this stage, we first perceive the system
state or the state of the interface. So, whenever we are using the term system we are actually
referring to the interface because a user interface is synonymous with a system. The user is not
aware of what is going on inside the computer.

So, anything that is not visible or perceivable to the user is irrelevant and whatever is visible is
relevant and that actually is the system to the user. So, in the evaluation stage, the first task is to
perceive the system state or state of the interface. For example, after we perform the task to
select a button, we look at the screen. So, to perceive the outcome of the selection operation so,
we intended to select a button we formulated intention.

We set a goal first formulated intention, translated to actual actions, and perform the actual
actions. After that, we try to perceive what happens to the interface or the screen. So, we look at
the screen to perceive the interface. That is, the first action that we do in the evaluation stage.
(Refer Slide Time: 21:54)

Perception is followed by interpretation we try to make sense of the sensory inputs. So,
perception involves perceiving through our sensory organs. Now, that collects information from
the environment then comes interpretation the second action in the evaluation stage, where we
try to make or where we try to understand the meaning of the sensory input. For example, if we
continue with our button selection task for example so, if the colour of the button changes after
we select it.

We might interpret this as the button selected if the colour does not change, we might interpret it
as a button not selected. So, after we perceive the screen and sensed through our eyes the button
with its colour and interpreted that there is a colour change. So, the button is selected that is one
outcome of this action. If there is no colour change that is sensed through our visual sensing
system that is the eyes.

We may interpret it as the button is not selected, so we may try to select it again. So, the second
action in the evaluation stage is an interpretation of the sensory input which we gather as the first
action in the evaluation stage.
(Refer Slide Time: 23:44)

The third action is very crucial that is we evaluate the result of our action by comparing it with
the goal state. So, we perceive the state interpreted the state and come to a conclusion that this is
the outcome. Now, this outcome we compare with our goal to see whether we have reached the
goal. For example, we may compare the interpretation that the button is selected to our goal state
that selects the button.

So, this comparison is the third and final action in the evaluation stage.So, in the evaluation stage
then we perform 3 actions. One is to sense the environment or sense the system state or perceive
the system state then whatever we have perceived we need to interpret as the second action and
finally, the result of interpretation is compared with our goal state to understand whether we
reach our goal state or not.
(Refer Slide Time: 24:53)

Again, if you have noticed carefully the first action that is perceived in the system state is related
to our sensory organs. So, this action actually models our perception behavior. The last 2 actions
are purely mental. So, models our cognitive behavior. So, in the execution stage, we have seen
that there are 3 cognitive actions and 1 motor action. In the evaluation stage, we can see that
there is 1 sensory action and 2 cognitive actions.
(Refer Slide Time: 25:42)
So, as you may have noticed by now that with these 7 stages, we can try to understand any
interaction with graphical user interfaces in particular and generally interactive systems of any
nature. Because these actions are very broad and generic and the overall model refers to any
interaction rather than specific interaction. So, whenever we are interacting with any GUI, for
example, one web page we can try to analyze, how we interact in terms of these 7 actions.

But once we do that, then what? So, what we gain by analyzing in terms of 7 actions. In fact,
these actions are the model if deployed properly, to understand an interaction can lead to many
interesting outcomes. One interesting application of the model is in terms of the execution
evaluation cycle. So, the model proposes to view any interaction as a cycle of these 2 stages, the
execution stage, and the evaluation stage.

So, with this model, we can think of any interaction as comprising of cycles of these 2 stages
execution stage and the evaluation stage. If the evaluation matches the goal then the cycle stops.
Otherwise, it continues till the goal is achieved. So, the last action in the evaluation stage is to
compare with the goal state. If the goal is achieved, we stop it otherwise, we start the execution
stage again with the 4 actions and then go to the evaluation stage again to compare whether we
reach the goal stage and this cycle goes on till we arrive at the goal state. So, that is a very
interesting way of looking at any interaction.
(Refer Slide Time: 27:58)
So, graphically we can represent an interaction in this cyclic form we have an execution cycle,
and evaluation cycle, so the execution cycle starts with the establishment of coal and come to the
actual action on the interface. The evaluation circle start after the actions are performed and the
perception of the state begins and it reaches the final act where the goal state is compared with
the outcome of the evaluation stage.

If it matches, then the execution stops the execution of the cycle. Otherwise again we go to the
execution stage and this continues. So, that is a nice way of looking at any interaction.But again,
so what so we get to know this cycle. Then what we can do with this knowledge?
(Refer Slide Time: 29:07)
(refer time: 29:07) This simple descriptive model of interaction can be put to much significant
use. Now, this model helps to develop 2 powerful concepts. What are these concepts?
(Refer Slide Time: 29:24)

One is called the gulf of execution. Now, this concept states that actions that we; specify to
translate intentions to action supported by the system, may not be supported by the interface.
Leading to a gap or gulf between the; first 3 actions in the execution stage and the last action in
the execution stage. So, the first reaction just to recollect tells that we first establish a goal then
formulate intention and translate intentions to some set of actions that are doable on the interface.

It may so happen that the interface does not support those actions that we identified after the
translation stage. Then in spite of having come up with a set of actions to be done on the
interface is not supporting those actions. So, we will not be able to perform those, actions. If
there is such situation then we call that there is a gap or gulf between the first 3 actions and the
last action of the execution stage so, this is called the gulf of execution.
(Refer Slide Time: 31:00)
Similarly, we can have a gulf of evaluation our interpretation of the interface state based on our
perception may not match the actual state of the interface. So, what we are perceiving and
interpreting as the system state may not match with the actual state of the system. In that case,
we call it a gap or gulf between the first 2 actions in the evaluation stage and the last action in the
same stage so, in case of a gulf of execution, we have a gulf or gap between the first 3 actions
and the last action in that stage.

And in case of a gulf of evaluation, we can have a gap or gulf between the first 2 actions and the
last action of the evaluation stage.
(Refer Slide Time: 32:15)
Now, these 2 concepts gulf of execution and the gulf of evaluation can lead to further application
of the model. These concepts were actually found to be quite useful in analyzing GUI’s graphical
user interfaces and many other interface designs and they were useful in identifying design
flaws. So, these concepts of the gulf of execution and gulf of evaluation were used heavily in
analyzing designs of GUI as well as other interactions.

That this is particularly true in the context of errors analyzing errors that may happen due to
design flaws in interfaces. The explanation of errors can be done in terms of 2 concept slips and
mistakes. So, we can make use of the outcome of the model namely the gulf of execution and the
gulf of evaluation concepts, to explain the occurrence of errors in user interaction with interfaces
particularly GUI’s in order to do that we can take the help of 2 concepts slips and mistakes.
(Refer Slide Time: 33:31)

So, there are 2 types of human error slips and mistakes. Norman's model of interaction tells us
when slips can occur and when mistakes can occur. Based on that information we can take
corrective measures in our interface design. So, let us first understand what are these concepts?
When we say that a slip has occurred during an interaction, we can explain it as due to these 3
things taking place that the user has understood the system and the goal.

The user has correctly formulated mentally the actions required to achieve the goal. But the user
has made some mistakes made some errors in performing the actions sleep happens when the
users have understood the system and goal formulated intention correctly and specified the
sequence of actions required to achieve the goal. But, made incorrect actions on the interface to
achieve the goal ten if some error happens, we call it a slip.
(Refer Slide Time: 35:01)

In contrast when you say that mistake happened? This may happen because there is some
problem in formulating a goal properly. So, if the user is able to formulate a goal and specify
actions. But could not perform the actions correctly then that is one type of error we call slip. If
the user is unable to specify or establish the goal itself the very first action in the execution stage
then if that leads to an error then we call it a mistake.
(Refer Slide Time: 35:40)
So, once we are able to understand the nature of the error whether it is a slip or a mistake we can
think of corrective actions. So, in case of slips, if we notice that slips are happening, that can be
fixed with a better interface design. So, those incorrect actions are difficult to perform. But if a
mistake happens then, interface design change may not be helpful and users need to be trained on
the interface properly.

So, it requires a better understanding of the system rather than, changing the system of course
changing the design can help in understanding. But only changing the design will not be
sufficient in case of slip so here along with the refinement of the design if required the user has
to be thoroughly trained to make him or her understand the system in a better way. So, for errors
that slip we can take one corrective measure.

For errors that are due to mistakes, we can think of other corrective measures. So, it is very
important to know what; kind of errors are happening more frequently, and accordingly, we can
take corrective measures to elevate the problem.
(Refer Slide Time: 37:06)
So, that is one very interesting application of Norman's model of interaction. So, it gave us these
powerful concepts of the gulf of execution and the gulf of evaluation. Using these concepts, we
can understand why an error happens and what kind of error happens for a given interface. And
we will be able to judge better the nature of the error, and based on that judgment, we can take
corrective measures. That is one interesting and important application of Norman's model of
interaction.

Now the same model can also be used to recommend design guidelines which can serve as the
starting point of any interface design activity like the way we can use the 8 golden rules by
Schneiderman. Now, these recommendations in the form of guidelines there are 7 such
recommendations called 7 principles. Let us see what are those 7 principles which is an outcome
of the model of interaction.
(Refer Slide Time: 38:23)
The first principle is while designing any interface, the user should be able to make use of both
knowledge in the world and knowledge in the head, use the interface and the design should
support in that behavior. The second principle states that any task that is performed by the user
who is using the interface should have a simple structure. So, the structure of tasks should be
simplified and presented in a simplified manner for the user to perform.

The third one is very important; whatever the interface does should be visible to the user so make
things visible.This helps in bridging the gulps of execution as well as the gulfs of evaluation. The
Gulf of execution and gulf of evaluation both can be bridged if things are made visible. Now, the
model talks about the mapping from intention to actual physical action.The design should be
made in a way such that this mapping is done appropriately and rightly.

So, the user is able to map rightly so the design should support actions that are easy to
understand and easy to map to intention. That is one of the important principles. While designing
the principles; also advises the designer to exploit the power of constraints both natural
constraints and artificial constraints. So, this is another recommendation that whenever you are
designing something you should be aware of the limit of interaction and you can impose
constraints in the interaction and interface elements to make it easier for the user to understand
comprehend and use the system.
The sixth principle talks about taking care of errors if during interaction error happens the design
should support error handling. So, we should design for handling errors knowing that it will
happen and the last one is somewhat interesting that if in spite of best efforts the designs are not
behaving the way they should be expected to behave. We can standardize all the interactions and
interface elements. So that it is enforced on everybody to use the way it is recommended.

So, flexibility is reduced and minimized with the process of standardization. Flexibility in the use
of the interface, as well as flexibility in interaction with the interface, is reduced with the
standardization of the design. So, that expected outcome is achieved. So, these are the 7
principles that resulted in one of the outcomes of the descriptive model of interaction proposed
by Norman.

Now, these 7 principles can be used as a starting point for interface design. So if we have any
design in mind we can see whether these principles are followed in the design of that interface.
Then, we can go ahead and prototype test and do the other things in the design prototype
evaluate cycle. So these 7 principles can act as a starting point in the same way. We can use the 8
golden rules as a starting point for interface design.

So, with that, we come to the close of this lecture. So, here in this lecture what we learned, we
learned about a model of interaction which is a descriptive model that means it cannot predict.
What is going to happen rather it can explain what is happening and why it is happening? Now,
based on that model or idea of the interaction we can do several things so the model talks of 7
actions as representative of any interaction these actions are grouped into the execution stage and
evaluation stage.

In the execution stage, there are 4 actions performed in sequence. In the evaluation stage, 3
actions are there performed in sequence and the evaluation stage actions follow the execution
stage actions the model says that these actions represent the cognitive sensory and motor
behavior of the users and these actions are performed in a cycle the execution evaluation loop,
till we achieve the goal of interaction.

So, this model gave rise to powerful concepts such as gulf of execution and gulf of evaluation
which help us to understand interactions better and interpret things that are happening with the
interaction.It also leads us to analyze the erroneous situation, understand the nature of errors that
are happening with an interface, and can help us take corrective measures to reduce or minimize
the occurrence of errors.

So, this gulf between execution and evaluation helps us to understand that errors can be of 2
types slips and mistakes.If sleep happens, we can go for a better design.If a mistake happens,
then along with design we have to train the user on the interface.If trending is turning out to be
too hard then that means the design is faulty. We need to change the design, but train on the
refined design nonetheless to avoid mistakes.

That is one of the outcomes another outcome is to come up with a set of design guidelines. So, in
this case, we have the 7 principles, that were formulated based on this model and these principles
can be used as a starting point for interface design. I hope you enjoyed the learning so far and
understood the concepts, explained in the lecture.So, that is all for this lecture.In the next lecture,
we will take up the other stages namely prototyping, evaluation, and the subsequent stages.

That is all for now whatever I have discussed can be found in this book, particularly in chapter 3
section 3.3.2. If you go through this book this chapter and section you will get to know more
about this descriptive model and how it leads to the principles so thank you and see you all in the
next lecture goodbye.
 Design & Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Module No # 04
Lecture No # 15
Prototyping

Hello and welcome to the NPTEL MOOCS course on design and implementation of human
computer interfaces lecture number 14 on prototyping. In the previous lectures we have covered
several topics.
(Refer Slide Time: 01:00)

The topics are related to the different stages of the software development life cycle for interactive
systems. Earlier we have seen how to gather usability requirements using contextual inquiry. We
have also seen how to convert the requirements into system design into design of interfaces
where we made use of guidelines and we have also covered few guidelines for the purpose. In
this lecture we are going to talk about another stage in the development life cycle namely the
stage in which we create a prototype of the design that we got after the design stage.

But before we proceed further as usual we will first have a quick relook at the stages of a
software development lifecycle for interactive system development.
(Refer Slide Time: 02:17)
If you can recollect we have several stages as shown in this life cycle we have requirement
gathering analysis and specification stage we covered this stage in details. Where we learned
about different ways to capture end user requirements and we went through one particular
approach that is contextual inquiry. Now here end user means the users who are going to use the
system rather than the clients or customers and the requirements here primarily refers to usability
requirements.

Then we have this design prototype evaluate cycle in which there are 3 stages design stage,
prototyping stage and evaluation stage evaluation of the prototype. So here design refers to 2
types of designs one is the design of the interface where usability is the primary concern other
one is the design of the system where execution efficiency is the primary concern. Now we
learned how to create a design of an interface? We talked about some design guidelines as a
starting point for designing our interface.

Now that design needs to be tested for that we need to make prototypes and get it tested through
some early evaluation methods based on the test results we can update that design and this goes
on in a cycle. Once the interface design is finalized we go for the system design where we build
the design for the code. Now there we basically focus on modularity and maintainability of the
code for quick implementation by a team.
After the system is designed we go for coding and implementation which is followed by code
testing. So the code testing primarily deals with testing the execution ability as well as the
efficiency of the code in terms of resource usage. Once this phase is over we get a working
system which is supposed to be executable and resource efficient. However we still have not
addressed through these testing’s the overall usability of the end product.

For that we have this next stage that is empirical study also called empirical research here with
end users we test the product for usability issues if any. And if some issues are found out then we
may need to go back to the earlier stages to refine and revise the design and subsequently change
the implementation. Once we get a system which is usable as well as executable we go for
deployment and the subsequent stage of maintenance. So this is in a nutshell the stages and the
overall life cycle for interactive system development.
(Refer Slide Time: 05:44)

Among these stages we have already covered requirement gathering stage; we have covered
interface design stage. We are now going to cover the next stage that is prototyping so essentially
expressing the design that we have come up with for testing purpose. In the earlier lectures we
have seen that we can make use of design guidelines to go for interface design now that provides
a starting point.
(Refer Slide Time: 06:22)
However they are just that merely a starting point with this we can go for a design but we still do
not know whether that design is going to be usable or not. So essentially what we need to do is?
Basically we need to express the design for evaluation some sort of evaluation need not be very
rigorous but some sort of evaluation.
(Refer Slide Time: 06:42)

Now to express the design our intuition may tell us that go for full implementation of the system.
Which is what most of us anyway think intuitively that ok this is the design idea let us go and
implement it and then test it to know whether it is going to work in practice but that need not be
the case. To know if the design is going to work in practice we need not fully implement the idea
first that is not necessary.
(Refer Slide Time: 07:19)

Instead what we can do we can go for building a prototype which is a lightweight

implementation in a sense to test our idea. So once we have come out with a design idea to test
the idea it is not necessary to go for full-fledged implementation of the idea in this case
interactive software interface. Instead what we can do we can much reduce our effort and cost of
development by going for lightweight implementation.

We will see what we mean by lightweight implementation in subsequent part of this lecture but
what is required is a lightweight implementation of the design idea. So that it can be tested to
know whether the design idea is going to work in practice if not then we need to revise our idea.
And that lightweight implementation is nothing but a prototype for the design idea.
(Refer Slide Time: 08:26)
So prototyping can be used for getting feedback on our design idea whether this is going to work
in practice or not. In user centric or user center design approach prototyping plays a very
important role these are built typically at a very early stage of the development life cycle. So
unless we take recourse to prototypes what we have to do is basically go for full-fledged design
and full-fledged implementation which involves lots of effort and cost.

Now once everything is done completely and then we test it and then get to know that there are
issues revising, those designs or implementations adds to the cost significantly. So we need to
avoid that for that we need to make use of prototypes which are lightweight implementation
reduces cost to a very significant extent. Cost as well as effort of development and allows us to
test without going for full-fledged implementation in that way it helps us manage the overall
effort and cost of the project.

Also typically prototypes are built at a very early stage of the development so that we get
feedback quickly and without spending too much time and effort as well as money. So these
prototypes are significant part of any user centered design approach.
(Refer Slide Time: 10:05)
Now once the purpose of a prototype is served that means we get some feedback on the design
idea by evaluating the prototypes we can discard the prototype that is what is commonly done.
So the prototype is discarded.
(Refer Slide Time: 10:25)

But that need not be the only possible way of utilizing prototype. On the other hand we can reuse
the prototype we can incrementally refine the prototype as we make progress in the development
till the end at which point it becomes the fully implemented product in itself. So what we can do?
Either we can discard the prototype after we test the design idea or we can keep on incrementally
refine the prototype. And test it and again refine it till we reach the end of the development cycle.
At which point of time the prototype itself becomes the final product that is another extreme of
the use of prototype. Now there are different ways a prototype can be made so based on
functionality that a prototype serves we can divide them into 2 broad categories.
(Refer Slide Time: 11:35)

One is horizontal prototypes what these prototypes do is basically they allow us to express the
entire interface at the surface level but without any functionality. So in horizontal prototype what
we try to do we basically express the entire interface at the very surface level without adding any
functionality to the prototype. So we cannot do any real work rather we can just test the look and
feel.

So interactions are not prototype in horizontal prototypes since we are not implementing any
functionality so we cannot do any real work in that sense that is we cannot interactively perform
any task with such a prototype. So then if we are unable to do anything then what purpose does it
serve? It serves significant purpose of course these are primarily suitable to discuss brainstorm or
elicit feedback on the interface look and feel primarily.

So the primary purpose is to get feedback or to test the look and feel of the proposed design that
is what we can achieve with horizontal prototypes.
(Refer Slide Time: 13:14)
Now there is another category of prototypes that is vertical prototypes as opposed to horizontal
prototype in these prototypes we can represent interactions. So vertical prototypes are designed
to represent interaction horizontal prototypes are designed to represent interfaces primarily.
Whereas vertical prototypes are primarily designed to represent interaction since interaction is
represented it can also represent interfaces so it can represent both.

However that does not mean that with vertical prototypes we implement every functionality; of
the system that can be achieved through interaction. Instead few selected features or
functionalities are implemented in depth that is from starting to the end point. Starting from the
first screen when the interaction starts to the screen after, the last action is performed. So,
essentially the idea is that you choose a set of activities or interactions that can be performed
with the proposed system.

Now this set has to be chosen carefully typically representative use cases should be chosen.
Secondly the use cases that are chosen are to be implemented in full that means from the starting
screen the screen when the interaction starts to the screen when the interaction ends. And all
intermediate screens in between as well as the way to interact all these things have to be
implemented in a vertical prototype. Clearly these prototypes are suitable for analysis of
interactions and features of a proposed system.
So these are the 2 categories of prototypes which we can think of based on the functionalities
that they support. There can be another way to categorize prototypes as well.
(Refer Slide Time: 15:42)

That is based on how we can create the prototypes how prototypes are implemented. So one such
category is low fidelity so how to create prototypes there are different ways to create prototypes
and broadly there are 3 categories of prototypes according to the way they are created. One
category is low fidelity prototype in this case we do not require any technological intervention to
create a prototype we do not require any computer software or anything.

Instead we can make use of objects that are easily available such as paper, cardboards, woods,
clay and so on to create a prototype for a product. A very popular example of, such a prototype
are the paper mock-ups for interface look fill and even functionality. So when we are trying to
create a horizontal prototype we can use paper mock-ups which are a low cost way of
implementing the idea.

Since we are not relying on technology and technological expertise is not required these types or
these prototypes are quick to make and cheap to create. They are also quick and cheap to modify
as well because in this design prototype evaluate cycle we need to revise our design and
accordingly recreate the prototypes. So we should have a prototype which is not only easy to
create but also easy to modify and low fidelity prototypes are best fit for that purpose.
By the very nature of its way of implementation these prototypes are good for horizontal
prototypes and generally used for brainstorming on alternative designs and get user responses on
the idea so that is the anyway the purpose of horizontal prototypes.
(Refer Slide Time: 17:58)

One special and popular low fidelity prototype is interface sketches. Now this can be considered
to be slightly different from the other prototypes low fidelity prototypes that we have mentioned
in the previous part of the lecture. So this actually offers another, low fidelity prototypes which
are nothing but drawings as the name suggests name suggests drawings depicting major
components of an interface. So again we are trying to basically create interface look and feel

So we are trying to create prototypes for interface look and feel and interface sketches allow us
to do that. Again good for horizontal prototype because it, allow us to envision appearance of the
interface. However when we are talking of interface sketches it need not be the case that they are
made with simple papers or simple woods or clays or something so they can be typically drawn
on a paper.

In that case that is low cost but they can also be created using computers so some technological
expertise may be required but in principle interface sketches are considered to be low fidelity
prototype.
(Refer Slide Time: 19:17)
let us try to understand this with an example consider a shop now the shop sells various
consumer items such as clothes, bags and so on. The shop owner wants an interactive system to
generate bills based on the selection by a customer that is the requirement that has come from the
owner of the shop. The customer selection is scanned and identified by the system and the bill is
generated.

So that is a functional requirement which again has come from the client which in this case is the
shop owner. Now the shop owner wants to have a system which allows the customer to perform
such actions and then accordingly the system responds by generating a bill. A sketch for the
proposed interface design can be made so that whatever design ideas the developers come up
with can be shown to the client in this case the shop owner and his or her feedback can be taken.
(Refer Slide Time: 20:41)
Let us see one such interface sketch here as you can see this is one idea of the interface how it
should look like so it is created on a piece of paper. So it is a low cost implementation of the
prototype of the interface only the appearance rather than any real function. Here there are
according to this design there are several components one top component, then middle
component, top left and top right there are 2 components. Then middle component, then lower
component and a central component.

So these are the components that can be part of the interface as proposed by the design team and
this design can be taken for feedback. And this prototype can be taken to the client or the shop
owner for feedback on the design idea. So the top left corner component talks about certain
things top right corner component talks about the selected product.

Central component with the menu and the details shows the billing information and the lower
component here shows the options now the same sketch can be done in a different way. So here
when we are using paper and hand draws the sketch clearly the quality is not very high. We can
do the same thing with the help of a computer or sketching software.
(Refer Slide Time: 22:29)
As shown in this next version of the prototype the same thing but now; it is created with
sketching software. Again the same components top left, top right, central component with
menus and lower components. But now it looks much better and probably it will be easier to
collect feedback if such a sketch is used. So here we are not only relying on low cost
non-technological approaches to create the prototype. We may use some computers or
technology to create a good quality prototype although that is still low fidelity prototype.
(Refer Slide Time: 23:23)

Now sketches in itself are not sufficient to prototype interaction because they are primarily used
for horizontal prototyping. Primarily to get feedback on the look and feel of the interface as
probably we have seen in the previous example. In the example if we create such a prototype of
the interface which is the sketch it is not possible to know the sequence of actions and the
corresponding changes on the interface to execute a task such as a stroller purchase.

If the customer purchases stroller using the interface what are the actions and how the screen
changes that type of information is not possible to get using simple interface sketches for that we
need to do something more.
(Refer Slide Time: 24:21)

So sketches essentially represents horizontal prototypes now using the same idea and extending
the idea a bit further we can actually make use of the idea to go for vertical prototypes as well.
For that what we need to do is not to create a single sketch rather a series of such sketches.
(Refer Slide Time: 24:32)
For that what we need to do is not to create a single sketch rather a series of such sketches for the
interfaces at different stages of interaction. Now when we create such a series of sketches where
each sketch represents an instance of the interface during the course of interaction for achieving
a specific goal that series of sketches is called storyboarding. Now in other words storyboarding
idea can be used to represent interaction or to go a little bit further we can create story boards to
have a vertical prototype.
(Refer Slide Time: 25:18)
The idea originated from the film industry where such a storyboards are used to depict a scene.
So before a scene is sought its sequence is depicted using storyboards so the same idea is used
here.
(Refer Slide Time: 25:40)

Remember that storyboard refers to a series of sketches now each intermediate sketch in the
storyboard is called a key frame again the term is borrowed from the movies. Now a key frame
can be considered to be a snapshot of the interaction at a particular point of time at any specific
instance of interaction or a particular point of time during the course of the interaction.

So when we are using the idea of interface sketches and extending it to create vertical prototype
what we need to do is we have to create a storyboard depicting the interaction. Now in a
storyboard there are key frames or intermediate interfaces which results due to the interaction
during the course of the entire interaction.
(Refer Slide Time: 26:35)
So the key frames allow us to visualize the nature of interactions in its entirety for a specific
scene. So this is nothing but what we have discussed earlier as vertical prototype we want to
visualize interactions involving change in screens or interfaces and that we can achieve with a
storyboard having key frames. Where, each key frame represents an intermediate interface which
results during the course of interaction at any given point of time.
(Refer Slide Time: 27:13)

Let us try to understand this idea with an example suppose we are trying to design a mobile app
to find spicy food in our neighborhood that is the design idea.
(Refer Slide Time: 27:29)
So in a storyboard we try to capture the sequence of actions starting from the desire to find food
to the actual finding of food along with the appearance of the intermediate screens. So that
should be captured in a storyboard as shown in this series of screens. First screen shows the
desire to find food that is the starting point of the interaction then opening the app to do the same
that is second screen where it shows some food menu and whatever is available.

Then in the third screen we go for specific food items say in this case Indian then what should be
on they are under this Indian food menu north India and south Indian. 4th screen another
category is selected north Indian food and under which some menu options are available that is
depicted here. Fifth screen shows that we have zeroed in on a specific menu item with some
description.

And finally in the last screen we can depict what to do to order that food so we have 6 sketches
one, 2, 3, 4, 5 and 6 together these 6 interface sketches constitute the storyboard. Each of these
sketches is a key frame so there are 6 key frames which together make up the storyboard. And
each of these key frames represents an instance of interaction and the corresponding interface at
that point of time.

This is how we can create a storyboard and here as you can see by specifying the sequence of
key frames we can actually specify the interaction that the interaction for selecting a food should
happen in this way. So that is how we can create a prototype for the interaction using the idea of
storyboarding and just want to emphasize again that storyboarding is a low fidelity prototyping
technique.
(Refer Slide Time: 30:18)

So apart from low fidelity prototypes we can have another way of creating a prototype that is
medium fidelity by definition medium fidelity prototypes are those which are created using
computers. Now if the computer is used to create static sketches only it still remains horizontal
prototype since no real functionality is there. So earlier we talked of low fidelity prototype where
we are using non-technology based solutions such as paper mock-ups, use of clay, use of woods
to create prototypes.

In interface sketches we have seen that we can do it in either of the 2 ways one is simply drawing
the sketch on a paper hand-drawn. Other one is using a computer tool sketching tool to create it
on created using a computer in the latter case the quality is likely to be much better than creating
something on pen and paper unless the person who is creating the sketch is a skilled painter.

Now when we are creating a prototype using, say a paper and pen that is low fidelity. When we
are using the same prototype using a computer we can call it medium fidelity rather than low
fidelity because here we are having some technological intervention. So although in principle
everything is low fidelity because we are unable to do any specific functionality using
sophisticated mechanisms still since we are using computer we can call it medium fidelity to
differentiate it from the low fidelity prototypes.
So interface using sketches created using pen and paper falls under low fidelity prototype.
Interface sketches using created using computer falls under medium fidelity prototype. Similarly
storyboards having key frames created, with pen and paper falls under low fidelity prototype.
Whereas storyboards having key frames created using computer tools fall under medium fidelity
prototype. Of course this is how we implement the prototype it does not change the nature of the
prototype that is whether it is horizontal or vertical.

With medium fidelity we can have horizontal prototypes if there is no functionality support
provided. Whereas if we are using computer to create a storyboard with support for functionality
or interaction then that medium fidelity can be a vertical prototype. However with medium
fidelity we can go even further than simply replicating low fidelity ideas.
(Refer Slide Time: 33:32)

Medium fidelity prototypes can include videos as well so instead of creating simply sketches or
story boards we can create a full-fledged video showing the transitions with a medium fidelity
prototype.
(Refer Slide Time: 33:48)
For example we can have an animation video created with some software tools such as adobe
flash tool or similar tools. And that animation video can be used to prototype the food selection
app of the previous example in the video simple controls can be provided to simulate the
interaction. For example simply pressing a keyboard button say enter button or simply clicking
on the mouse button these can be simple controls utilized to simulate change of interfaces.

So we can create an animation video and enable it with simple controls to move forward to
simulate a vertical prototype but that is not the only way to have a medium fidelity prototype.
(Refer Slide Time: 34:46)
When we are talking of vertical prototype the interaction can also be simulated with as simple a
tool as a Microsoft PowerPoint slideshow. So a simple slideshow with timer can be used in place
of other controls to basically simulate a vertical prototype. So in this case the key frames can be
converted to slides if you know already how to create slides in ppt Microsoft PowerPoint then it
will be easier to understand.

So we can create slides which represent the key frames with simple controls such as a timer or
key phrase slight transition takes place depicting the interaction and in that way the storyboard
can be converted to a particle prototype a medium fidelity vertical prototype. So when we are
referring to the term medium fidelity we are essentially referring to the idea of low fidelity but
implementing those, idea with the help of computer.

Rather than non-technological means of implementation such as papers, pens or such similar
things but the ideas remain more or less similar such as interface sketches, storyboards, key
frames all these things remain the same.
(Refer Slide Time: 36:10)

The other major category is high fidelity prototypes unlike in low fidelity or medium fidelity
prototypes in high fidelity prototypes we rely on computer programs so the prototypes are
created by writing programs. So this indirectly means actual software development activities
involved in creating the prototype. Since, we are using programs to build the prototype so these
are more sophisticated as compared to low or medium fidelity prototype. But at the same time
obviously they require much more effort including expertise in programming than the other 2
prototyping methods.
(Refer Slide Time: 37:05)

To create high fidelity prototype it is not necessary to always start writing programs from scratch
there are supports provided in the form of interface builders toolkits and wizards to ease the
programming efforts such supports are already there.
(Refer Slide Time: 37:27)
Examples of such supports include the Tcl Tk toolkit for creating GUI’S visual basic
programming language again for creating GUI’S java swing library for creating GUI’S and so
on.
(Refer Slide Time: 37:46)

Now the toolkits and libraries that are already available provide support for widgets or GUI
elements graphical user interface elements such toolkits and libraries allow us to easily create
and manipulate such widgets in a prototype. So a programmer can directly use those widgets
from the tools and libraries available rather than creating them from scratch on his or her own.
And using those widgets it is much more, easier to build GUI’s quickly without too much effort.
(Refer Slide Time: 38:32)
That is one part of the story that is to create the interface other part is to implement the
interaction that is done through programming. Essentially by writing codes to listen to user
inputs and then accordingly take actions to change the interface all these activities are done by
writing programs. So tools and libraries provide support for both creating GUI’S as well as
implementing interactions.
(Refer Slide Time: 39:05)

For implementing interactions tools and libraries again provide support for event listeners so that
user inputs can be easily captured and then necessary actions can be taken. Now since it involves
lots of effort and it provides sophisticated prototypes high fidelity prototypes are typically used
for creating vertical prototypes where sophistication is required. For horizontal prototypes such
effort may not be worth of it so for purely horizontal prototypes it is preferable to go for low
fidelity or medium fidelity prototyping approaches.
(Refer Slide Time: 39:50)

One interesting prototyping approach is called wizard of Oz approach this is actually a very
interesting approach let us quickly try to understand it.
(Refer Slide Time: 40:02)

In this technique a human subject believes to interact with an autonomous computer note the
emphasis on the word believe. So, human subject believes that he or she is interacting with a
computer in reality that is not the case. What happens is that the computer is operated by an
unseen human being who is referred to as the wizard. Now the term originated wizard of oz this
phrase originated in the early 1980s but the concept was there from before but in the early 1980s
this was put into practice.
(Refer Slide Time: 40:46)

An example of application of this concept is the testing of the listening typewriter product by
IBM way back in 1984 what happened that time is that IBM was trying to develop a speech
recognition system. Now at that time speech recognition was a very futuristic technique although
nowadays we take it for granted but in 1984 it was a futuristic technique nobody knew how to
implement it successfully.

But at that time IBM was trying to estimate whether if such a system is made whether that will
be a sellable product an acceptable product. So IBM was trying to test something which is not
yet there and they applied this wizard of oz approach. So, they wanted to test the acceptability of
the idea requiring a working system otherwise how do you test the acceptability if you do not
have a system. But the problem is at that time nobody had the speech recognizer and the
company IBM did not want to spend money and effort before testing the acceptability.

So nobody knew how long it will take or whether it will ever be possible to develop a speech
recognizer. So to test it we first need to develop it but then that is risky uncertain and involves
lots of money. IBM was not interested in spending the money before they know that if they put
in effort then actually they will come up with a sellable product. So they want to test something
which cannot be made at that time.
(Refer Slide Time: 42:30)

So they decided to go for a wizard of oz experiment.

(Refer Slide Time: 42:38)

So what was there in the experiment in this figure the experimental setup is shown in this figure
on the left side sits the user. In front of the user there is a microphone user utters something and
get some response on the screen. So user thinks that there is only this computer and the
microphone but there is a wall in between behind the wall there are seats the wizard or a human
operator of the computer.

So the microphone output is connected to the computer of the wizard and to the speaker near the
wizard which is not audible to the user. So whatever the user utters the human wizard gets to
here and based on that the human wizard types a response which is transmitted to the user's
computer. And it appears on the computer here and the user thinks that because he uttered the
word the computer understood it and then gave the response because the user is unable to see the
wizard.

Or however of his presence because the user is unable to see the wizard or however of his
presence in that way the user thinks that there is a computer which understand the speech and
then responds according to the content of the speech. So based on this understanding the user
decides whether this system is good or bad so in this setup this feedback can be collected about
the acceptability of the system.

So this overall approach is called wizard of oz where we are not relying on actual technology
fully rather we are relying on a human in the loop for creating the prototype. So that is an
interesting way of creating prototype for futuristic technologies which are yet to be developed or
which are yet to be in a matured stage. So we have learned about different ways to categorize
prototypes.
(Refer Slide Time: 44:57)
Another important issue is how to use the prototypes again there are broadly 3 ways in which we
can make use of the prototypes. It can be thrown away that means the prototype is discarded after
use. For example if we are creating a cardboard mock-up or a paper mock-up or a wooden
mock-up or a clay model or sketches drawn on paper we need to throw it out. Because they are
not anywhere computerized but throwing them out is also not a problem because they are low
cost and takes very little effort to create.

So the idea of thrown away prototypes is that we should be able to create such prototypes rapidly
and with low cost. Otherwise it becomes too expensive to discard a prototype made over a period
of time with considerable man hours spent. So when we meet these criteria then we can throw
away the prototypes and these are one way of utilizing after getting feedback we throw it away.
(Refer Slide Time: 46:02)
Another way of using prototype is the incremental approach what this approach says here the
system is designed into units. So, overall system that we are trying to test is divided into units or
modules. Each unit is separately prototyped and tested afterwards it is integrated into the system.
So the entire system is divided into units each unit is prototyped, tested, feedback collected
revised all these things done.

And then they are integrated together into the whole system so that is an incremental approach.
Here we are not discarding but we are refining the prototypes of individual modules or units of
the system. And then finally once all are tested and refined we are integrating them into the
whole system that is the incremental approach.
(Refer Slide Time: 46:58)
Third approach is called evolutionary for utilizing prototypes we can go for evolutionary
approach as well. Here also we are not throwing away the prototypes but unlike incremental
approach here we are not dividing the system into modules and separately prototyping each
module. Instead what we are doing we are creating a prototype for the whole system together and
then we are testing it.

Based on the testing the prototype of the system is altered and this goes on in a cycle and
eventually it becomes the final product. So the evolutionary approach is what immediately comes
to our mind when we think of prototypes to create the full system, test it, refine the system, test it
again and goes on in a cycle till we reach the final product so that is called evolutionary
approach. But that is not the only approach other approaches as we have discussed include
thrown away approach and incremental approach we can choose any of these approaches.
(Refer Slide Time: 48:07)
So with that we come to the end of our discussion on prototypes so here we have learned various
things about prototypes. What is prototype, how it is useful so we have seen that prototypes can
be vertical or horizontal based on what we implement as prototype. We have also seen that
depending on the use of the material and technology we can categorize them as low fidelity
medium fidelity or high fidelity prototypes.

And learned about few of the prototyping techniques such as interface sketches, storyboarding
high fidelity of course provides us the most sophisticated prototypes because they rely on
programs and purely technology oriented. Also we have seen how to make use of the prototypes
once they are built. We can either throw them away after use that is after getting the feedback on
the design idea which is typically the case with low fidelity low cost prototypes.

Or we can keep on using them till they convert to the final product so now this approach can be
done in either of the 2 ways either we can go for incremental approach or we can go for
evolutionary approach. In incremental approach we divide the whole system into units prototype
each unit test each unit separately. And finally integrate them together to get the whole product.

In evolutionary we create the prototype of the whole system itself at the beginning then
incrementally refine them after every testing cycle and finally it leads to the final product. So
that is in a nutshell we also have learned about wizard of oz approach. So that is in a nutshell
what is prototype and how we can make use of prototypes in the interactive system development
lifecycle.

So with that we have finished our discussion on several of the SDLC stages namely requirement
gathering, interface design stage with guidelines and with this lecture on prototyping stage as
well.
(Refer Slide Time: 50:33)

So if we see the life cycle again so we have already covered this stage requirement gathering
stage, design stage. Note here that when we talk of design stage we are referring to 2 types of
design one is interface design one is system design so we have covered so far interface design
stage.And with this lecture we have covered prototyping stage in subsequent lectures we will
take up the other stages namely the quick evaluation of prototype and system design stage. So
that will be the subject matter of our next lecture.
(Refer Slide Time: 51:06)
That is how to evaluate the prototypes that is the other important stage in the design prototype
evaluates cycle which is typically early evaluation of the design idea. So that will cover in the
next lecture whatever we have covered in this lecture.
(Refer Slide Time: 51:23)

Can be found in this book Human Computer Interaction User Centric Computing for Design you
can refer to chapter 2 section 2.4.5. With that we have come to the end of this lecture I hope you
enjoyed the lecture looking forward to see you again in the next lecture thank you and goodbye
you.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Lecture: 16
Prototype Evaluation I

(Refer Slide Time: 00:54)

Hello and welcome to NPTEL MOOC’s course on design and implementation of human
computer interfaces lecture number 15. So, in the earlier lecture we talked about how to create
prototypes. Prototypes are useful for testing design ideas as we have discussed elaborately during
the lecture. Now when we are talking about prototype so, it is basically meant to test our ideas
but testing means we need to evaluate it.

At the same time we have to ensure that whatever methodology we apply for evaluation should
be first we should be able to get the results quickly otherwise that will defeat the purpose why
so?
(Refer Slide Time: 01:41)
Let us try to understand this with respect to the software development life cycle for interactive
systems. So, when we talked about developing a software we also learned about the interactive
system development life cycle. If you may recollect we have talked about requirement gathering
and after that we said that there is One Design prototype evaluate cycle which consists of three
stages design stage, prototyping stage and evaluation stage.

Now here we are specifically focusing on the cycle that means once we get the design done
maybe either based on our intuition or may be using the design guidelines as a starting point or
based on our experience and so on. We express it in the form of prototype and then get it
evaluated. So, that we get to know whether the design suffers from any problem. So, when you
say evaluate it what we are trying to understand?

We are trying to understand whether the design suffers from usability problem because for
interactive systems usability is our main concern. So, we evaluate the prototypes to learn about
issues that may be there with the design. Then based on identification of those issues we go for
refinement of the design again then again we go for prototyping and again we evaluate and this
cycle goes on till we arrive at a design which no longer has significant amount of issues with
respect to usability.
Now typically when we are trying to implement this life cycle typically the design prototype
evaluate cycle takes place frequently and many times the iteration takes place. In other words we
have to be ready to execute this cycle many times. Now if our evaluation takes time then when
we need to do it many times repeatedly then overall cycle time till we arrive at a stable design
increases which is detrimental to the overall turnaround time of the project.

So, our aim should be to have an evaluation method which gives us quick result. Now typically
this evaluation is done at the early stages of design. So, specific and specialized evaluation
methods are there which help us get quick results of evaluation of the prototype just for the sake
of completion. So, once the stable design is arrived at then we go for system design from system
design you go to coding and implementation stage this is followed by code testing.

So, after code testing what we get is an executable system that system we test further with end
users to know about the usability of the final product. So, that is done in this stage empirical
study. Once we are sure that no further usability issues are there or the usability issues are very
few and not significant then we go for deployment and maintenance this is in brief the interactive
system development life cycle.

Out of which we have already talked about requirement gathering design prototyping and in this
lecture we are going to talk about how to quickly evaluate our prototypes.
(Refer Slide Time: 05:37)
So, essentially the topic relates to quick prototype evaluation. So, the word quick is very
significant here and we will see how or what methodology can ensure that the evaluation is done
quickly. Now the quick is a relative term. So, just to put it into perspective to evaluate usability
ideally we should go through rigorous user testing and that is the stage that we just mentioned
empirical study stage where we do this rigorous testing.

Now that rigorous testing takes lot of time and typically that testing is carried out only once or
twice in the life cycle. Whereas the quick evaluation that we do in the early stages in the design
prototype evaluate cycle can be performed many times and it produces results without much
investment in manpower, effort and cost. So, with respect to the empirical study we are saying
that our evaluation method should be quick.
(Refer Slide Time: 06:51)
So, let us now try to understand the evaluation methods that we can use to get quick results after
testing the prototypes. So, now suppose I ask you a question a basic question how do we evaluate
an interface what would be the answer to this question? This is a very basic question which we
should be able to answer before we try to understand what we mean by quick evaluation.
(Refer Slide Time: 07:21)

So, the answer is simple by evaluating usability in our earlier lectures we talked about the idea of
usability there is an ISO standard definition of usability which we have discussed in details. Now
that idea of usability needs to be evaluated or we need to check in our proposed design which is
expressed in the form of a prototype whether the usability idea is present or there are some
deficiencies in the design. So, that usability is affected. So, how do we do that?

There are several methods available the most fundamental method of course is empirical study or
empirical research method where we employ end users a group of end users collect usage data
from them in a controlled setting analyze that data to conclude about the overall usability of a
product. But that as I already mentioned earlier can involve cost and time overrun in the overall
product life cycle if we do it repeatedly.

Because any empirical study involves lots of time lots of effort huge manpower may be resources
so, it is a costly affair. Definitely empirical studies cannot give us quick result. So, we need to go
for some alternatives. So, there are alternative ways to get quick results.
(Refer Slide Time: 09:12)

One such alternative method is called expert evaluation method. Now expert evaluation is used
for quick and cheap evaluation of prototype. Evaluation of what? Evaluation for of prototype and
evaluation for what evaluation for usability? So, expert evolution method is a quick and cheap
method of evaluation of prototypes for usability and such method are typically applied at an
early stage of design rather than after the product is developed.
In order to perform expert evaluation we need two things. So, there are two crucial components
of this study method or the evaluation method or the testing method which we need to have
before we go for expert evaluation.
(Refer Slide Time: 10:06)

One of those things is up prototype. Now we require at least a low fidelity prototype. Recollect
our discussion on prototyping. So, we talked about two types of prototypes one is low fidelity
prototype and the other one is high fidelity in between there is a medium Fidelity which is
nothing but implementation of low fidelity ideas with the help of a computer. For expert
evaluation to take place we require a prototype at least a low fidelity prototype should be
available to let us test the system or let us test the design idea.

So, that is the first requirement along with that we also require an evaluation team. So, generally
it is done by a team rather than a single person. So, we require an evaluation team. Now who can
be team members that is a crucial question we should be aware of. Now the team may consist of
the designers. So, design team can act as testing team or it may include other skilled designers.
So, there may be other persons who are designers themselves.

Designer of the interface skill designer but they need not necessarily be part of the design of the
current interface which we are testing. In addition and optionally few end users may also be
included in the team if available. So, if we find that some end users are available and they can be
included we can include them in the testing team but that is optional not mandatory. The team
should have at least three to five members that is also another requirement.

So, there are two things one is we need to have at least a low fidelity prototype and we need to
have an evaluation team. In the team there can be designers there can be other designers there
can be some end users and at least three to five members.
(Refer Slide Time: 12:34)

Now how the testing takes place each team member evaluates individually and produces a report
it is not a group activity. So, there is a team. Now the Prototype is given to each team member
with certain things along with the Prototype which we will discuss in subsequent part of this
lecture. And each team member individually evaluates the Prototype and produces a report on
various usability aspects of the system or the interface.

So, the report contains a list of usability issues that the evaluator found out. So, each member of
the team produces such a report and all those reports are collected and combined to produce a
final list of usability issues. Once that list is available that is the outcome of the evaluation stage
and based on that final list we go for refinement of the design subsequently prototype the refined
design again we evaluate and so on in this way the cycle takes place.
(Refer Slide Time: 13:52)
So, this broad idea is called expert evaluation. Now why it is called expert evaluation? Because
we are relying on quote unquote experts to get the evaluation done rather than end users. So,
usability as per definition if you recollect the definition as per definition usability is related to the
end users but in these evaluation end users presence is optional as we just mentioned. So, in the
team optionally we can include them we may not include them.

We are relying on the testing by skilled designers who are supposed to be experts in
understanding or in the knowledge of user behaviour. We are assuming that those skill designers
have sufficient knowledge of user behavior to understand from user's point of view the usability
issues and they can produce relevant reports that is why this is called expert evaluation method.
There are several ways in which expert evaluation can take place here in this lecture we are
going to talk about two such methods.
(Refer Slide Time: 15:11)
These two are cognitive walkthrough method and heuristic evaluation method let us start with
cognitive walkthrough method. What it is? How it is done and what it produces let us try to
understand that.
(Refer Slide Time: 15:29)

Broadly cognitive walkthrough method which is a type of expert evaluation method can be
considered to be an usability inspection method. So, essentially this method refers to inspection
of a system for identifying usability issues. What are the requirements for this method? Like the
broad requirements we just discussed for any expert evaluation method here also the same
requirements are there. At least a low fidelity prototype with an additional requirement is that
that the prototype should support several interface level tasks.

In other words we not only require a prototype but the Prototype should be a vertical prototype.
Recollect our discussion on prototype where we said vertical prototypes are those that prototypes
interface state at any instant of interaction as well as the interaction itself. So, essentially the
prototype refers to a set of interfaces each interface refers to a particular stage of interaction and
it also contains the mechanism to change interfaces in other words the mechanism to perform the
interaction.

So, when we are talking of cognitive walkthrough we need to have such prototypes with us and
importantly not only a vertical prototype but many vertical prototypes for the system that means
we should have more than one tasks prototyped and available to us before we go for cognitive
walkthrough method. At least three to five member team should be their evaluation team as we
have already discussed along with the Prototype.

Now here in this team again just to recollect we can include end users if available we can include
other skill designers or only the member of the design team.
(Refer Slide Time: 17:53)
So, how it works those are the requirements based on that requirements how we can perform a
cognitive walkthrough. Let us try to understand this in terms of one example. So, earlier we
talked about a calendar application simple calendar application. So, let us now try to understand
cognitive walkthrough with respect to an interface that we have designed for the calendar
application.

Suppose we have a design for the calendar app in our app we show only the months in the first
screen once the user selects a month by some means either by Mouse click or tap another screen
appears showing the dates or the days in that in that month a user can select any day and add
some note. So, that is the interface that we propose for the simple calendar app. It shows months
at a time once a month is selected it shows days in that month.

And if we choose a date day then in that day we can keep some notables. So, that interface is
available. Now based on this idea of the interface let us try to understand whether this interface
suffers from any usability issue assume that we have prototyped it and we want to test it and we
are applying cognitive walkthrough method for identifying usability issues with this interface.
For that as we just mentioned cognitive work through requires tasks.

So, we assume prototype is available. So, what can be the tasks that a user can do with this
interface. There can be many tasks but in prototype we of course cannot implement all the tasks.
(Refer Slide Time: 20:02)
So, few will select but let us first have a look at different types of tasks that can be done with this
interface user can select a month select a day of a month add note to a particular day of a month
can get back to the month view from the day view and vice versa. So, these are some of the tasks
which are likely to be frequently performed by an end user of the Calendar app.
(Refer Slide Time: 20:26)

Now in order to perform cognitive walkthrough we need to have some prototypes ready in the
Prototype we need to replicate some task scenario and the prototype should support more than
one of these tasks. So, we can create prototypes for multiple tasks that are supported by the
interface. We can make simple paper prototypes for these tasks like we have discussed earlier we
can create storyboards to create a vertical prototype.

So, each prototype is a series of sketches depicting change of screen after each interaction this is
nothing but the idea of storyboarding where each intermediate sketch is called a keyframe.
(Refer Slide Time: 21:28)

Now we first need to before we go for creating a prototype we first need to explicitly describe a
task or rather specify the scenario to perform tasks. Now let us take one example suppose you are
an user of the calendar app and if you recollect the Calendar app when you talked about the
Calendar app we mentioned that it is to be used by either teacher or students in an academic
environment. So, suppose you are a teacher or instructor.

So, you are planning to take a lecture on that subject human computer interaction you want to
schedule a class on the first Monday of the next month that is what you want because you know
that the students are available only on the specific Monday. So, every month first Monday within
a semester the students are available other Mondays they are not available for some reason and
on all the other days of the week they have some other works.

So, they do not have any free slot for you to take the lecture. Now you want to find out the date
so, that you can inform the students about the class. So, you are given the Calendar app your task
is to find out the debt on which the first Monday of the next month falls and once you are able to
identify the debt you can inform the students and additionally you can keep some note on that
date in your Calendar app.
(Refer Slide Time: 23:24)

So, what is your task as a user of the app your task is to identify or determine the date on which
first Monday of the next month Falls. In order to perform this task we need to perform or rather
you need to perform some interface level activities or tasks what are those tasks one is to select
the next month next is locate the first Monday in the month view and the third is Mark the date
by some means along with keeping a note on that particular date regarding the schedule of the
class.

So, these are some activities that that you need to perform with the interface to know about the
date. Now let us see if with the proposed design you perform these activities whether there will
be any usability issues. We want to test for usability of the proposed design with respect to these
tasks using cognitive walkthrough method. So, then in the method what happens.
(Refer Slide Time: 24:37)
This scenario is given to the evaluators that mean each member of the evaluation team this
scenario is given then they are asked to find out the debt by performing the interface level tasks
with the prototype. So, prototype is created to carry out these tasks that means you have a
vertical prototype where screen changes take place by some means of interaction which you
specify indicating the completion of the tasks.

Now, this prototype you give to the evaluators or individual evaluators in the team and ask them
to carry out the tasks in particular carry out the interface level tasks to achieve the overall
objective of identifying the debt.
(Refer Slide Time: 25:36)
Now after giving the tasks to the evaluator so, you have identified the task scenario created
prototype identified the evaluation team and you have given the tasks or whatever prototypes you
have created to each member of the evaluation team to generate usability reports. After that you
also need to do one more step we also need to frame not the word frame you also need to frame a
set of questions which are related to usability issues beforehand.

This is essentially a way to guide the evaluators to identify usability issues. Evaluators are
expected to report on these issues while they perform the tasks. So, as a designer of the test you
are expected to come up with a set of questions each question pertains to some usability aspect of
the interface and your expected to create a list of such questions this list is provided to each of
the evaluators along with the prototype.

So, the evaluators are asked to perform the tasks and at the same time answer those questions
which will bring out the usability issues as perceived by the evaluator. It may be noted here that
each evaluator need not report identical findings. Each of them are free to report as per their
understanding what are the usability issues that is why at the end we need to compile them
together see whether there are duplicate findings or there are unique findings and we have to
identify the unique findings and create the final list.
(Refer Slide Time: 27:34)
So, when we say questions what we mean by that let us try to understand with respect to the
same example. So, in this case for this particular interface what can be the question or what can
be a set of questions that pertains to usability concerns for the interface let us see few of those
questions. One is you able to locate the month you are looking for easily this can be one
question. Next is the interaction required to change from the month view to the day view
apparent.

That means is it easily understandable how to perform the interaction to change from month
view to day view did you find it difficult to locate the first Monday that can be yet another
question. Was the date clearly visible along with the day. So, yet another question did you try to
go back to the month view was the mechanism to go back clearly visible in fact these are two
separate questions for brevity we have shown it together here.

So, these can be some of the questions, so, these questions if you notice carefully these questions
pertain to some aspects of the interface which affects the usability of the product. So, these types
of questions you are expected to frame and provide to the evaluators. Now the evaluators will
perform the tasks with the interface and while performing they will try to answer these questions.
As I have just mentioned earlier it is not necessary that every evaluator reports the same thing.
So, for example for this particular task with the specific interface one evaluator may find that the
second question is the interaction required to change from the month view to the debut apparent
one evaluator may find it not apparent or not very clear whereas two other evaluators may find
them to be apparent or easy to locate or easy to perform. So, there can be variations in the reports
produced by the evaluators.
(Refer Slide Time: 30:09)

There are few more things you should be aware of while trying to perform cognitive work
through. So, the broad purpose of this method is to identify problems users are likely to face. So,
when an evaluator is carrying out the tasks he or she has to assume that he or she is actually
representing a user rather than a skill designer or an expert. And as a user he or she needs to
answer the questions rather than as a skill designer.

So, it is very important that to get appropriate or reliable outcome after the test you choose your
design team your evaluation team very carefully. Second important aspect that should be noted is
that evaluators are not expected to answer only in yes or no. So, if we see the questions are you
able to see this are you able to see that that type of questions are framed. Now evaluators can
simply answer yes or no but that is not the purpose.

Along with yes or no they are supposed to give a detailed report on what they felt about the
interfaces and interactions with respect to each question. So, only yes or no is not very
informative way of testing. Along with that evaluators are expected to give detailed explanation
why they find it apparent or not apparent why they find something easily visible because of what
it may be colour, it may be size, it may be placement.

Or why they do not find it easily visible whether it is because of contrast whether it is because of
small size whether it is because of cluttering. So, that type of reasoning should be provided. Just
to give you an example suppose one button is there to go back to month view from day view.
Now one question is whether that button is easily recognizable. An evaluator may say yes or
evaluator may say no but that is not what we want whenever somebody says yes somebody
means the evaluator says yes why the evaluated thinks it is easily recognizable. Is it because the
size is big is it because the colour is such that the contrast with the background is good. Is it
because the placement is such that it is easily visible?

The possible reason with respect to the questions must be provided by the evaluator according to
his or her understanding. Similarly if the evaluator says no the reason has to be mentioned why it
is not clearly visible is it because of the background foreground contrast is it because of the size
is it because of the placement and so on and so forth. So, answer with explanation is expected
from each evaluator.

Now once all the evaluators submitted their report those are compiled by the lead evaluator or
team lead and analyzed to identify broader unique usability issues which will form the final list
of usability issues based on which the design may be refined or based on which we may decide
not to refine because if the list is very small that means and points to insignificant issues that
indicates that no further changes in the design is required. So, we may stop the cycle otherwise
we may continue with the cycle.
(Refer Slide Time: 34:34)
Some more examples of the questions for both for getting feedback as well as analyzing can be
understood in terms of this example scenario. So, one such question can be is the effect of the
action same as that of the goal of the user at that point this is at a broader level. Will a user see
the control for a particular action. So, these are broad generic type of questions not referring to
any specific system.

These questions can be adapted to specific scenarios as we have just seen, will a user see that the
control produces the desired effect, will user select a different control instead, will a user
understand the feedback provided by the system to proceed correctly what happens in case of an
error. So, whether error is taken care off. How a user who is familiar with other systems that
perform similar tasks is going to react.

So, these questions are slightly different from the questions that we have seen earlier these are
somewhat broader generic type of questions and based on this type of generic questions we can
frame individual list of questionnaire for each task scenario as we have done in the example. So,
that was about cognitive walkthrough which is one of the expert evaluation method. Let us try to
understand another expert evaluation method that is called heuristic evaluation.
(Refer Slide Time: 36:23)
So, we will try to understand what it is how it is done and what we get after the evaluation.
(Refer Slide Time: 36:33)

Now cognitive walkthrough which is one type of expert evaluation is useful definitely in the
early stages of design. So, it can be used definitely for quick evaluation of prototypes because it
does not require end users and it can be done with the design team skill designers to get the
feedback about prototypes. But there is one problem the method is scenario based that means we
evaluate with respect to specific usage scenarios.
Now for simple systems that is fine. For complex systems there are likely to be numerous usage
scenarios and we definitely cannot evaluate with respect to all. So, if we are dealing with simple
interfaces then usage scenarios are limited one or two and we can create prototypes for those
usage scenarios as we have seen in the example and those prototypes can be used vertical
prototypes which can be used to perform cognitive walkthrough.

But for more complex systems usage scenarios are likely to be numerous and in that case we
cannot perform cognitive work through to test prototypes for each possible usage scenario. Now
if we miss out some scenarios then we do not know whether there are usability issues related to
those scenarios that knowledge will never gain.
(Refer Slide Time: 38:16)

Now why we are unable to test for all usage scenarios in complex systems? So, there are
primarily two reasons one is we may not have that much time. So, if there are large number of
scenarios then even if we apply cognitive work through it will take long time to test each and
every scenario and that much time will defeat the whole purpose of quick evaluation. Secondly
which is more likely case we may not even be able to enumerate all possible you said scenarios.

So, in complex systems it is generally very difficult to identify all possible usage scenarios in
advance. So, we will not be able to enable it and then if we are unable to enumerate we will not
be able to prototype also and even if we are able to enumerate and prototype time may not be
there to perform cognitive walkthrough for all the possible usage scenarios.
(Refer Slide Time: 39:13)

There can be one way to address this concern that is instead of trying to enumerate and prototype
all usage scenarios we can work with representative use cases. What is a representative use case.
So, if there are large number of use cases it is not necessary that in real life situation all the use
cases are frequently performed. Instead most likely very small subset of the use cases are
frequently performed and our objective is to identify that small set of use cases which are
frequently performed.

That small set is the representative use case or use cases that are likely to represent real world
usage of the product. But this is easier said than done it is very difficult to identify in advance
when the product is not ready and used very difficult to identify what constitutes the
representative use cases. So, if we are able to identify then since the number is small we can
prototype and go for cognitive evaluation but it is not easy to identify representative use cases.

So, we have to go for all possible use cases which is time consuming and which may not be
possible either.
(Refer Slide Time: 40:40)
 In order to address this concern that is there with cognitive walkthrough method we can use
another approach. Now in case of cognitive walkthrough we are relying on task scenario. So, this
is Task Centric approach instead what we can do is instead of trying to evaluate usability with
respect to tasks in a Task Centric approach what we can try to do is, we can discard the task
Centric approach we no longer require tasks to be identified and usabilities is identified based on
the performance in the tasks.

What we can do we can go for comprehensive evaluation of the whole system without bothering
about task scenarios or tasks to be performed with the system. So, we no longer need to create
scenarios and ask evaluators to perform the tasks. Instead what we can do we can ask evaluators
to tick or select on a checklist of features of the system as a whole. So, the idea is very simple. In
cognitive walkthrough what we had is some task scenarios.

Now here we are not having those task scenarios instead we are having a checklist, checklist of
system features that are identified in advance which are related to usability of the interface. So,
an evaluator will be asked to take the interface prototype and tick in the checklist whichever of
the features the prototype supports that is the basic idea.
(Refer Slide Time: 42:23)
Now when we follow this idea this is called heuristic evaluation. The checklist is nothing but a
set of heuristics that we assume to represent usability of the interface or usability aspects of the
interface. So, the items in the checklist are called heuristics and these heuristics are used to
evaluate the overall system irrespective of tasks.
(Refer Slide Time: 42:53)

Like design guidelines which we have discussed earlier for heuristic evaluation also many such
checklists are available some are quite detailed and system specific similar to design guidelines
but there are some that are more focused on broader principles of usability. So, like design
guidelines we have detailed checklist which are likely to be system specific and broader
checklists where the heuristics in the checklist refer to broader usability aspects of the system.

So, evidently in that case the number of heuristics will be much less compared to detailed
checklists.
(Refer Slide Time: 43:38)

In order to understand the idea of heuristic evaluation let us see one such checklist or heuristics
which is a broader set of heuristics. This is a very popular checklist as well the 10 heuristics by
Nielsen proposed in 1994.
(Refer Slide Time: 44:01)
So, there are 10 such heuristics or items in the checklist. First heuristic says visibility of system
status whether status of the system at any instant of interaction is clearly visible to the user.
Second heuristic it talks about match between system and the real world. Whether the actions
and elements present on the interface have matches with our day to day experience in the outside
world then heuristic 3 talks about user control and freedom how the control and freedom
perceived by the user.

Forth heuristic it talks about consistency and standards. So, whether the; design follows
consistency and follow standards that is the fourth heuristics. Fifth heuristics is regarding error
prevention whether the design that we are evaluating supports or Aids error prevention. Heuristic
6 talks about recognition rather than recall that means whether it supports the; user to recognize
items on the screen rather than forcing the user to recall from memory before he or she can use
the interface.

Heuristic 7 talks about flexibility and efficiency of use whether these are supported by the
design. The eighth heuristic talks about aesthetic and minimalist design whether the design that
we are evaluating is aesthetically pleasing and it contains minimum number of elements as well
as minimum number of interactions to achieve tasks goals. The ninth heuristic talks about
whether the system helps users recognize diagnose and recover from errors and the tenth at the
final heuristic talks about whether the system supports help and documentation.
So, these heuristics as you can see lists some aspects of the design which are related to usability
for example recognition rather than recall. So, see this can be related to the Golden Rule of
Snyderman where it was mentioned that the 7 plus minus 2 rule was mentioned that means if the
user is forced to recall sequences or meaning of items if the number of recalls or the amount of
recall is large then of course that will exceed our short term memory capacity and that will be
difficult for the user to perform.

So, eventually the interaction will not be usable whereas if user is able to recognize actions and
items by the very design of the interface then the memory constraint is taken care of. So, a design
that supports recognition rather than recall is more usable than the opposite thing. So, what the
evaluator needs to do evaluator we will get this list and a prototype.
(Refer Slide Time: 47:55)

Now unlike cognitive walkthrough in case of heuristic evaluation we require low fidelity
prototype which can be a horizontal prototype because here we are not relying on tasks. So,
execution sequence is not important rather the elements present are more important. However
vertical prototypes can also be used to see the nature of interaction as well with respect to the
checklist. But even if we have a vertical prototype we do not need to specify any specific tasks
scenario.
So, for vertical prototype task scenarios need not be specified anything is fine but typically
heuristic evaluation is used for horizontal prototypes. This is in contrast to cognitive walkthrough
method where we rely mostly on vertical prototypes.
(Refer Slide Time: 48:51)

And like the other method we also need a team of evaluators. Now the team should contain at
least between three to five members that is the same as before. Now these team members can be
the designers or other expert designers or even end users along with the expert designers. So, this
point is very important. So, the evaluation team should not be only end users at this stage there
should be few skilled designers as experts in the team so, that we can get some expert feedback
along with simple Yes, No type feedback.

Now here as we said evaluation process is slightly different. So, we no longer require the task
scenario each evaluator checks the design or the prototype with respect to the heuristics and
report their findings. Now reporting here again is not simple Yes, No yype like in cognitive
walkthrough. So, even if suppose one item says that whether the design supports error prevention
if the evaluator simply say yes then that will not be very revealing rather the evaluator should say
why he or she thinks that the design supports error prevention.

What are the features present on the system or the design that supports error prevention that
detailing is required like in case of cognitive walkthrough. And once all the evaluators submitted
their reports those reports are combined to determine heuristics that are violated this is very
important. So, where the end result is identification of heuristics that are violated by the design
as reported by the majority or all the evaluators.

So, it may happen that one evaluator said it is violated but majority side it is not violated then we
will consider it to be not violated. So, in majority things that particular heuristic is violated we
will consider it to be violated and those violated heuristics are considered while refining the
interface or while refining the interface design. So, that is in a nutshell what is heuristic
evaluation.

With that we have come to the end of this lecture here we learned about quick evaluation
technique for evaluating design ideas which are prototyped. Just to quickly recap here we talked
about expert evaluation technique. Now in expert evaluation we require a prototype and an
evaluation team consisting of at least three to five members. Now the team members can be
designed team members or other skilled designers.

And additionally and optionally in this team you can include end users if available. We have
talked about two expert evaluation techniques one is cognitive walkthrough and one is heuristic
evaluation. These two techniques are different in terms of their approach to the evaluation
process. In cognitive walkthrough what we do is we perform the evaluation based on tasks task
scenarios accordingly vertical prototypes are created.

Prototypes along with a set of questions are provided to each evaluators. Evaluators carry out the
task and answers the questions in detail and submit and at the end all the reports collected from
the evaluators are combined to identify usability issues. In contrast in heuristic evaluation we do
not have any questions or a task instead what we have is a checklist or set of heuristics and a
prototype typically horizontal prototype.

So, each evaluator is given a horizontal prototype and the checklist they report their findings
based on the checklist detailed report like cognitive walkthrough at the end those are combined
to identify which of the heuristics are reported to be violated by the design and accordingly the
design is refined that is the basic idea. So, this is one way of performing quick evaluation of the
prototypes. In the next lecture we will talk about another way of weak evaluation technique
involving end users.
(Refer Slide Time: 54:01)

That is all for this lecture whatever material I have covered can be found in this book your
requested to refer to chapter 9 section 9.1 to 9.2 both the sections you can refer to, to learn about
these methods that we have covered in this lecture. Hope you have enjoyed the topic and looking
forward to meet you in the next lecture, thank you and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Lecture: 17
Prototype Evaluation II

Hello and welcome to the NPTEL MOOC’s course on design and implementation of human
computer interfaces lecture number 16 where we will continue our discussion on evaluation of
prototypes. So, in the previous lecture we started our discussion on how to evaluate prototypes.
So, the constraint that we have is that once a prototype is created it has to be evaluated quickly.
Here we are assuming that the design building of prototype and evaluation of prototype forms a
cycle.

And this cycle repeats frequently in the early stages of design till we arrive at a design which is
having very less significant amount of usability issues so it is very important to be able to
evaluate the prototypes quickly and rapidly. In the earlier lecture we have discussed about
specific methods of evaluations in particular we learned about expert evaluation methods two
methods we discussed one is cognitive walk through other one is heuristic evaluation.
(Refer Slide Time: 02:12)

In this lecture we will continue our discussion on how to quickly evaluate prototypes. So, today
we are going to start our discussion on another way of evaluating prototypes rapidly which is
user evaluation. So, here we will be discussing methods to involve end users in rapid evaluation
of prototype. Recollect that in our earlier discussion on prototype evaluation we said that it is
expert evaluation that means end users involvement is not necessary.

Although optionally they may be added in the evaluation team however today what we are going
to discuss in this lecture is based on user evaluation. Now generally evaluating prototypes or any
systems with users is time consuming process involving elaborate setup detailed data collection
and analysis methods which entails cost and time. However there are ways to quickly evaluate
systems or prototypes with users although the outcome will not be as robust as what we will get
if we follow a rigorous evaluation method.

But still in the early phase of design such a quick evaluation would be beneficial. So, let us see
how we can do that.
(Refer Slide Time: 03:41)

So, with expert evaluation that we have discussed earlier we rely on data provided by those who
are not likely to be the users of the system. Now, that is one thing that we emphasize that expert
evaluation primarily relies on expertise or domain expertise of evaluators. Now in the early
phases we make use of that which can be considered to be a replacement of evaluation by end
users.
However if it is possible to involve end users then we are likely to get more insight about
usability issues of a particular product from the data collected from such users.But we have to do
it in a rapid fashion.
(Refer Slide Time: 04:33)

Now one way to do that as we mentioned as one stage of the interactive system development life
cycle one way to do that is through empirical studies. Now that is actually a very rigorous
process and we will learn it in more details in a later lecture. This involves as I said elaborate
setup and expertise, expertise of the experimenter as well as expertise for analysis of data to
collect and analyze data which is not an easy thing to do and it takes time.
(Refer Slide Time: 05:15)
Now there is another way to collect end user feedback on a design which is much less complex
and here we can get feedback from users by asking them questions directly. So, you ask some
questions and answer to those questions are likely to give you some feedback about your design
idea this is called evaluation with self reports. So, this is the method that we are going to discuss
in this lecture.
(Refer Slide Time: 05:56)

The data that we can collect through this method can sometimes be called subjective or
preference data that is another way of referring to the data that we collect through this method.
(Refer Slide Time: 06:14)
Now let us learn in details what is evaluation with self reports.
(Refer Slide Time: 06:20)

Now when we want to get some data about usability issues of a product how we can get the
feedback from end users. So, there are different ways possible. We can ask the users to provide
some rating on a scale a rating scale a typical example is a Likart scale for providing feedback.
We can ask them to choose from a list of system attributes and ask for their feedback about those
attributes. Also, we can ask them direct open-ended questions such as what you feel about the
system. So, there are different ways to get the feedback.
(Refer Slide Time: 07:09)
Now which way we should use? Intuitively it may seem very easy to do if we simply ask them
about their feedback through open-ended questions like what you think about the system how do
you feel about the system do you think there are some issues and similar such open-ended
questions but as you can understand if I simply ask some user to give feedback based on
open-ended questions.

The results will not be very reliable because at that point of time when the user is providing the
feedback several things influences the answer including prior exposure to the system mood of the
user at that point of time so on and so forth. Now there is no way to actually analyze objectively
the reliability of the answers based on open-ended questions. In contrast if we try to take
feedback based on rating scales such as a Likart scale then these type of feedbacks are generally
considered to be more efficient and reliable.

So, instead of going to collect feedback based on open-ended questions ideally we should aim for
collecting such feedbacks using some sort of rating skills such as a Likart scale.
(Refer Slide Time: 08:50)
But that is also not easy. So, when we are planning to collect feedback using a rating scale it is
not an easy thing to do there are broadly two issues involved here what are those issues.
(Refer Slide Time: 09:05)

So, when you say we want to collect rating about some interface or rather design of some
interface how do we do that we collect it based on some questions. These are generally called
items which are typically can be in the form of a question or in the form of statements. For
example there can be a statement about some design that the controls are easily accessible. Now
on this statement we may ask the end users to provide some rating on a three point Likart scale.
Where one may refer to highly agree two may refer to neutral and three may effort to disagree.
So, this type of statements can be used to collect the rating. So, what it indicates it indicates that
there is a prerequisite before we go for using some rating scale based feedback mechanism. Here
what we need we first need to identify the items. Now these items can be in the form of questions
or statements as I just mentioned.

However when we have a set of such items this is typically referred to as a questionnaire
although it need not contain questions it can be a set of statements but the general term used is
questionnaire or items. So, it is very challenging to identify suitable questionnaire to collect the
feedback that is one of the major issues in rating based feedback mechanism.
(Refer Slide Time: 10:59)

There is another issue when we ask for feedback we assume user is already exposed to the
system otherwise the user will not be able to provide the ratings on the items in the
questionnaire. Now how we can make it possible how the user can be exposed to the system she
or he may be asked to use the system before feedback like in a controlled study. So, we can set
up a controlled study and ask the users to use the system in that controlled environment.

And typically what happens in such studies is that users are typically asked to perform a set of
tasks. So, a set of tasks is provided to the users and they are asked to perform those tasks using
the system in the controlled environment. So, that is generally how we can expose the user to the
system.
(Refer Slide Time: 12:13)

Now there are two points where we can collect feedback one is after every task remember that in
a controlled experiment we ask the user to perform a set of tasks. So, after every task we may try
to get the feedback of the user about the system or after all the tasks are performed which is
generally called a session at the end of the session we can try to get the feedback. Now if we
decide to collect feedback at one point and ignore the other point that is generally not very
advisable thing unless there is some real problem in collecting data.

So, it is desirable to collect data at both the points after each task and at the end of the session but
when we are using questionnaires to collect feedback. The questionnaire for getting feedback
after each task and the questionnaire for getting feedback after the whole session need not be the
same. So, there may be differences corresponding questionnaire may not be the same that we
have to keep in mind so accordingly we have to design the questionnaire.
(Refer Slide Time: 13:30)
Now which one is better is it advisable to go for collecting feedback after each task or after each
session. So, let us try to quickly compare these two data collection points one is post session
versus post data feedback. So, if we collect feedback after each task we are likely to pinpoint
problems with respect to specific tasks and parts of the interface used to carry out the task
because users are likely to remember problems better just after each task.

So, if we have faced any issue while using the system for carrying out a specific task that issue is
likely to be remembered by us and expressed by us if we are asked to provide feedback just after
the task is completed. Instead if we are asked to provide feedback after end of all the tasks then it
is possible that we may forget some of the issues that we have encountered during tasks that have
been performed earlier.

So, this is the advantage of post task feedback over post session feedback but this approach may
not be possible always.
(Refer Slide Time: 14:58)
With post session feedback what we gain we are more likely to learn about user perception on
overall system. So, after each task if we are taking feedback then we are likely to get issues
related to execution of that task with the specific parts of the interface which were required to
carry out the task. However it will not give us an overall idea of what are the issues. Whereas if
we are collecting feedback after the entire session is over that means all the tasks are carried out
then it is more likely that we will get user feedback on general issues related to usability.

So, we are likely to get general perception of the user about the overall system rather than only
parts of the systems involved in specific tasks. Now it may not be possible to relate that
perception with specific task or components of the interface. So, post session feedback need not
be related to whatever we experienced after each task.
(Refer Slide Time: 16:25)
Now as I mentioned earlier so when we are trying to take feedback after each task vis-a-vis when
we are trying to take feedback after the entire session or all the tasks performed we need to have
different questionnaires same questionnaire will not work in both the situations in most cases.
Accordingly different questionnaires have been developed over time to collect feedback at these
different points of interaction with the system post task and post session.

So, let us quickly learn about few such questionnaires for different feedback for post task
questionnaire several popular questionnaires are available like After Scenario Questionnaire or
ASQ proposed by Lewis in 1991, Expectation Measure proposed by Albert and Dixon in 2003.
So, these two are quite popular questionnaires meant for collecting feedback post task. Similarly
there are several popular questionnaires designed to collect feedback post session which include
system usability scale or SUQs questionnaire proposed by Brook way back in 1996.

Computer system usability questionnaire or CSUQ proposed by Lewis in 1995, Questionnaire

For User Interface Satisfaction or QUIS Chin et al proposed this in 1988, Usefulness Satisfaction
and Ease of Use Questionnaire abbreviated as USE proposed by Lund in 2001. As you can see
all of these are quite old primarily meant to collect feedback about GUIs mostly. And these are
quite popular questionnaires still in use for collecting feedback at different points of interaction
post task or post session.
(Refer Slide Time: 18:53)
Let us now try to understand each of these questionnaires with examples from each of these set
of standard and popular questionnaires. So, we will start with post task questionnaire and the
example that we are going to use is ASQ.
(Refer Slide Time: 19:13)

Now ASQ as I just mentioned ASQ is one questionnaire designed to collect user feedback after
each task is carried out in a controlled experiment. Now ASQ contains three statements users are
asked to provide rating on a seven point rating scale for each statement. So, there are three
statements and on each statement users are expected to provide a rating on a seven point rating
scale. Now ratings range from strongly disagree which is the rating of one to strongly agree
which is the highest rating of seven.

So, after every task user has to fill up the ratings for each question where the ratings vary from
strongly agree to strongly disagree. The lowest rating value one indicates strongly disagree and
the highest value indicates strongly agree.
(Refer Slide Time: 20:25)

So, what are the questions. So, there are three items or statements in the questionnaire item
number one I am satisfied with the ease of completing the tasks in this scenario. So, a task is
performed by the user following a task scenario and user has to provide rating for this statement
or item which is I am satisfied with the ease of completing the tasks in this scenario. Then
second one is I am satisfied with the amount of time it took to complete the tasks in this scenario.

Again here the user is expected to provide a rating in the seven point rating scale for this item
after the task is completed. Then the third item in the questionnaire is I am satisfied with the
support information which includes online help messages documentation when completing the
tasks. So, this item also needs to be rated in that 7 point rating scale by the user after the task is
complete. So, the user is given a task and then asked to provide ratings for all these questions or
items these are basically statements rather than questions.
So, it is better to call them items but the whole set of three items we can call questionnaire using
the standard terminology. Just to repeat statement one or item one is I am satisfied with the ease
of completing the tasks in this scenario. Then item number two I am satisfied with the amount of
time it took to complete the tasks in this scenario. And item number three I am satisfied with the
support information when completing the tasks where the support information include online
help messages and documentation.
(Refer Slide Time: 22:30)

As you can see from the questionnaire or rather the items in the questionnaire it is simple so the
questionnaire is designed to collect quick feedback and this is suitable because we are supposed
to collect feedback multiple times in the early phase of design. So, this questionnaire along with
this method supports that idea. Now let us try to understand how the feedback provided by rating
on these three items can be related to the idea of usability and usability issues.

So, when we discussed usability if you may recollect we mentioned three things as per ISO
standard definition of usability these are effectiveness, efficiency and satisfaction.
(Refer Slide Time: 23:28)
First statement in the ASQ questionnaire is related to the effectiveness measure that we have
mentioned in the definition of usability. Efficiency aspect is covered in the second statement if
you look at the statements closely and all the three statements taken together represents
satisfaction. So, the ratings for all the three statements together represent satisfaction whereas
fast statement refers to effectiveness and second one is refers to efficiency.
(Refer Slide Time: 24:01)

So, how we can make use of the feedback or the ratings that we get from the users. So, we can
actually take an average rating for each statement. Suppose we are collecting the rating from five
end users after they were asked to perform some tasks using our proposed design of the interface.
Now to perform the tasks it is not necessary to implement the interface rather some prototypes
are fine and the task scenario needs to be mentioned the way we did it in cognitive walkthrough.

But now here instead of expert evaluators we have end users to evaluate the interfaces. So, now
after each task is performed we can use the questionnaire to get the ratings and once we collect
ratings from all the five users we can take average rating for each item or we can take average
rating for all the statements taken together either of these are fine. And based on the average
rating we can take a decision.

For example suppose the rating is closer to one that means users are mostly disagree with the
statements in that case there are likely to be usability issues and we need to revise the design. If
the average ratings are closer to 7 which is the highest rating then probably issues are less and no
need to refine the design further that can be one of the way to conclude from the data that we
collect. So, that is about post task questionnaire.
(Refer Slide Time: 25:56)

Now let us try to understand post session feedback collection using questionnaire with respect to
one example here we will be using the example of system usability scale or SUS questionnaire.
(Refer Slide Time: 26:02)
Now SUS questionnaire consists of 10 statements. Again here we are using the term statement
rather than questions because these are in the form of statements. One interesting thing is that
half of these statements are positively worded and the other half are negatively worded. So,
statement number 1, 3, 5, 7 and 9 odd number statements are positively voted and even number
statements 2, 4, 6, 8 and 10 are negatively worded. Let us have a look at these statements.
(Refer Slide Time: 26:41)

Statement number one I think that I would like to use this system frequently. As you can see this
is positively worded statement. So, one is positively worded. Statement number two says I found
the system unnecessarily complex again this is a negatively worded statement. Statement number
three I thought the system was easy to use another example of a positively worded statement.
Statement 4 I think I would need the support of a technical person to be able to use the system
this is a negatively worded statement.

Statement 5 I found the various functions in this system were well integrated as you can see this
is another positively worded statement. Six says I thought the system was too inconsistent
example of negatively worded statement. Seven I would imagine that most people would learn to
use the system very quickly a positively worded statement. Eight is I found the system very
cumbersome to use a negatively worded statement.

Statement nine I felt very confident using the system again a positively added statement whereas
statement 10 says I needed to learn a lot of things before I could get going with this system
which is a negatively worded statement. So, here as we just have seen the odd number statements
namely 1 3 5 7 9 are positively worded whereas even number statements 2 4 6 8 and 10 are
negatively worded together they constitute the SUS questionnaire having these 10 items.
(Refer Slide Time: 29:05)

So, what to do with these items? So, post session the questionnaire is given to the users and they
are asked to provide rating for each statement on a five point agreement scale which is a Likart
scale where one indicates strongly disagree and five indicates strongly agree. So, for each item
the user has to provide feedback in the form of ratings in a five point agreement scale where 1
indicates strongly disagree and 5 indicates strongly agree.
(Refer Slide Time: 29:45)

Unlike in the case of ASQ here combining these ratings is slightly different. So, we need to
combine the ratings for all the 10 statements to obtain an overall SUS score which is a tricky
appear it is not as simple as simply taking an average which we did in the case of the earlier one.
(Refer Slide Time: 30:13)

So, how do we perform the combination? We first sum up the contribution let us call it C for
each statement to get overall score S. Now this contribution from each statement is an integer
which lies between the value 0 and 4, two components are there to calculate individual statement
contributions.
(Refer Slide Time: 30:50)

For positively worded statements that is statements which are odd numbered the individual
contribution for each statement is calculated as the rating obtained minus 1. So, it is R minus 1.
So, if the user provides some rating for that statement we deduct 1 from it to get the individual
contribution. For negatively worded statements the contribution is calculated as 5 minus the
rating. So, here it is 5 minus R.

So, whatever ratings the users provided for the negatively worded items or statements that is the
items which are even numbered we basically calculate the individual contribution for that
particular statement by subtracting the rating from 5.
(Refer Slide Time: 31:47)
And then we sum up these contributions as mentioned earlier. So, total SUV score is calculated
as summation for individual contributions by all the positively worded statements that is even
number statements R i - i where i varies from 1 3 5 7 9 within this set and contribution for the
statements which are negatively worded 5 minus R i where i varies between these numbers 2 4 6
8 and 10. Now we sum it up together all the 10 contributions and then multiply with a factor 2.5.

R i here indicates the rating for the ith statement and individual cases accordingly we vary i. So,
after multiplication the number that we get is the SUS score.
(Refer Slide Time: 32:54)
Let us try to understand it with an example. Suppose for statement one in a given situation where
the user was asked to use some particular interface design and provide the ratings the users have
provided the following ratings. For statement 1 rating is 5 for statement 2 rating is 4 for
statement 3 rating is 2 statement 4 rating one statement 5 rating 2 statement 6 rating 3 statement
7 again rating 2 statement 8 rating 4statement 9 rating 5 and statement 10 rating 2.

Now these ratings are provided by an user for a given design on the basis of the SUS
questionnaires. So, we now need to combine these ratings to get the SUS score for that particular
user.
(Refer Slide Time: 33:59)

So, there are two components we first have to combine ratings for positively worded statements
to get the contributions from those statements. So, it will be five minus one plus two minus one
plus two minus one plus two minus one plus five minus one or eleven. Then we have to combine
for negatively varied statements five minus rating that is five minus four five minus one five
minus three five minus four and five minus two this also and then we add them together.

So, this also results in the number eleven then we sum these two components. So, we get eleven
plus eleven that is 22 and then we get the overall score by multiplying the sum with the factor 2.5
to get 55.
(Refer Slide Time: 34:55)
So, how to interpret this number so, we got a score 55. So, what it means we can interpret this
core as a percentage. So, we can say that the score in the example is 55%. So, we got the number
55. So, we can say that SUS score is 55%. It is generally assumed based on several studies that
an SUS score around 70% or more is desirable for a system or an interface design to be
considered not having significant usability issues.

If SUS score is found out to be less than 70% then there are likely to be some usability issues and
it is better to redesign the interface. So, scores lower than the 70 percentage point might indicate
usability problems and it is preferable to revise or refine such designs. So, that is how we can
make use of the SUS score. So, that is what we can do with user based quick evaluation. Here we
have seen two methods.

So, the basic setup remains the same as in the case of expert evaluation. So, we have some tasks
and prototypes to carry out the tasks preferably vertical prototype here. So, that tasks can be
carried out then what we can do is we can collect feedback using rating scales from the users
after they were asked to perform those tasks in a controlled setting using the prototypes. So,
unlike in the expert evaluation method here the feedback is collected using rating skills.

So, we have two types of questionnaires to collect feedbacks from two points one is after each
task is carried out and second is after all the tasks are carried out that means at the end of the
session. ASQ is one example questionnaire that we have discussed to collect feedback after each
task and SUS is one example questionnaire that we have discussed to collect feedback after the
whole session. As we have discussed each of these methods has its own positive and negative
sides.

Post task questionnaire is likely to reveal more about the specific components of the interface
that has been used to carry out the task. Whereas post session questionnaire is likely to reveal
more about the general perception of the user about the whole system rather than task specific
perception it is preferable to use both as much as possible. So, that is what we can do to quickly
evaluate prototype with end users note that the requirement that the evaluation takes place in a
rapid manner is very important and these self reporting methods can satisfy that requirement with
that we end the topic here.
(Refer Slide Time: 38:26)

So, whatever I have discussed can be found in this book human computer interaction you are
requested to refer to chapter 9 section 9.3 to know in details about these methods. I hope you
have enjoyed the content and I am looking forward to meet you all in the next lecture, thank you
and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Lecture: 18
Case Study on Prototype Evaluation - I

Hello and welcome to the NPTEL MOOCs course on design and implementation of human
computer interfaces lecture number 17 where we are going to discuss about case studies on
prototype building and evaluation.
(Refer Slide Time: 00:57)

So, before we start let us quickly recap what we have learnt. So, far earlier we learned about
prototypes namely what is a prototype and we learned about different prototypes also we learned
about how to make prototypes and the different prototypes that we can make all these things we
have learned in the earlier lectures that is one side that is what are prototypes and how to make
them.
(Refer Slide Time: 01:25)
We have also learned how to evaluate the prototypes in the design prototype evaluate cycle we
need to build as well as evaluate the prototype. So, we have learnt 2 techniques for evaluation of
prototypes rather quick evaluation of prototypes one is cognitive walkthrough and the other one
is heuristic evaluation. I hope you can remember these techniques and in this lecture we are
going to see how the prototypes can be built and how it can be evaluated using these techniques.
(Refer Slide Time: 02:00)

So, we will specifically learn about building of prototypes and evaluation of those prototypes
using a case study. So, that is our objective for this lecture.
(Refer Slide Time: 02:13)
Before we go into the content let us quickly understand the case. So, we have already mentioned
it before this is about the calendar app which we have introduced earlier. if you may recollect we
are interested to build a calendar app it is meant for the students primarily for the students to help
in their various academic activities. Now that is the requirement stated in a very broad manner
and we have seen earlier how to gather the functional requirements for this calendar app and how
to represent them in a hierarchical manner.
(Refer Slide Time: 03:01)

Let us quickly recollect the functional requirement hierarchy for this calendar app. We need that
because what we have mentioned earlier is SRS or the software requirement specification
document is the starting point for design of the code as well as the interface. So, here our concern
is to get the interface designed and evaluated rather than the code and for that also we will use
the SRS document as the starting point to come up with an interface design that will support the
functional requirements that are specified in the SRS document. So, let us quickly recap the SRS
document for the calendar app that we have earlier gone through.
(Refer Slide Time: 03:43)

Particularly in lecture number 8 in the third week we have gone through this SRS document.
Now the SRS document contains several functional requirements arranged in the form of a
hierarchy the top level functions are there for example display calendar is one top level functions
under which there are 3 sub functions display months display days with events and specific date
view these are 3 sub functions under display calendar function at the top level.

Another top level function is set reminders here again there are 3 sub functions create reminders
edit reminders and delete reminders. Then we have a third top level function set background
under which there are 2 sub functions set theme and reset theme. We have a 4th top level
function synchronize under which we have attach account and remove account these 2
subfunction.
So, this is the functional hierarchy which we converted to the SRS document and which will be
the starting point of our interface design that means we are going to design an interface that will
support these functions.
(Refer Slide Time: 05:15)

So, first we will talk about building the prototype and getting it evaluated with the cognitive
walk through method. So, let us first see how we can build the prototype and how it looks. So, to
perform cognitive walk through if you recollect we need at least a medium fidelity prototype or
high fidelity prototype. In fact low fidelity can also work provided we design it in an appropriate
manner however it should be a vertical prototype that is the important concern here.
(Refer Slide Time: 05:47)
So, we need to create a vertical prototype and this prototype that we are going to discuss has
been created with a tool called figma this is an online tool that you can also use to create
prototypes.
(Refer Slide Time: 06:05)

Now the prototype has several of the functions not all functions are being discussed here.
Namely months in a year days in a month specific date set reminder edit reminder delete
reminder set theme where you can select the theme and after theme is applied those views those
things we have prototyped. Remember that here in this case study we are not designing a
prototype that supports all the functions that are present in the functional hierarchy a few
functions are left out particularly synchronization.
(Refer Slide Time: 06:45)

So, let us first quickly go through the interface how it looks like once the SRS is prototyped first
we will see how the months in a year looks like when it appears on the interface. So, there are
this 3 year-wise views are given say for 2 entry 21 we get to see January February March in this
way similarly for 2020 to 2023. So, essentially it will be in the form of a matrix. For each year
the months are shown in this manner.

So, it is a 3 by 4 matrix where there are 3 columns and 4 rows and the months along with the
days in the month are arranged in this matrix form as shown in the view. Now this view is what
we have prototyped to demonstrate the view of the months in a year.
(Refer Slide Time: 07:58)
Next if we want to see the days in a month. So, in the earlier view those dates or days were
shown in a very small manner which may not be properly visible. So, we want to enlarge it and
see it in that case we can get a view like this. Remember that here we are not concerned about
how we get this view only thing is this is the view for days in a month it can appear through tap
it can appear through touch it can appear through strike or finger stroke.

Any interaction is fine or mouse click but we are more concerned about the view rather than the
actual interaction. So, for example if we want to see a month say March 2022 or say April 2022
this is the kind of view that we will get where the days of the week are shown here Monday
Tuesday Wednesday Thursday Friday Saturday Sunday and then we get to see the dates or the
days in the month.

So, for example march 2022 starts from a Saturday and up to 31st of the month and additionally
with each day we can display certain events along with it in the way shown here. So, that is the
view that we want to create for our system.
(Refer Slide Time: 09:31)
Now there is this specific date view. So, that is about the earlier view was about seeing all the
days in a month. Now a specific day I want to see in details. So, then what kind of interface will
appear what is our design that can be seen here in the form of this prototype for specific date
views. So, for example 13th March 2022 it shows the events that are listed on this date software
engineering CS506 some discussion some other topics along with time of the event project
discussion along with time of the event.

So, this is all events view. Now in the bottom side as you can see we have different options time
tables deadlines meetings. Now if we select time table then we will get a timetable view where
only the classes will be shown that are there on that particular date software engineering ml high
performance computing along with the class timings. So, here these other discussions like shown
here in the under the all events view will not be shown.

So, this is what the specific date views look like and this is what we intend to design for the
system.
(Refer Slide Time: 11:05)
We can also have deadline view like a specific event deadline is there with the time or we can
have meeting view. So, all the meetings will be listed under this view for a specific date. So, for
a specific date either we can see all the events or we can see specific events like time table
deadlines meetings and so on.
(Refer Slide Time: 11:30)

Next is the view for setting of reminders. So, for a specific date say 18th March there are some
events and for some event we may set a reminder. So, this can be the place or this is the place in
our design using which we can set the reminder. So, if we select this option plus then this screen
will appear set reminder screen where you need to put some description and select the type with
the timetable deadline or meeting and the reminder and the event duration and then it will be
saved.

So, there is this save option provided here. So, you can use the save option and then this
reminder will appear with the event for that specific date as shown here. So, after save option is
selected then the reminder appeared. We can also get a similar interface to edit the reminder the
interface looks similar and there we can edit this reminder start and end times and save it.
(Refer Slide Time: 13:01)

We can also delete a reminder with this delete option the interface more or less looks similar.
(Refer Slide Time: 13:14)
The next function that we prototyped is select theme. So, this is the view that we get to see when
the select theme functionality is executed with the system. So, we have to remember here that by
the use of the term view what we are referring to is that this is how the interface will look like if
the system is implemented and this is what the user gets to see. So, there is this theme option
present. Now once this is selected then different themes appear here.

So, this is the theme window here with this boundary. So, this is the window that appears having
different themes like dark mode clouds geometrical floral and from here we can select a theme
then once the theme is selected then we get theme applied view. So, if we have selected a
specific cloud theme then it looks something like this or if you have selected dark mode then it
looks something like this and so on.

So, with the selection of the theme the theme gets applied on the interface and the user gets the
corresponding view.
(Refer Slide Time: 14:57)
Similarly the other 2 themes that we can apply plural as well as geometric themes and then these
will be applied on the background of the interface.
(Refer Slide Time: 15:08)

So, that is all about how the prototype looks and how we can implement the functional hierarchy
that we have identified during the requirement identification phase to create the prototype. Just to
recollect what we have just seen is how the interface appears to the users what the users get to
see while using the system. And our objective here is to create the prototypes for those interfaces
rather than actually writing a program to implement the system.
And those prototypes we can evaluate to see whether there are any usability issues with the
design that we have come up with for implementing the interfaces. So, now our next task is once
the prototype is ready we need to evaluate it.
(Refer Slide Time: 16:12)

So, let us see for this particular that we have just seen how we can apply evaluation techniques.
So, here we will first start with cognitive walkthrough and see how cognitive walkthrough can be
applied to know if there are usability issues with the specific design that we have prototyped and
just discussed.
(Refer Slide Time: 16:27)
Now if you may recollect for cognitive walkthrough you need to come up with a use case and
you have to give this use case to the evaluators. So, they will try to use the interface with respect
to the use case and then try to figure out problems if any and then create a report and finally
those will be compiled together. So, let us see one use case related to the usage of the calendar by
a student.

Suppose you have been given an assignment in the software engineering lab course to avoid
missing the deadline you would like to add a reminder for the deadline of the assignment. So,
essentially it is about setting a reminder for a particular assignment.
(Refer Slide Time: 17:25)

Let us first try to identify what are the interface level tasks that means what are the tasks that the
users are going to perform on the interfaces to achieve the objective that is setting of reminder
first thing is user has to navigate to the date of the deadline by choosing the correct year and
month in case the month is different from the current month. Then the user has to select the date
of the deadline select the plus button to set reminders.

Add the description of the assignment its type as deadline and the time of deadline and finally
save the reminder. So, these are the interface level tasks that the user needs to perform.
(Refer Slide Time: 18:15)
So, this is this screen shows the scenario and here let us quickly see how these tasks can be
performed.
(Refer Slide Time: 18:30)

This is an animation for the activities to be done to achieve this objective of setting a reminder
for a particular assignment okay. So, these are the things on the interface that we need to perform
in sequence which we have just mentioned and seen in the video.
(Refer Slide Time: 18:49)
Now this use case is given to the evaluators. So, remember that for cognitive walkthrough we
need a team consisting of between 3 to 5 evaluators who should not be part of the design team
but there should be experts domain experts and they have to go through the use case perform the
interface tasks on the prototype given and then come up with a report to help them prepare the
report some questions can be supplied.

So, let us see few such questions for example suppose we have set this question where you able
to navigate to the correct month easily. Now let us see different views expressed by the experts..
Expert one here the term. Expert essentially refers to a domain. Expert who is not part of the
design team but who knows how to use a calendar. So,. Expert one says in response to the
question yes I was able to navigate by swiping left from the current month with the prototype
that is given.

Expert 2 also said yes since the month being displayed was the month in which I had to set the
reminder.. Expert 3 again yes a simple swipe on the screen showed the next month's calendar this
is a common way to move to the next element in mobile applications. So, some commentary also
added.. Expert 4 said yes I was able to navigate to the correct month easily. There are of course
some variations like. Expert 2's response is somewhat different than the other 3.
And everybody has their own way of looking at the things and prepare response for the question
asked.
(Refer Slide Time: 20:34)

Then the next question is did you navigate to the wrong month by mistake if yes was the
mechanism to go to the correct month convenient.. Expert one said, yes but it was easy to go to
the correct month by swiping.. Expert 2 said no I selected the correct month. So, there was no
error made. Expert 3 said no I did not navigate to the wrong month I was able to swipe correctly
on the first attempt.

So, there again there was no error. Expert 4 mentioned no I did not navigate to the wrong one.
So, from these responses we can make out that. Expert one probably made some mistake and
then was able to come out of this erroneous situation easily whereas the other 3 experts did not
make the mistake. Another question is was it apparent that you could add a reminder by clicking
on the date or selecting the date.

Expert one said though it was not that apparent I did click the date to add a reminder on that date
the events listed below the dates helped however I am not sure about how to add events in an
effective manner which would span across more than a day that is a very relevant point added..
Expert 2 said yes not at first but I figured it out.. Expert 3 said that it was not completely
apparent but because there was not any other option for it in the default view it was extremely
likely and accordingly he has figured it out.

Expert 4 said it was not apparent that I could add a reminder by clicking on the date I just
happened to click on a date and was directed to that view that contained an option to add the
reminder. So, from these 4 views it appears that the intuitiveness of adding a reminder is not very
high with the current design.
(Refer Slide Time: 22:34)

Next question did the plus button indicate its function appropriately. Expert one said yes the plus
button made it clear that it is meant for adding a new event to the calendar. Expert 2 says yes it
was apparent that it displayed some functionality to add something which could be nothing other
than reminders. Expert 3 said yes it was apparent that the plus button was to add reminders and.
Expert 4 said again yes the plus button indicated its functionality properly I was able to easily
add a reminder. So, all agreed on this point.
(Refer Slide Time: 23:10)
Where the; input fields in the set reminder window clearly visible and was there naming
appropriate. Expert one said the input fields were clearly visible however for adding the deadline
both start and end was shown which confused me I would have liked to have just an end time of
the deadline. Expert 2 said yes the input fields were appropriately labeled and were visible.
Expert 3 said yes the input fields were coloured differently to the background the labels made it
easy to understand the purpose of each input field.

And expert 4 said yes the input fields in the set reminder were visible and their names clearly
reflected what they were meant for. So, essentially one expert disagreed with the naming
convention but other 3 agreed.
(Refer Slide Time: 24:07)
Were you able to see the assignment after adding in the deadline view that was the next question.
Expert one said yes I was able to see the assignment added in the deadline view and it was also
highlighted in the calendar the saved successfully message also confirmed the addition of the
assignment. So, this is a very important observation made by the expert that there was actually a
feedback. Expert 2 again said yes the deadline appeared in the deadline view with the banner
displaying that it was added successfully.

So, the same feedback is mentioned by. Expert 2 as well expert 3 also said I could see the event
added correctly in the specific day view although he did not mention about the feedback. Expert
4 said yes the assignment was visible in the deadline view after addition I also liked that the
assignments were sorted by time. So, some other feature was highlighted by the expert.
(Refer Slide Time: 25:02)
So, that was about one use case 4 experts were appointed to evaluate the interface and they were
given this particular use case and asked 5 questions on which they provided their response. Now
let us see another use case due to some unavoidable circumstances your class for the software
engineering course today has been shifted to 10 am from 10 am to 11 am you would like to edit
the reminder for the class with updated timings. So, now the task is to edit the reminder.
(Refer Slide Time: 25:44)

What are the interface level tasks select today's date select the software engineering class event
edit the start and end time fields to 10 am and 11 am respectively and finally save it.
(Refer Slide Time: 25:58)
So, this is how this interface level tasks can be performed. Again you can see the video and get
an understanding of how the interface level tasks can be performed.
(Refer Slide Time: 26:14)

Again few questions were asked to the evaluators to the experts and their responses were
collected. First question were you able to locate today's date. Expert 1 said yes it was highlighted
in blue colour. Expert 2 said yes the corresponding current day cell had highlighted background
in the months view. Expert 3 said yes the current days date had been highlighted in a different
colour to make it stand out and. Expert 4 said yes today's date was clearly highlighted I had no
difficulty in locating it. So, all could see the date.
(Refer Slide Time: 26:56)

Next question was, was it apparent that you could edit the time of the class by clicking on the
event. Expert 1 said yes it was clear that I will have the have to open the event first to make any
changes to it. Expert 2 said yes not at first but playing around made it clear that clicking on an
event had some functionality associated with it which was to edit and delete. Expert 3 mentioned
while it was not certain it was highly probable because most mobile applications allow editing
elements by selecting them.

So, expert 3 actually bringing in the learning from similar apps which expert had used earlier.
Expert 4 said editing the time of the class by clicking on the event was slightly ambiguous the
tiles representing the events did not look like buttons and an edit option was not explicitly
mentioned. So, it was not very intuitive to the expert.
(Refer Slide Time: 27:59)
Next question is was it apparent that the fields were editable. Expert one said it was not apparent
from the fields itself but the window popped up showing edit reminder made it clear that I can
edit the fields. Expert 2 said yes clicking the fields made them turn into edit mode then it could
be edited. Expert 3 said the edit reminder heading at the top made me confident that the fields
here were editable this was confirmed when I clicked on the input fields.

Expert 4 yes it was apparent that the fields were editable as the fields either closely resemble text
boxes or radio buttons. So, there is clearly a division in opinion some say it is apparent some
thought it is not apparent and those who said it is apparent they probably used their knowledge of
similar apps to infer that the particular functionality can be done with this particular interactio.
(Refer Slide Time: 29:11)
Next question was did you make an error while editing and saving if yes was the mechanism to
correct it convenient. Expert one said no I was able to correctly edit the time fields and save it.
So, no error met. Expert 2 also said no error met I correctly edited the fields and saved
successfully. Expert 3 said that yes while editing the event I deleted the event by mistake. So, I
had to make a new event with the same details it would be better if you could give a warning or
ask for confirmation before deletion.

So, some feedback mechanism is required which was not present in the prototype or rather in the
design. Expert 4 said, no I did not make an error while editing and saving. So, only one expert
made an error and according to the expert the feedback regarding the error should be there which
was missing.
(Refer Slide Time: 30:09)
The next question was where are you able to see the class event with updated timings. Expert one
said yes I was able to see the updated successfully message along with the update in the timings
of the event. Expert 2 also said yes in fact all experts said yes expert 3. Expert 4 it was visible in
the events view for a particular date according to. Expert 2 and banner was displayed showing a
successful update. Expert 3 said yes after saving the edited reminder the class timings had been
updated in the other views too.

Similarly expert 4 said yes I was able to see the class event with updated timings the green
pop-up indicating that the update is successful made the process transparent. So, most of the
experts appreciated the feedback given regarding the operation.
(Refer Slide Time: 31:04)
Let us consider another use case you want to meet your friends during the third week in the next
month you want to check your schedule to find out find an appropriate date and time for the
meet.
(Refer Slide Time: 31:24)

So, what are the interface level tasks swipe left in the current month to navigate to the next
month get an overview of your schedule for the third week in the month view itself select the
date in which you have the list number of events scheduled even better if you have a date where
no events is scheduled check the timings of the events and decide a convenient time to meet your
friend. So, these are the interface level tasks that you need to perform to create an appointment
with a friend.
(Refer Slide Time: 31:58)

Let us quickly see through a video how these interface level tasks can be achieved can be
performed with the prototype. As you can see swipe left then minimum event day then
appointment fixing. So, that is how you can schedule an appointment.
(Refer Slide Time: 32:21)

Similar to the earlier use cases here also the experts asked few questions and their responses
were collected first question was where you able to navigate to the next month without going to
the year's view. Expert one said yes I was able to figure out that you could go to the next month
by swiping left. Expert 2 also was asked the same question and his response was no the swipe
left feature was not so, apparent at first.

So, initially going to months view seemed to be the only option. Expert 3 said yes I did not need
to go to the year view however initially I was not very sure how to go to the next month and I
needed some time to figure it out. Expert 4 said yes I was able to navigate to the next month
without going to the months view however I feel that the transition could be made more apparent
by using a next or a forward button in place of the swipe mechanism being currently used.

So, in response to this particular question asked the experts had different opinions along with
some suggestions.
(Refer Slide Time: 33:38)

Next question asked was where the events listed clearly visible in the months view. Expert 1 said
no I felt that the font size could have been increased I noticed that not all events were shown in
the month. Expert 2 said no not all the events were listed only first 3 in the chronological order
were visible from day wise view. Expert 3 said the first few 3 events of each day could be seen
clearly however their timings had not been given.
And expert 4 said yes the events were clearly visible the events were also colour coded which
gave a rough overview of the kind and number of the events scheduled on a particular day. Again
here majority disagreed that they were clearly visible only one agreed. So, that is a very
interesting finding.
(Refer Slide Time: 34:34)

Third question asked was where are you able to determine the day with the least number of
events effectively through the month's view. Expert once said yes the month's view gave a good
idea of which day would be relatively free without the need to see the events in each day of the
week. Expert 2 also said yes but in my case I choose the day with only one event. Expert 3 again
yes an overview of each day schedule was visible with which I could make out the day with list
events scheduled.

And expert 4 also conquered that yes task headings for the tasks that needed to be performed on
a particular day were clearly specified this allowed me to efficiently determine the days with the
least number of events. So, all agreed in this particular response.
(Refer Slide Time: 35:25)
Next question were you able to decide a convenient time to meet your friend which does not
clash with the other events in the day. Note that all the questions are related to the interface level
tasks and each question has one to one correspondence to the tasks that need to be performed at
the interface level to achieve the objective. So, in response to this question expert 1 said yes after
viewing the events in the day with least number of events I was able to decide convenient time
the events being displayed in the sorted order of time helped.

So, some feature that helped the expert was also mentioned by the expert. Expert 2 said yes I
choose 12 hours to 16 hour slot on 18th April as it had the least number of events. Expert 3 said
yes I could see the timings of all events on that day and decide an appropriate time accordingly.
Expert 4 also said yes I could easily decide a convenient time to meet with my friend on a given
day the events scheduled on a given day were clearly specified and were sorted by time.

So, the same feature is highlighted by this expert as well which is helpful this allowed me to
efficiently decide a convenient time to meet with my friend. So, here again everybody conquered
with the view that they were able to decide a convenient time without any problem.
(Refer Slide Time: 37:01)
Let us see one more use case you want to change the theme of the calendar with some different
background image. So, if this is the use case then what are the interface level tasks. Click on the
figure icon click or select by some means on the figure icon which is labeled as theme select the
theme that you wish to apply. So, these are the interface level tasks.
(Video Starts: 37:34)

Let us quickly see the video on how it can be achieved so here the theme option is selected then
the themes appeared and then a particular theme is used and the theme is applied.
(Video Ends: 37:47)
(Refer Slide Time: 37:48)
So, the questions that were asked were you able to set theme correctly. Expert 1 said yes the
icons were labeled appropriately rest of the procedure was simple. Expert 2 said yes I could
easily set that theme. Expert 3 also concurred yes I applied the theme without any problems. So,
is expert 4 who said yes I could easily apply the theme. So, nobody faced any issue. Apart from
these specific questions some general questions were also asked to the experts.
(Refer Slide Time: 38:22)

For example was there any component in the interface which you could not understand unrelated
to any use case this is a general question. Expert one said no I was able to understand all the
components of the interface as they have clear functions. Expert 2 said most of the things were
fairly easy to grasp other than the year view where the months in a year were displayed. The
swiping action though was not apparent at first but it is fairly easy to grasp.

Expert 3 said the swipe method to change to adjacent months and years was not understandable
at first also changing to your view from month view by clicking on the year was not clearly
visible. Editing reminder was also not very clear at first however when I used the app for some
time I was able to understand each component. So, initially those were problematic as per expert
3 but once a user gets familiar there are no issues.

Expert 4 said I was able to understand all the components in the interface for the large part the
interface was intuitive and easy to use and the functions that were performed by individual
components were clear that is the view of expert 4.
(Refer Slide Time: 39:47)

Another general question asked was sufficient feedback provided indicating that intended actions
was or were performed successfully or unsuccessfully. Expert one said yes the feedback was
provided after each action instantly I was also able to see the updates in the application correctly
after the action. Expert 2 said yes feedback was provided showing updated deleted and saved
reminder banners in case of setting theme the theme was applied to the background.
Expert 3 also said yes feedback was given wherever required whenever a reminder was saved
edited or deleted a banner confirming the same was shown for other actions too the changes
caused by the actions were visible to the user. Expert 4 also conquered that sufficient feedback
was provided after the intended action was performed. For instance whenever I added deleted or
updated a reminder feedback related to the action was shown in a green prompt this allowed me
to easily keep track of what was going on. So, everybody agreed with the feedback.
(Refer Slide Time: 41:05)

Another general question was the interface in accordance with the conventions of the real world
applications as per their understanding. Expert one said yes the interface was in accordance with
the real world conventions the icons used and their colour followed the conventions. The
positioning of the buttons also was in accordance it was similar to most of the standard calendar
applications according to expert 1.

Expert 2 also said yes the days were listed appropriately with events the event view was as found
in different applications its adherence to common conventions makes it easier to use. Expert 3
said yes it was in accordance with the conventions delete and deadline buttons were shown with
the red danger colour file save button and confirmation of successful operations were shown in
green the plus sign was used to indicate adding reminders which according to the expert are in
accordance with the conventions.
Expert 4 said the interface was in accordance with conventions like the other experts conventions
of the real world applications. Since I had a prior experience using such applications I found the
given application very easy to use general conventions such as displaying deadlines using red
colour using the plus symbol in the button for deadline addition were followed which made the
application intuitive. So, everybody found that the conventions colour schemes icons that are
used are in accordance with the real world conventions.
(Refer Slide Time: 42:52)

Was the design appropriate for a calendar application that is a very broad and generic question
asked to the evaluators for their opinions response. Let us see how they responded. Expert one
said yes the design was appropriate and lighter background seemed good however the font size
on the month view could have been increased overall the design was neat clean and simple.
Expert 2 said yes the design follows a normal calendar be it in the month view year view it is as
one would find in a real calendar.

Expert 3 also said yes the design was appropriate with different views for a day month and year
making it convenient for the user to view the calendar at whatever level he wished. Expert 4 said
overall the design is appropriate for a calendar application certain aspects of the design such as
displaying the deadlines sorted by time giving feedback after actions made the application easy
to use however at some points the design was not very intuitive and improvements could be
made.
For instance in the view where deadlines are shown it is not very clear that I can click on the
deadline and update it because the deadline does not resemble a button. Similarly it was not
apparent that I can switch from month view to year view by clicking on the year because the year
did not resemble a button. So, some concerns were flagged by the expert. So, that is the response
rather these are the responses collected from the evaluators based on some use cases as well as
some open general questions.
(Refer Slide Time: 44:45)

Now from these we need to compile them together and identify the issues through some analysis
of the responses. So, the analysis reveals that each evaluator was able to perform the tasks
smoothly and achieve the required objective they were all satisfied with the overall experience.
The controls for essential actions such as addition deletion updation of events were provided
through buttons which reflected their intended purpose as revealed by the experts.

Whenever the user performed some action the app went through visible changes the feedback
was provided by the app to the user whenever the user added edited or deleted reminder.
Although errors were made by the evaluators at some point they were able to recover from the
error. One evaluator faced an error when he mistakenly deleted the reminder and had to go
through the process of adding the reminder again. It would be better if we could show a
confirmation prompt before saving or deleting a reminder. So, here some refinement in design is
required to address the constant raised by the evaluator.

The interface is similar to most of the other calendar applications at some points the steps to
achieve the desired functionality were not apparent but the evaluators experience with other
similar applications guided them. So, there is a potential point of concern where things are not
very intuitive and it expects the user to have some prior knowledge of using similar systems. For
novice or intermittent users probably such modifications are required for expert users the design
is all right.
(Refer Slide Time: 46:38)

So, at the level of functionality if we analyze the responses provided by the evaluators we can
find out several things. Navigating between various months and years in this case what we found
out through the evaluation is that the procedure to go for to the year view by clicking on the
current year is not apparent to some users. So, this is a point of concern. The swiping method to
go to the next month in the month view and the next year in the year view was difficult to find
for some users.

Once in the year view one can then go to the desired month by simply clicking on it which is
natural. So, there is no issue with that.
(Refer Slide Time: 47:30)
Viewing the events of a specific day the procedure to view the events of a specific day is quite
intuitive and clear as revealed by the responses by simply clicking on the day in the month view
we can view all events of the day which is apparent to the users. These events are sorted in order
of their start time further clearly labeled buttons give the user the option of seeing a particular
type of event timetable deadline or meeting each type of event is assigned its own colour.

So, the user can easily make out the type by looking at the event. These are some positive sides
of the design.
(Refer Slide Time: 48:07)
Regarding add edit delete events the plus button for adding events gives the user a clear
indication of its purpose as revealed by the responses. The procedure for editing deleting events
though is not very obvious this is one point of concern, users did not feel confident that clicking
on the event would enable them to perform those operations. So, that is another point of concern
that the users are not very confident.

Once in that edit reminder view users can easily save the events with appropriate details it would
be better to ask for confirmation before saving changes to handle errors. So, this is another point
of concern.
(Refer Slide Time: 48:47)

Regarding set theme functionality what the responses reveal is that the button to set the theme is
clearly visible in the main view and is well labeled in the next step the user can easily select the
desired theme the process is fairly simple for a layman user that is what the responses by the
evaluators reveal regarding this particular functionality. So, as you can see we started with
building the prototype we use the Figma tool to build the different views.

These views are built keeping in mind that the users are going to see the system in this way and
they are going to use the system with interaction in this way. Once the design is represented with
the prototype we set out to evaluate it through cognitive walkthrough for that we have created 4
use cases ask the evaluators to perform those cases perform the interface level tasks to achieve
those objectives mentioned in the use cases.

And while they perform those interface level tasks the problems they faced we tried to extract
those problems in with the help of a set of questions that were posed to the evaluators. So, their
responses gave us some idea of the issues that are faced by them which are likely to have
implications for usability of the interface. So, those issues we have identified during the analysis
phase also we identified some issues by posing some broad generic questions unrelated to the use
cases.

And those also revealed some positive and negative sides with respect to usability of the
proposed design. At the end when we compile the responses together and analyzed it we
identified the positive sides of the design and we also identified some issues that needs to be
addressed. So, in the design prototype evaluate cycle. So, once we identify issues after the
evaluation phase we refine the design by going to the design stage again and then prototype it
again get it evaluated as discussed in the earlier lecture.

So, in this lecture we have seen one such iteration. In continuation of this in the next part of this
lecture we will get to see how to prototype and evaluate heuristically a design. I hope you
enjoyed the material understood the concepts that we tried to learn here looking forward to
meeting in the next lecture, thank you and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Lecture: 19
Case Study on Prototype Evaluation - II

Hello and welcome to the NPTEL MOOC’s course on design and implementation of human
computer interfaces. We will continue our discussion on Prototype building and evaluation that is
lecture number 17. So, in the previous lecture we have discussed about how to build a prototype
and how to get it evaluated with cognitive walkthrough. So, there we talked about one case that
is building a calendar application or calendar app.
(Refer Slide Time: 01:14)

So, just to recap we are interested in building a calendar app which is primarily meant to be used
by students to manage their academic activities.
(Refer Slide Time: 01:23)
And we have already seen the different functions that have been identified as part of requirement
gathering phase which are to be supported by the app. Now the functional hierarchies shown here
so, as you can see there are 4 top level functions display calendar, set reminders, set background
and synchronize and there are some functions like display month, display days display specific
date.

Then create reminders, edit reminders, delete reminders, set theme, reset theme and attach
account remove account among them in our previous lecture we talked about ah creating a
prototype for supporting the 3 top level functions set background set reminders and Display
calendar. Same thing we will do here we will talk about building a prototype for this primarily
these 3 top level functions as well as getting it evaluated.

However this time we will talk about evaluation using a different evaluation method that is
heuristic evaluation.
(Refer Slide Time: 02:41)
So, the main concern here is building a prototype that supports the functions which are part of
the functional hierarchy and getting it evaluated with experts using heuristic evaluation method.
(Refer Slide Time: 02:55)

So, the Prototype that we are going to talk about is a medium fidelity vertical prototype however
vertical prototype as you can recollect is not mandatory. So, primarily we will be focusing on the
different interfaces that are part of different stages of the Prototype and the Prototype has been
built with the figma tool which we use to build our earlier prototype as well as discussed in the
previous lecture.
(Refer Slide Time: 03:31)
Now the Prototype has this month view specific date view, year view, background view where
background can be changed dark background custom background then other views like deadline
views timetable view scheduled of a day that view. So, all these things are supported which are
results of the analysis of the functional hierarchy that we have just seen.
(Refer Slide Time: 04:05)

Let us see the views although this prototype is designed as a vertical prototype to support screen
transitions. We can think of it as horizontal prototype where we will focus primarily only on the
interfaces for specific views and then we will evaluate it using heuristic evaluation. Let us start
with the year view. So, if we want to get a year view we can see such an interface where the year
is mentioned here.

And then the months are mentioned on the top and if I select a specific month the current month
the days are shown here and the year can be changed. To change the year this right hand interface
appears where we can change the year.
(Refer Slide Time: 05:03)

The month view as we have just mentioned in the year view itself the month view is available
this is for the current month it can be for other months as well. So, we have to select the month
from the top menu.
(Refer Slide Time: 05:21)
In this month view we can also have specific dates and if we choose a date like here then for this
date we get to see the events that are scheduled on that day likes shown here in this type of
interface. So, for 12th July that specific date in the year 2022 these are the events that are
scheduled CS544 a course CS361 another course 3 4 5 another course assignment submission
some other activities.

So, these are part of that activities and events that can be viewed if we select a date. So, that is
the interface for specific date.
(Refer Slide Time: 06:17)
Then we can set events for a date. So, if we choose a date then this interface appears and below
this interface there is this button and if we select this button then the other interface on the right
hand side appears where we can mention the event name start time of the event end time of the
event and some brief description which is optional. And as you can see below we can save it
save this event or we can delete also if we think that that is not necessary to save.
(Refer Slide Time: 06:54)

Then comes the background view. In this view we start with the year view where we get to see
the days of the year and below that interface there is this set background option. So, once we
select it the next interface appears in the middle where we can have either dark theme or some
other theme that we can select from the device. If we choose the dark theme then that is a pre
stored theme and this top interface appears with the background changed to the dark colour.

If we make the other selection that is select from device then some other background themes may
appear depending on what are stored in the device and we can choose from here. Like if we
select this particular theme then this next interface shows the theme applied on the year view as
shown in this interface.
(Refer Slide Time: 08:10)
For deadline view we have this deadline view option here once it is selected it shows all the
deadlines for a specific date which can be chosen from here.
(Refer Slide Time: 08:28)

Similarly to see the timetable we have this time table view for a specific date that we can select
from here and the timetable for the day date is shown in this interface on the right hand side.
Here you can see additional information along with the timetable.
(Refer Slide Time: 08:51)
Another option present there is schedule view. So, this view is meant for schedule of the month
like 12 July 13 July 14th July. So, what are the schedules it will show you the schedule for the
month in this type of interface where it can be scrolled up or down.
(Refer Slide Time: 09:19)

Another feature of the interface although that is not exactly part of the functional requirement
hierarchy. Functional hierarchy is a dialog box that is added to prevent errors. So, if there is
something needs to be saved some changes have been made or you want to close the app before
that this type of confirmatory messages appear where you can confirm or decline to confirm the
changes. So, that is all about the prototype.
(Refer Slide Time: 10:07)

Now let us evaluate this prototype with heuristic evaluation.

(Refer Slide Time: 10:20)

So, in order to perform heuristic evaluation we will follow the 10 heuristics by Nielsen just to
recap. So, these 10 heuristics are visibility of system status, match between the system and the
real world, user control and freedom, consistency and standards, error prevention, recognition
rather than recall, flexibility and efficiency of use, aesthetic and minimalist design help users
recognize diagnose and recover from errors help and documentation.
So, these are the things that are expected to be there on the interface the system status should be
visible to the user there should be a match between the system and the real world user should
have control and freedom for operations. The system should follow consistency and standards it
should support error prevention mechanisms, it should support recognition rather than recall it
should provide the user flexibility and efficiency of use.

It should have aesthetic and minimalist design, it should help users recognize diagnose and
recover from errors and finally it should have help and documentation support. These are 10
things that needs to be checked for ensuring that the interface is usable.
(Refer Slide Time: 11:50)

Now from the designer's point of view let us see what can be the view with respect to these 10
heuristics. First is visibility of system status the system should keep users informed about what is
going on through appropriate feedback within a reasonable time gap. According to the designer
the users in this system can distinguish and easily find today's date and month as it is highlighted
with noticeable colour dates with deadlines are also highlighted in red colour.

Changing the months is quite intuitive as dragging left towards text to the previous month and
dragging right towards text to the next month and also on changing the month we can see the
change in the view in real time. While selecting the year the up down buttons increase visibility
and give users feedback on the change of the year. New, events for any particular date can be just
created by tapping on the; date to which event has to be added.

Moreover in the specific date view for any date the events that have some deadline is when
created has a star symbol which helps to see the user the change taking place. In timetable view
the user can see the current time in a red line thus helping in an easy preview of current status.
So, these are what the designer thinks about conforming to the first heuristic that is visibility of
system status.
(Refer Slide Time: 13:27)

Next heuristic is match between system and the real world. What it means is that the system
should use users Daily Language with words phrases and Concepts familiar to the user rather
than any specific system oriented terms and what the designer thinks about this particular design
similar layout to real life physical calendar red colour to indicate deadlines and other cautionary
instructions like delete and reset.

Green colour to indicate instruction like save for success a star beside deadlines in dead view to
indicate the importance plus sign to add a new event. So, these are the things that are added to
ensure that there is a match between system and real world as per the designer.
(Refer Slide Time: 14:15)
Next is user control and freedom. So, this is the third heuristic users often use functions by
mistake and may need a clearly marked emergency exit to leave The unwanted state without
having to go through an extended process of rewriting the change that is what is required to
ensure this third heuristic is satisfied. So, what the designer thinks about the design with respect
to this third heuristic different themes and views are there in the system allowing user to choose
according to their preference. So, this implies freedom.

Option to edit and make changes to deadlines implies control. Prompt message before saving
allowing users to rectify the errors or to discard them completely emergency exit. So, according
to the designer the design supports this third heuristic as well.
(Refer Slide Time: 15:17)
The 4th heuristic is consistency and standards what it says is that users should have the
experience of not having to wonder whether different word situations or actions mean the same
thing or different things. In the design for this calendar app what the designer thinks with respect
to the 4th heuristic. In the design users can see the timetable of classes in timetable view and
specific date View and in both the types of views consistency in colour coding for different
courses is maintained that means it supports consistency.

Even the overall UI also maintains this colour consistency. So, consistency is supported however
nothing is mentioned about following the standard.
(Refer Slide Time: 16:03)
Error prevention is the fifth heuristic, even better than good error messages is a careful design
that prevents a problem from occurring in the first place. What the designer thinks a prompt is
added for confirmation when there is any change in the view whether it is change in background
theme or addition or deletion of any events for any specific date which helps in error prevention.
So, designer thinks that the prompt feature or the dialog box that we have seen is supporting this
heuristic.

Adding time while creating an event is handled by another view that is solely just designed to
take correct time and correct format thus minimizing human error. Again the designer thinks
because of the particular design error prevention is possible and this particular heuristic is
satisfied.
(Refer Slide Time: 17:06)
Next heuristic is recognition rather than recall which implies that the design should minimize
users memory load by making objects action and options visible. In the design adding events
saving events deleting events and changing views all have well known and heavily used icons to
recognize the feature according to the designer. Using any feature in the application does not
need recall for the user as the function names are quite self explanatory again according to the
designer.

While creating an event the user can see some text in the input fields describing what should be
entered in those input fields which according to the designer is an effective measure for
recognition for the user. So, the designer thinks because of this particular way of Designing the
design supports recognition rather than recall.
(Refer Slide Time: 18:18)
Next is flexibility and efficiency of use for different user categories namely novice intermittent
and expert users. In this design since the application is quite simple in nature as perceived by the
designer hence from novice to expert users all have the same simple interface according to the
designer. So, designer thinks the interface is quite simple. So, it does not matter whether the user
is novice or expert all will be able to use it. So, it provides flexibility and efficiency of use.
(Refer Slide Time: 18:47)

Next is aesthetic and minimalist design which states that dialogues should not contain
information that is irrelevant or rarely needed. Different types of views have the most appropriate
amount of information that is required all these qualifications are made by the designer that
whether the information is most appropriate or not again simple UI in all types of views does not
intimidate the users and hence restrict the users from abandoning the application.

So, this is what the designer thinks that the amount of information is appropriate not intimidating
and does not lead to rejection of the application.
(Refer Slide Time: 19:33)

By the user next heuristic is the design should help the users recognize diagnose and recover
from errors. In the design the calendar allows users to delete any already set events along with an
extra layer of protection prompt asking for confirmation. User can easily revert, the changes back
when needed. The designer feels so, while adding a deadline The View has a star along with it if
this is not the case then it helps the user to recognize that something might have gone wrong.

So, again there is some indication regarding erroneous situations and the designer thinks all these
design choices made the system help users recognize diagnose and recover from errors.
(Refer Slide Time: 20:27)
Finally help and documentation support for the design since the calendar mimics a basic calendar
most of the functionalities can be naturally understood by the user and no documentation is
required as such which the designer feels. In other words there is no documentation provided in
the design and the designer feels that is not required. Precise titles clearly indicate the
functionality.

So, the titles itself can be treated as documentation as per the designer and that those titles can be
used to help the users use the system. For several functionalities a small explanation is also
provided in the white space. So, that is not there for all the functionalities but for several
functionalities. So, that is one sort of documentation according to the designer. So, in summary
designer thinks that there are several design decisions made which indicates that the 10 heuristics
by Nielsen are supported in the design which in effect implies that the design is usable. Now let
us see whether that is indeed true with respect to some independent evaluation by experts.
(Refer Slide Time: 21:47)
So, let us assume that heuristic Evolution has taken place just to quickly recap in heuristic
evaluation we have a team of 3 to 5 expert users who are domain experts. They are asked t check
the interfaces and see whether the interface design satisfies the heuristics and they are asked to
prepare reports. Each evaluator prepare reports and at the end those are compiled to identify
points of concerns.

Let us assume that we have followed such a approach such an approach and let us discuss the
results. Suppose there is one evaluator who produced a report which we are terming as
evaluation one. So, the evaluator found that the visibility of system status is not satisfied. The
evaluator feels that the system status is not visible for any instances. For example when I set a
new event the system does not show any status whether it is a success or a failure.

So, the view of the evaluator is that system status is not visible. Match between system and real
world that is satisfied all the symbols words used in the system are matched to the real world
these are commonly used word and symbol. So, the second heuristic is satisfied according to the
first evaluator. User control and freedom not satisfied there are no undue and redo features for
some actions consistency and standards not satisfied the system is not consistent with the various
calendar applications.
The deadline view timetable View and the schedule view buttons are placed in the places which
is not common in the calendar apps. A separate menu bar should be provided to select these
options. So, according to the evaluator these two heuristics are not satisfied.
(Refer Slide Time: 23:53)

But the designs supports error prevention the save and delete buttons in the event creation page
are far enough to select the proper option. When I try to delete a particular event or I try to reset
the theme a pop-up comes up to confirm if I really want to do that. So, these according to the
evaluator help preventing error. Evaluator also feels that recognition rather than recall is
supported in this design.

While creating an event I can see some text in input Fields describing what should be entered in
those input fields which is an effective measure for recognition for the user.
(Refer Slide Time: 24:32)
Regarding flexibility and efficiency of use the evaluator feels it is supported since the application
is quite simple in nature hence from novice to expert users all have the same simple interface.
So, the heuristic is supported aesthetic and minimalist design heuristic is also supported only
relevant details are shown in the system no irrelevant details are asked or displayed in the
system.
(Refer Slide Time: 24:58)

Help users recognize diagnose and recover from errors not supported according to the evaluator
while adding an event if the event fails to add events it does not show the reason making it
difficult to diagnose it. Help and documentation is also not supported no help and documentation
is observed. So, these are the opinions according to evaluator one. Let us see another evaluation
report let us call it evaluation two.
(Refer Slide Time: 25:30)

Here also according to the second evaluator visibility of system strategies not supported while
adding event or uploading custom background the system state is not visible. Match between
system and real world supported used red colour to indicate deadlines and other cautionary
instructions like delete and reset. Used green colour to indicate instructions like save user control
and freedom according to this evaluator it is supported when delete option is selected a prompt
pops up to undo it once event is created it can be edited.

Regarding consistency and standards not supported the menus are placed in the odd place
according to the evaluator.
(Refer Slide Time: 26:20)
Error prevention supported pop-ups appears to prevent errors while entering date time for the
events date time interface menu pops up to enter date time in correct format. Recognition rather
than recall supported adding events, saving events, deleting events and changing views all app
well known icons to recognize the feature.
(Refer Slide Time: 26:44)

Flexibility and efficiency of use supported. The system is flexible for both novice and
experienced users, aesthetic and minimalist design supported there are not any dialogue that
contain information which is irrelevant or rarely needed. So, this is the view of the evaluator.
(Refer Slide Time: 27:04)
Help users recognize diagnose and recover from errors not supported. While adding custom
background if some PNG image is selected the background is not loaded and the information is
insufficient that means no information is displayed for not applying the change making it hard to
diagnose. Now information is displayed when event creation fails help and documentation is also
not supported no help and documentation is found in the prototype. So, this is the view of
evaluator 2.
(Refer Slide Time: 27:44)
Let us look at the view of a third evaluator. Visibility of system status not supported does not
show any system status while creating editing or deleting events. Match between system and real
world supported add edit delete icons are used as it is used in other applications.
(Refer Slide Time: 28:03)

User control and freedom supported users have the control over the created events, consistency
and standards not supported the set background button looks bigger than other buttons.
(Refer Slide Time: 28:20)

Error prevention supported used pop-ups to prevent functions like delete, reset and replace event
data or rather during edit bit of operations pop-ups were there to get confirmation. So, that helps
in error prevention. Recognition rather than recall supported the functionalities could be
recognized by the way it is presented.
(Refer Slide Time: 28:54)

Flexibility and efficiency of use supported. The system is very simple and can be used by both
novice and expert users. Aesthetic and minimalist design supported only relevant details are
given while viewing dates events and creating new events.
(Refer Slide Time: 29:12)

Help users recognize diagnose and recover from errors, not supported. While creating event if
some information is not given the event is not created however this reason is not displayed to the
user. Help and documentation not supported no help and documentation there. So, we have seen
different opinions rather different responses to the evaluation by different evaluators. At the end
we are supposed to compile them together and identify common points of concerns which will
eventually lead to refinement of the design.
(Refer Slide Time: 29:56)

So, if we summarize the evaluations what we see is that in case of the first heuristic visibility of
system status evaluator one things it is not supported two things not supported 3 also things not
supported. Second one match between system and real world all 3 things supported. Third one
user control and freedom one thing not supported 2 and 3 things think there it is supported.
Consistency and standards none of the evaluated things it is supported.

Error prevention recognition rather than recall, flexibility of use, aesthetic and minimalist design
all the evaluators things these 4 are supported in the proposed design represented in the form of
prototype. Whereas the remaining two help users recognize diagnose and recover from errors and
help and documentation support all the evaluators think these two are not supported. So, only in
case of user control and freedom there is a difference of opinion between the evaluators.

Otherwise in all the other cases all the other heuristics, 9 heuristics the opinion is same. Now
here we can say that because majority thinks it is supported out of 3, 2 things it is supported for
this particular third heuristic user control and freedom we may consider it to be supported
whereas for heuristic 1, heuristic 4, 9 and 10 these 4 heuristics are not supported. So, we have to
do something in the design to support these heuristics.
(Refer Slide Time: 31:57)

We can summarize as the evaluators noticed that no System state was visible a message can be
shown once an event is created edited deleted and background is applied. So, that is what can be
done to refine the design. Evaluator one pointed out that there is a need for undo and redo. Undo
and redo operation can be incorporated by adding undo redo for the last activity. However we
have edit option for created events.

According to the evaluators the buttons for the view are not expected in the front page first
interface this can be added in a separate maneuver. So, these are some suggestions that can be
used to refine the design. So, that the heuristics are supported while creating events and setting
backgrounds the reason of any error can be displayed as an error message. Since it mimics a
basic calendar most of the functionalities can be naturally understood by the user and no
documentation is required as such.

So, although that particular heuristic is not supported all the evaluators pointed out that the
interface is simple. So, documentation may not really be required. So, it does not matter whether
the; particular heuristic is supported and documentation is added or not because this particular
application is very simple. So, at the end what we get is some suggestions first status check of
the quality of the design with respect to the heuristics and then based on the responses we can
figure out whether we need to make improvements or it is not really necessary.

Even if the heuristic is not supported like in the case of help and documentation. So, that is all
for this topic. So, in this lecture we have learned about how to create prototype how it looks and
how we can apply cognitive work through or heuristic evaluation to evaluate the prototypes what
are the steps what reports we get how to compile them and how to draw conclusion. Based on
this conclusion we may go for refinement of design which is followed by again prototyping and
evaluation or we may say that there are no further issues.

So, we can freeze the design and go to the code design. I hope you enjoyed the content of this
lecture looking forward to meet you in the next lecture, thank you and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology, Guwahati

Module No # 05
Lecture No # 20
Basics of System Design

Hello and welcome to the NTPEL MOOC’s course on design and implementation of human
computer interfaces lecture number18 where we will start our discussion on system design.
So before we start we will quickly recap the interactive system development life cycle and
then we will understand where we what we discussed and where we are at present. Then from
there we will forward the discussion.
(Refer Slide Time: 01:17)

So if you recollect in the interactive system development life cycle there are several stages
some of the stages from some cycles. So; essentially the lifecycle contains iterative
components as well as some non-iterative components. So we started our discussion with the
requirement gathering analysis and specification stage. Where; we learned about how to
create an SRS document or software requirement specification document.

In the document we can include both functional requirement as well as non-functional

requirements. After the requirement gathering stage we have a cycle which is design
prototype and evaluation cycle. So there are 3 soft stages involved here one is the design
stage one is the prototyping stage and the third one is the evaluation of the prototyping that
stage.
Now if you may recollect here what we mentioned is that design actually refers to 2 thing one
is interface design and system design or code design. So we have so far discussed interface
design and this cycle refers to design of the interface. So once we have some design ideas
then we create a prototype get it evaluated and refine our design based on the evaluation
results and so on the cycle continuing still we arrive at some stable interface design.

Also design during the discussion we have learned about how to go for designing an interface
particularly we learned about design guidelines. In prototyping we learned how to make
different prototypes ranging from low cost and affordable prototypes to high cost system
oriented prototypes. So there are broadly 3 types low fidelity, medium fidelity and high
fidelity.

So learned about these different prototypes and how to use them also we learned in details
about different prototype evaluation techniques. We learned about to broad techniques one is
evaluation with experts and evaluation with users with the objective of getting the evaluation
done rapidly and without much cost. So once we arrive at some stable design then we go for
system design where we design the components of the system in modules and some modules.

Now then that is followed by implementation of the design in the coding and implementation
stage then comes testing of the code that is another stage. A very important stage so after
testing we get an executable system this is followed a special stage called empirical study
where we test the system or usability. So getting only an executable system is not the goal our
overall goal is to get a usable system.

So we have to conduct empirical study stage now occasionally it may happen that in
empirical study we found some usability problems. So we need to refine our interface designs
and the subsequence stages we need to carry out. So there is a loop from here but it is very
infrequent unlike the design prototype evaluate cycle. So after we arrive at an executable and
usable system we go for deployment followed by maintenance stage that is our overall
interactive system development life cycle.

Now in this life cycle we have so far covered requirement gathering stage and interface
design stage. In this lecture we are going to take the discussion forward. So we have covered
under interface design stage how to design the interface create prototype as well as evaluate
the prototype. So entire cycle we have covered for interface design and then in this lecture
onwards we will take it forward.
(Refer Slide Time: 05:54)

So we have learned about interface design issues and guidelines in the earlier lectures. And
now we are going to discuss once we design an interface how to convert the interface design
to the design of a system specifically software. Note that here in this entire course wherever
we use the term system we primarily refer to the software. So we are going to talk about
design of the system which is based on the design of the interface that we arrive at executing
the design prototype evaluate cycle.
(Refer Slide Time: 06:46)

Now the design prototype evaluate cycle as I mentioned primarily caters to the interface
design aspect of the lifecycle. Once we get a stable design so the design is stabilized that
means no further usability issues are discovered or in significant number those issues are
discovered after the evaluation stage. So no further iteration of the cycle is done and we reach
at a stable design and then we focus on converting that stable interface design to the design of
a system.
(Refer Slide Time: 07:34)

Now when we are taking of design of a system the same 2 issues come back what are those
issues? One is where to start? And the second is how to represent? In case of interface design
we encounter the same issues and if you recollect we discuss that to answer the question
where to start the interface design process we can start with design guidelines. Also our
intuition experience this can be a starting point and we say how to represent interface design
we talked about prototypes to express the design.

So in case of interface design prototypes can be used to represent the design or essentially
that is the design language. So in case of system design this same issues are there where to
start and how to represent?
(Refer Slide Time: 08:35)
Now the core objective of a system design is to make the final code manageable what this
means? So when we are saying that we need to go for design of an interface we are primarily
concerned about what the user perceives what the user gets to see a interact with or gets to
perceive an interact with. So there our primary concern is our user now when we are talking
of system design our primary concern is implementation that is we need to built a software
for that we need to write a code and that code how to write it in a way such that it is
manageable.

Why that issue is important? Generally codes return in a team for complex system, typically
complex systems require writing of hundred or thousands of lines of code and if single
persons are interested with this task then it becomes very difficult. And there is possibility of
huge number of errors. To address this problems what happens is that? The code is divided
into units and different teams are entrusted to develop the units separately and then finally
combine them together to create a whole system.

So that is typically what is called a modular design to manage the overall development
process smoothly. So when we are going to designing the system we should keep that in mind
and try to design it in a modular way such that so that when we convert it to code the modular
development is done or is possible. So our main objective in system design is to help in
managing the code development well and help in making the code manageable. So let us
begin with the first question where to start the system design process?
(Refer Slide Time: 10:52)
Now earlier in the requirement gathering stage we saw the output is SRS or software
requirement specification document. Let us begin with the question where to start so we start
with the SRS document or software requirement specification document. If you recollect this
is the outcome of the requirement gathering analysis and specification and we start our
system design with this document.

Now when we are going for designing our system there are broadly 2 phases what are those 2
phases? One is the preliminary design where we go for designing a system at a very high
level. So this is essentially a high level design of the whole system and then there comes the
detailed design phase. Now in this phase what happens is that? We go to the minute detail of
the system now this is also known as modules specification document.

So when we are creating a detailed specification document this is also called module
specification design document. So in the preliminary stage we design at a high level at the
modular level and in detail design stage we go to minute details of the modules.
(Refer Slide Time: 12:36)
Let us begin with the high level design phase let us try to understand what we do at this
phase. So at this level as we earlier mentioned that our whole objective is to make the code
manageable. For that we need to go for a modular design approach where we can divide the
big problem into smaller modules which are easier to manage rather than trying to manage
the whole problem at a time.

So at the high level design we start with identification of modules also at this level what we
do is? We try to find out control relationships between the modules and at this level we
provide definition of interfaces between modules. So modules need to interact with each
other how they interact what kind of interfaces should be there that definition also you
provide at this phase of system design that is high level design phase.
(Refer Slide Time: 13:49)
The next question then is once we manage to come with a design how should; we represent it.
So that it becomes easier to understand by others who are going to implement the design. So
what language to use there are actually many languages which we can take request to
implement the system design idea.
(Refer Slide Time: 14:23)

Let us see one example later on we will see another example so this example actually shows
one particular language used to present a high level system design. This is called DFT or data
flow diagram as you can see here in this example so essentially what is happening is that? We
are using graphical notations to express the design idea so it is a graphical language to
represent design.

There are certain conventions and standards used like any language that we will learn later
but here I want to just give you some idea about the idea about DFT or the idea of the
graphical languages and how it can be used to express a design. Suppose we are asked to
design and web based newspaper application. So essentially we are looking for designing
software which is a newspaper application which is based on an web.

So a user can get the newspaper through a browser so what happens is that somebody as
designed this system and this is a top level view of the deign where this entire circle which
contains this text web based newspaper is the representation of the system. Whole system is
represented with this circle here then there are some rectangles used which are representing
who all can interact with the systems who all are the stake holders for this system.
For example there can be administrator there can be a special type of user or there can be
some other type of users. Also it shows how these different stakeholders who are users of the
system can interact with the system in the form of labeled arrows like the one shown here. So
this arrow is there with a level which shows what data flows and in which deduction it flows.
For example administrator can interact with the system in different ways by providing news
details user details, content details several information account details etc.,

A special type of user marked as user share can interact with the system with general
discussion providing feedback addition of comments and account details. That is how the
design is (())(18:00) and then this particular notation are used to represent the design.
Similarly other user can view or search so the other user can interact only with these 2 ways
other interaction mechanisms are not available to the other users.

In that way we can indicate who are the user how they interact and what they interact so that
is the graphical language. Now of course when we are representing the whole system with a
single circle that does not convey anything at a very high level it says that there is the system
and there are these users and those users can interact with the system in so and so manner.
But then what is inside the system?

What is the design of the system? Same language DFD can be used to represent the lower
levels of the design as well although still at a very high level.
(Refer Slide Time: 19:08)

For example that circle which represented the whole software can further be expanded in the
second level will learn about this level idea of levels and all these things in a later lecture
exclusively on DFD. But right now just to give an idea so that software contents several
modules as represented with these symbols one is faculty login module, one is faculty main
menu, one is conduct examination menu.

So this is of course not the design of the earlier system but this is design of some other
system which is related class room teaching. There is another module on faculty course
management so these particular symbols are used to represent modules or processes and then
there are symbols to represent some databases. Like the symbols used here rectangles this
represents several databases that are used by the system.

So essentially this is a second level representation top level will represent the whole system
in the form of a single circle as shown in the previous slide previous part of the lecture. And
if we want to express more details of the design in terms of the modules that are part of this
whole software then we can go for the next level of design using DFD where we can show
the modules.

Now these processes will require some data to operate on so that database also requires
something to represent so we can represent it using the rectangles as shown here. Then
interaction between modules again in the form of leveled arrows to show the direction and
content of interaction. So all this things can be represented with DFD we can go to even
lower levels, so one of the modules from the second level can be broken down into some
modules and shown as separate level of the DFD for that particular like one third level DFD
is shown for the modules shown in the earlier design of the system.

Now it may be noted that conventions used are the same like to represent process we use this
circle this notation to represent databases we use this notation leveled arrows. But this whole
thing here is actually representing one of the modules at the higher level. So one module is
divided into some module with interaction between them and the database they use and that is
that forms separate level of DFD.

We will learn about all these things in details in the later lecture so that is just to give you
some idea of just to express our design in the form of graphical language. Like DFD there are
other languages partly graphical languages are also there so later on we will learn about this
languages in more details. So that is about high level design note that in the high level design
that is where we are talking about modules and their interaction we are not telling how the
modules are implemented.

Instead we are simply saying that ok in the system there will be these many modules they will
interact with each other in this particular. In that direction and there will be some databases
which will provide data to the module and get data from the modules so on and so forth.
(Refer Slide Time: 23:45)

Now in the detailed design phase what we do? We go for detailed design of the modules and
sub modules that are part of the overall system. So here we identify data structures and
algorithms that are required for implementing different modules so that is the detailed design
phase. So that is in a nutshell what is system design so we have 2 phases of the design in the
first phase we go for designing the high level concepts in the form of modules and their
interaction.

And in the second phase we go for detailed design of the modules in terms of the data
structures and algorithms that they require to be implemented. So once we have a design
definitely the question comes whether this is a good design or bad design. So how do we
categorize whether some design is good or bad. For that we need to know what characterizes
are good design?
(Refer Slide Time: 24:48)
So let us see the characteristics that define a good design first thing is coverage. Now this
particular characteristic tells us that a good design should implement all the functionalities
that are specified in the SRS. So you have created a software requirement specification
document containing functionalities. When we are going for a system design the design will
be considered to be good if all the functionalities that are there in the SRS are part of the
design.

If we miss some functionalities then this is not a good design the second characteristics is
correctness that means a good design should be able to correctly implement all functionality
of SRS. Now here correctly means that it should be able to produce the desired output when a
specific output is given. So correct implementation of all functionalities is another hallmark
of good design third important characteristics is understandability what it means?

Any system design that you come up with a represent using some language should be, easily
understanding now this is very important. So the whole idea is that you divide the whole
problem into manageable smaller sub-problems in the form of modules and some modules.
So it is not necessary or generally it is not the practice that all the modules and sub modules
are implemented by the same team which designs the system.

It may happen and which is most often the case that the design is distributed to several teams
and they are asked to implement different modules and then finally those are combined
together. So whenever we are creating a design and expressing it with some language the
design should be easily understandable to people who are not part of the design. Otherwise it
will be very difficult to implement the design in a team.
So understandability is very essential characteristics of a good system design where
understandability means it should be understandable by other team members who are not the
part of design team.
(Refer Slide Time: 27: 58)

But maybe asked to implement it the fourth characteristic is efficiency this is another
important characteristic. The whole design should be efficient now here efficiency means that
the whole design should be made in a way such that it is possible to implement the design
idea with efficient usage of available resources. So a design should not require things that are
not available then that are not a good design.

So whenever we are going for designing something we should be aware of the resources
available and accordingly we should design so that those resources are used optimally. Fifth
characteristics is maintainability the design should be amenable to change so if there is some
change required after brainstorming over the design it should be easy to that without having
to recreate the whole design from scratch.

So we should be able to conceptualize and represent the design in a manner such that changes
can be performed at a local level without having to redo everything in the design. So those
are essential characteristics that define whether we can level a design as a good design or a
bad design. If this 5 characteristics are not there as per our evaluation of the design then;
there is a need to refine the design so that these 5 characteristics are maintained in the final
design.
So that gives us some idea of whether our design that we have come up with can be
considered to be a good design or a bad design. Now let us try to understand another
important concept in relation to design of a system.
(Refer Slide Time: 30:26)

Cohesion and coupling what it is and what are these concepts and how they are related to
good designs? As we have repeatedly said our goal is to come with the modular design so
that we can distribute the implementation work for faster turnaround time. So good software
design requires clean decomposition of the problems into modules this is very important we
should be able to very clearly and easily decompose the problem into sub problems or
modules that is not the only thing.

Also we should be able to neatly arrange the modules in the form of a hierarchy that is also
required. Now whether we will be able to do that? Whether we will be able to go for the
modular design or not depends on 2 properties of the design cohesion and coupling. So;
essentially modular design depends on cohesion and coupling.
(Refer Slide Time: 32:00)
So let us start with the idea of cohesion now cohesion typically is the property of one module.
Whenever we are trying to design a module it has a property of cohesion what this property
indicates? Several things determine the cohesiveness of a module and there are several types
of cohesion. One is logical cohesion that is if all the functions in the module perform similar
operations.

For example suppose there are several functions which are part of the error handling module
so essentially their objective is to deal with different types of errors. So all the functions are
performing error handling then we say that this error handling module is logically cohesive.
Then there is temporal cohesion that is if all the functions of a module should be performed
in the same time span.

For example whenever a system starts we have defined an initialization module so there are
several functions as part of the module and those functions initializes several maybe data
structures or storage elements databases. So all the functions are doing the initialization at the
same time span which; is at the beginning of starting of the operations of a system. If that is
the case then we say that the module in this case the initialization module is temporally
cohesive.

Then there is procedural functional cohesion which indicates or which happens when all
functions of a module are part of the same procedure or algorithm. Suppose there is a
deciding algorithm used in some image processing task image processing software. Now
decoding algorithm need not be implemented in the form of a single function instead we can
implement it as a group of functions all are part of the same module of decoding and they are
all representing the different part of the same decoding algorithm.

Then if such a situation exists then we say that particular module is functionally or
procedurally cohesive.
(Refer Slide Time: 34:45)

Then we have communication cohesion it happens when all functions refer to or update the
same data structure. As an example if a set of functions are there that are operating on a
linked list data structure. So that means they are referring to the same data structure as well as
updating the same database structure then those functions are said to having communication
cohesion property.

And finally we have sequential cohesion ouput from one element is input to the next element
of the module. For example the sequence of functions get input validate input and short input
if these 3 together form a module then the output of get input is fed as input to the validate
input function. Validated input output is fed to the short input function so then they are
sequentially cohesive module then that particular module is called sequentially cohesive
because the functions that are part of the module follow the sequential cohesion property.

So essentially this cohesion property what they say is that a module is a collection of
functions and how the functions behave in terms of input or communication between them or
execution, behavior. So those; behaviour of the functions in a module represent the cohesion
property of the module and there are 5 types of cohesion depending on how the functions
behave that is about the cohesion
(Refer Slide Time: 36:48)

Next is the concept of coupling now cohesion is property of the single module so the
functions that are part of the module coupling in contrast is the property between modules. So
when we say coupling we say that it is the property between 2 or more modules. Now there
are likewise there are different types of coupling possible one is data coupling what it says is
that? If 2 modules communicate through data item then we say that they are having data
coupling property.

For example passing an integer between 2 modules so if we are designing modules in a way
such that some integers need to passed between them then they are having data coupling
property. Then we have control coupling if data from 1 module is used to control the flow of
instruction in the other module then we say that there is this property of control coupling. For
example if there is a flag data which we said in one module and that is used to control the
flow of operations in some other module then there is a control coupling between these
modules.

Then we have content coupling if 2 modules share code then they are said to have content
coupling property. For example branch from one module leads to execution of coding in
another module. If that is there then we say that these 2 modules share the content coupling
property.
(Refer Slide Time: 38:49)
So to recollect we have these 2 important concepts which are nothing but properties of
modules one is cohesion which is a property of single module and one is coupling which is
property between modules. Now one important thing that we should note is that high
cohesion and low coupling leads to functionally independent modules. So our objective is to
have clean and neat the composition of the problem into modules.

And we should be able to represent them in a hierarchical manner now that is possible when
we have functionally independent modules and that is possible in turn when we have high
cohesion within modules and low coupling between modules. So essentially whether we are
able to achieve our goal of a very good modular design depends on whether we have been
able to design modules such that the modules have high cohesion and low coupling.

If that is satisfied then we will be able to go for a very nice modular design otherwise it will
not be high quality modular design. So our goal should be to have as little coupling as
possible and as high cohesion as per possible.
(Refer Slide Time: 40:35)
So with that we got some idea of what is the aim of system design what we need to know and
what we should be aware of? Now next task is to understand how we can go for designing
system. So what are the approaches available broadly there are 2 approaches. One of these
approaches is function oriented approaches. In this approach what we do when we go for
design of a system is that we use functions as basic abstraction.

So whole system is designed is based on functions if we are going for such a design then we
call it function oriented design approach. Now when we are using oriented design approach
to represent that design we rely on generally we rely on DFD or data flow diagram the
example that we have seen in the earlier part of this lecture. As I said on DFD we have
detailed discussion later.
(Refer Slide Time: 41:51)
The other broad approach for system design is called object oriented design. Here instead of
function the basic abstractions that we use are objects which are instantiation of a concept
called class. So in object oriented design approach we rely on objects as the basic abstraction
or basic unit and these objects are instantiations of concept called class. So that is the basic
idea on which the object oriented design approach works.

Here also we rely on some language to express the design typically we go for UML or unified
modeling language to represent the object oriented design or a system.
(Refer Slide Time: 43:05)

So in subsequent lectures we learn about both these approaches namely procedural approach
and DFD as well as object oriented design approach and UML to express those designs. And
we will learn those with case studies so that these become easier to understand and remember.
So with that we have come to the end of the lecture so in this lecture we will quickly review
what we covered?

So we started our discussion on how to for system design now we learnt what is the main idea
behind system design and what are the key concerns. So there are 2 concerns one is where to
start and how to represent where to start? Is basically; the SRS document at the end of
requirement specification stage that is our starting point. So our objective is to implement all
the functions and to represent we need to make use of different languages one example we
have seen graphical language called DFD and there are other languages as well.
Now design happen in 2 phases one is the high level design phase one is the detailed design
phase while going for design our mina objective is to go for modular design so that the code
is manageable. Now to ensure that we have to ensure that whatever design we have come up
with as high cohesion and low coupling. Cohesion and coupling concepts we have discussed
including different types of cohesion and different type of coupling.

And just to emphasize cohesive is the module property whereas coupling is a property
between modules and our objective is to have a design that supports high cohesion within a
module and low coupling between modules then only it will be possible to go for a very good
modular design otherwise our objective of modular design may be compromised. Then we
talked about 2 broad approaches to design one is function oriented approach other one is
objected oriented approach.

For function oriented approach we need to use DFD to express the design for object oriented
approach we go for UML to express the design. In the subsequent lectures we are going to
talk about these design approaches as well as the languages to express them in more details
with case studies for better understanding So that is all for this lecture hope you have enjoyed
and learnt the concept looking forward to meet you all in the next lecture thank you and good
bye.