Design and Implementation of Human – Computer Interfaces

[Link] 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.