DESIGN RULES , PROCESS OF DESIGN, USER FOCUS

INTERACTION DESIGN BASIC
• what is design?
• A simple definition is: achieving goals within constraints
This does not capture everything about design, but helps
to focus us on certain things:
• Goals What is the purpose of the design we are intending
to produce? Who is it for? Why do they want it?
• For example, if we are designing a wireless personal movie
player, we may think about young affluent users wanting to
watch the latest movies whilst on the move and download
free copies, and perhaps wanting to share the experience
with a few friends.

THE GOLDEN RULE OF DESIGN
• Part of the understanding we need is about the
circumstances and context of the particular design
problem.
• We will return to this later in the chapter. However,
there are also more generic concepts to understand.
• The designs we produce may be different, but often
the raw materials are the same.
• This leads us to the golden rule of design:
understand your materials.

TO ERR IS HUMAN
• It might sound demeaning to regard people as
‘materials’, possibly even dehumanizing.
• In fact, the opposite is the case: physical materials
are treated better in most designs than people.
• This is particularly obvious when it comes to failures

THE CENTRAL MESSAGE – THE USER
• In this book you will find information on basic psychology,
on particular technologies, on methods and models.
• However, there is one factor that outweighs all this
knowledge.
• It is about attitude. Often it is said that the success of the
various methods used in HCI lies not in how good they are,
but in that they simply focus the mind of the designer on
the user.
• This is the core of interaction design: put the user first,
keep the user in the center and remember the user at the
end.

LOCAL STRUCTURE
• Much of interaction involves goal-seeking behavior. Users
have some idea of what they are after and a partial model
of the system.
• n an ideal world if users had perfect knowledge of what
they wanted and how the system worked they could
simply take the shortest path to what they want, pressing
all the right buttons and links.
• However, in a world of partial knowledge users meander
through the system. The important thing is not so much
that they take the most efficient route, but that at each
point in the interaction they can make some assessment of

HCI IN THE SOFTWARE PROCESS
• Within computer science there is already a large subdiscipline
that addresses the management and technical issues of the
development of software systems – called software engineering.
• One of the cornerstones of software engineering is the software
life cycle, which describes the activities that take place from the
initial concept formation for a software system up until its
eventual phasing out and replacement.
• This is not intended to be a software engineering textbook, so it
is not our major concern here to discuss in depth all of the issues
associated with software engineering and the myriad life-cycle
models.

ACTIVITIES IN THE LIFE CYCLE
• A more detailed description of the life cycle activities is
depicted
• The graphical representation is reminiscent of a waterfall,
in which each activity naturally leads into the next.
• The analogy of the waterfall is not completely faithful to
the real relationship between these activities, but it
provides a good starting point for dis- cussing the logical
flow of activity.
• We describe the activities of this waterfall model of the
software life cycle next.

formality gap between the real world and
structured design

USABILITY ENGINEERING
• The ultimate test of a product’s usability is based on
measurements of users’ experience with it. Therefore,
since a user’s direct experience with an interactive
system is at the physical interface, focus on the actual
user interface is understandable.
• The danger with this limited focus is that much of the
work that is accomplished in interaction involves more
than just the surface features of the systems used to
perform that work.

PROBLEMS WITH USABILITY ENGINEERING
• The major feature of usability engineering is
the assertion of explicit usability metrics early
on in the design process which can be used to
judge a system once it is delivered.
• There is a very solid argument which points
out that it is only through empirical
approaches such as the use of usability
metrics that we can reliably build

ITERATIVE DESIGN AND PROTOTYPING
• A point we raised earlier is that requirements for an interactive
system cannot be completely specified from the beginning of the
life cycle.
• The only way to be sure about some features of the potential
design is to build them and test them out on real users.
• The design can then be modified to correct any false
assumptions that were revealed in the testing.
• This is the essence of iterative design, a purposeful design
process which tries to overcome the inherent problems of
incomplete requirements specification by cycling through several
designs, incrementally improving upon the final product with
each pass.

WARNING ABOUT ITERATIVE DESIGN
• Though we have presented the process of iterative
design as not only beneficial but also necessary for
good interactive system design, it is important to
recognize some of its drawbacks, in addition to the
very real management issues we have already
raised.
• The ideal model of iterative design, in which a rapid
prototype is designed, evaluated and modified until
the best possible design is achieved in the given
project time, is appealing.

DESIGN RATIONALE
• In designing any computer system, many decisions are made as the product
goes from a set of vague customer requirements to a deliverable entity.
• Often it is difficult to recreate the reasons, or rationale, behind various
design decisions.
• Design rationale is the information that explains why a computer system is
the way it is, including its structural or architectural description and its
functional or behavioral description.
• In this sense, design rationale does not fit squarely into the software life
cycle described in this chapter as just another phase or box.
• Rather, design rationale relates to an activity of both reflection (doing
design rationale) and documentation (creating a design rationale) that
occurs throughout the entire life cycle.

DESIGN RULES , PROCESS OF DESIGN, USER FOCUS

More Related Content

Similar to DESIGN RULES , PROCESS OF DESIGN, USER FOCUS

More from mohanrajm63

Recently uploaded

DESIGN RULES , PROCESS OF DESIGN, USER FOCUS