CHAPTER 1: INTERACTIONAL DESIGN

Lessons:

1. Establishing requirements
2. Design, prototyping, and construction
3. Interaction Design in Practice
4. Introducing Evaluation
5. Evaluation: Inspection, Analytics,a nd Models

The process of Interactional Design

Is it true that Interaction design is?

What is interaction Design?

Interaction design is simply producing usable products that supports the way the people
communicate and interact in their everyday work.

LESSON 1: Establishing Requirements

Objectives:
1. Describe different kinds of requirements;
 2. Allow students to identify kinds of requirements from a simple description;
3. Explain additional data gathering techniques and how they may be used to establish requirements;
4. Enable students to develop a persona and a scenario from a simple description; and,
5. Describe use cases as a way to capture interaction in detail.
How to establish or discover requirements?
In the book of Rogers et al. (2019) on Interaction Design beyond HCI, they discussed that discovering
requirements focuses on exploring the problem space and defining what will be developed. In the case of
interaction design, this includes: understanding the target users and their capabilities; how a new product
might support users in their daily lives; user’s current tasks, goals, and contexts; constraints on the
product’s performance; and so on. This understanding forms the basis of the product’s requirements and
underpins design and construction.

What, How, and Why?

In this lesson, we will consider what is the purpose of the requirements activity, how to capture
requirements and why bother at all.

What is the purpose of the requirements activity?

As previously discussed in HCI, there are two phases of design which was introduced in “The
Process of Interaction Design”. These two phases involve exploring the problem space to gain insights
about the problem and establishing a description of what will be developed.

Requirements may be discovered through targeted activities, or tangentially during product

evaluation, prototyping, design, and construction. In practice, requirements evolve and develop as the
stakeholders interact with designs and learn what is possible and how features can be used. And this can
be repeatedly revisited as discussed in HCI under Iterative SDLC.

How to capture requirements?

Requirements may be captured in several different forms. For some products, such as e-commerce
app, it may be appropriate to capture requirements implicitly through a prototype or operational product.
In all cases, capturing requirements explicitly is beneficial in order to make sure that key requirements
aren’t lost through their iterations.

Going further, there are different kinds of requirements, and each can be emphasized or de-
emphasized by different notations because notations emphasize different characteristics. For example,
requirements for a product that relies on processing large amounts of data will be captured using a
notation that emphasizes data characteristics. This means that a range of representations is used including
prototypes, stories, diagrams, and photographs, as appropriate for the product under development.

Why bother? Avoiding Miscommunication

One of the goals of interaction design is to produce usable products that support the way that
people communicate and interact in their everyday and working lives. Discovering and communicating
requirements helps to advance this goal, because defining what needs to be built supports technical
developers and allows users to contribute more effectively. If the product turns out to be usable or
inappropriate, then everyone will be disappointed.

User-centered design with repeated iteration and evaluation along wit user involvement mitigates
against this from happening. The following cartoon illustrates the consequences of misunderstanding or
miscommunication. The goal of an iterative user-centered approach is to involve different perspective and
make sure that there is agreement. Miscommunication is more likely if requirements are not clearly
articulated.
What are requirements?
A requirement is a statement that specifies what an intended product should do, or how it should
perform. For example, a requirement for an e-commerce website might be that the time to load the images
is less than half a second. Another, less precise requirements might be for customers to find the e-
commerce website appealing. In the later example, the requirements activity would involve exploring in
more detail exactly what would make such a watch appealing to teenagers.

One of the goals of the requirements activity is to identify, clarify, and capture the requirements.
The process of discovering requirements is iterative, allowing requirements and their understanding to
evolve. In addition to capturing the requirements themselves, this activity also involves specifying criteria
that can be used to show when the requirements have been fulfilled. For example, usability and user
experience criteria can be used in this way.

An alternative way to capture what a product is intended to do is via user stories. User stories
communicate requirements between team members. Each one represents a unit of customer-visible
functionality and serves as a starting point for a conversation to extend and clarify requirements. User
stories may also be used to capture usability and user experience goals. Originally, use stories were
normally written on physical cards that deliberately constrained the amount of information that could be
captured in order to prompt conversations between stakeholders.

A user story represents a small chuck of value that can be delivered during a sprint, and a common
and simple structure for user stories is a follows:

• As a <role>, I want <behavior> so that <benefit>.

Example:
As a <traveler>, I want <to save my favorite airline for all my flights> so that < I will
be able to collect air miles>.
As a <customer> I want <to contact customer support> so that < I can get help
with my order>.
As a <customer> I want <to receive an order confirmation> so that < I can ensure
that my purchases were successful>.

Once completed and ready for development, a story consists of a description, an estimate of the
time it will take to develop, and an acceptance test that determines how to measure when the
requirements has been fulfilled. It is common for a user story such as the earlier ones to be decomposed
further into smaller stories, often called tasks.
Different kinds of requirements

Requirements come from several sources: from the user community, from the business community, or as
a result of the technology to be applied. Two different kinds of requirements have traditionally been
identified:

1. Functional requirements
Functional requirements describe what the product will do. Understanding the functional
requirements for an interactive product is fundamental.
2. Non-functional requirements
Non-functional requirements describe the characteristics (sometimes called constraints)
of the product.

For example, a functional requirement for a new video game might be that it will be challenging
for a range of user abilities. This requirement might then be decomposed into more specific requirements
detailing the structure of challenges in the game, for instance, levels of mastery, hidden tips and tricks,
magical objects, and so on. A non-functional requirement for this same game might be that it can run on
a variety of platforms. Interaction design involves understanding both functional and non-functional
requirements.
Suzzane and James Robertson (2013) suggest the following set of requirement types. See Table 1.

FUNCTIONAL REQUIREMENTS 1. The scope of the work

2. Business data model and data dictionary
3. the scope of the product
4. functional requirements

NON-FUNCTIONAL REQUIREMENTS 1. Look and feel requirements

2. Usability and Humanity requirements
3. Performance requirements
4. Operational and environmental
requirements
5. Maintainability and support requirements
6. Security requirements
7. Cultural requirements
8. Compliance requirmements

Data Gathering for requirements

Data gathering for requirements covers a wide spectrum of issues, including wo are the intended
users, the activities in which they are currently engaged and their associated goals, the context in which
the activities are performed, and the rationale for the current situation. The goals of the data gathering is
to discover all the types of requirements relevant for the product. It helps designers gather direct insights
from their target audience/users, understand and analyze user needs and wants, and generate
alternatives. There are several techniques and other approaches used to discover requirements. Some of
which are the following:

1. Interviews
2. Observation
3. Questionnaires
4. Focus group discussion
There are other approaches like documentation such as manuals, standards or activity logs, are a
good source of data about prescribed steps involved in an activity, any regulations governing a task,
or where the records of activity are already kept for audit or safety-related purposes.

In data gathering, it is usual for more than one data gathering technique to be used in order to
provide different perspectives. Examples are observation to understand the context of the activity,
 interviews to target specific user groups, questionnaires to reach a wider population, and focus group
discussion to build a consensus view.
Basic Data Gathering Guidelines

1. Focus on identifying the stakeholders needs

2. Involve all the stakeholder groups/ more than one representative
3. Use a combination of data gathering techniques
4. Support the data gathering sessions
5. Run a pilot session if possible
6. Understand what you are really looking for
7. Carefully consider the means used to record the data during face-to-face data gathering session

Bringing requirements to Life: Personas and Scenarios

User stories captures the essence of a requirement, but neither of them is sufficient on their own
to express and communicate the product’s purpose and vision. Both can be augmented with prototypes,
working systems, screenshots, conversations, acceptance criteria, diagrams, documentation, and so on. In
some cases, capturing different aspects of the intended product in more formal or structured
representations is appropriate.
Two techniques that are commonly used to augment the basic requirements information and to
bring requirements to life are personas and scenarios. Often used together, they complement each other
in order to bring realistic detail that allow the developer to explore the user’s current activities, future use
of new products, and futuristic visions of new technologies. They can also guide development throughout
the product lifecycle.

Scenarios

A scenario is an “informal narrative description” (Carrol, 2000). It describes human activities or tasks in a
story that allows exploration and discussion of contexts, needs, and requirements. It does not necessarily
describe the use of software or other technological support used to achieve a goal. Using the vocabulary
and phrasing of users means that scenarios can be understood by stakeholders, and they are able to
participate fully in development.

Imagine that you have been asked to investigate how a design team working on a large e-
commerce website project shares information. This kind of team includes several roles, such as an UI/UX
design, Project leader, system analyst, front-end and back-end developer, business consultant, and finance
department. On arrival, you are greeted by Project Leader, who starts by saying something like the
following:
 Every member of the team needs to understand the overall purpose, but each take a different
perspective o the design decisions that have to be made. For example, the finance dept will keep an eye
on how things cost, UI/UX design make sure that the design accounts for look and feel of the system
and so on. When the system analyst presents the design concept, each of us will view that concepts
form our own discipline and assess whether it will work as envisioned. This means that we need to share
information about the project goals, the reason for decisions, and the overall budget, as well as drawing
on our own discipline expertise to advise the client on options and consequences.

Telling stories is a natural way for people to explain what they are doing, and stakeholders can
easily relate to them. The focus of such stories is also naturally likely to be about what the users are trying
to achieve, that is their goals. Understanding why people do things as they do and what they are trying to
achieve in the process focuses the study on human activity rather than interaction with technology.
Repeated reference to a particular app, drawing, behavior, or location indicates that it is somehow central
to the activity being performed and that it deserves close attention to uncover the role it plays.
Understanding current behavior also allows the designer to explore the constraints, contexts, irritations,
facilitators, and so on, under which people operate.

Example of user stories with possible scenarios for e-commerce site

User Story 1: As a customer, I want to view product categories so that I can find the type of product I am
interested in.

Scenario 1: Viewing product categories successfully

1. The customer is browsing the homepage.
2. They click on the “categories” section in the menu.
3. The system displays a list of available categories such as clothing, jewelleries, etc.
Scenario 2: No products available in a category

1. The customer navigates to a specific category, such as “presentation clicker”.

2. They click on the category link
3. The system displays a message saying “no product available in this category” and offers
suggestions to browse related categories like “wireless presenter remote”

LABORATORY ACTIVITY: E-COMMERCE WEBSITE REQUIREMENTS

Instruction: Given the functional and non-functional requirements, create a user stories and provide at
least two possible scenarios for each requirement.
Capturing interaction with Use Cases

Use cases focus on functional requirements and capture interaction. Because they focus on the
interaction between a user and the product, they may be used in design to think about the new interaction
being designed, but they may also be used to capture requirements – to think through details about what
the user needs to see, to know about, or to react to. Use cases define a specific process because they are
a step-by-step description. This is in contrast to a user story, which focuses on outcomes and user goals.
Nonetheless, capturing the detail of this interaction in terms of steps is useful as a way to enhance the
basic requirement statement. The style of use cases varies. Two styles are shown in this section.

The fist style focuses on the division of tasks between the product and the user. For example, in
table below which was captured from your activities previously having a scenario.
1. As a client I want my e-commerce website to have a registration and login page so that my
customer can register and login to access my website.

USER AUTHENTICATION

CUSTOMER INTENTION SYSTEM RESPONSIBILITY

● The customer accesses the e-commerce ● The system provides registration page and
website. New user should register to view ask necessary information e.g. name,
products. address, mobile number, email address,
username, password, etc.

● The customer logs in to the e-commerce ● The system verifies the name and
website by entering the username and password if it matches saved info in the
password. database. If it does not match, error
messages will show to the customer.

● The customer forgot his/her password. ● The system provides reset password
button.

● The customer asks to reset his/her ● The system provides recovery page asking
password. for email address to send reset link or
code.

● ●

2. As a client I want my e-commerce website to have a product category so that my customer can
easily navigate their desired product

PRODUCT CATEGORIES
 CUSTOMER INTENTION SYSTEM RESPONSIBILITY

● The customer requests to view the ● The system will display the information
product in product category about the product of selected category

● The customer request to view specific ● The system will display the product
product under the product category. requested by the customer.

3. As a client I want my e-commerce website to have a product search and filtering feature so that
my customer can find specific product and price he/she is looking for.

PRODUCT SEARCH AND FILTERING

CUSTOMER INTENTION SYSTEM RESPONSIBILITY

● The customer wants to view specific ● The system display search bar.
product ● The system will display the information
about the specific product (price, ratings,
descriptions) If not matches, the system
display no results found. And offer other
product similar to the customers’
requests.

● The customer requests to filter some of ● The system will display the filtering page
the product. containing product type, category, size,
price range, color, etc. If not matches, the
system gives fail message. And offer other
product similar to the customers’
requests.

● ●

4. As a client I want my e-commerce website to have a add to cart feature so that my customer can
look for other products before checking out.

ADD TO CART

CUSTOMER INTENTION SYSTEM RESPONSIBILITY

● Provide an “Add to Cart” button on the

product detail page.
● The customer requests to add the desired
● Add selected items to the cart.
product to his/her shopping cart to
● Display a confirmation message to the
review or purchase later.
user.
● Customers add a product to the cart
● The system stores and tracks the
successfully.
information about the product.

● The customer tries to add an out-of-stock ● Display an “out of stock” notification if

item to the cart and wants to know its applicable.
availability status. ● Display add to Wishlist. Notify customers
when the item is back on the market.

● ●

5. As a client I want my e-commerce website to have a checkout feature so that my customer can
checkout products from their cart. /Checkout products desired.

Checkout and Payment Option

CUSTOMER INTENTION SYSTEM RESPONSIBILITY

 ● The customer completes the shopping / ● The system displays the products from
checks out products from his shopping his/her cart. The system provides a select
cart. button so customers can select other
products. The system displays Total price
and checkout button.

● The customer requests to view checkout ● The system will display the order
information. summary containing Receivers Name,
address, mobile phone, and landmark for
delivery purposes.
● The system will display the selected
product details including shop discount.
● The system will display product origin,
estimated delivery and order price break
down (subtotal, shipping fee, shipping
discount, overall total)

● The customer requests to view the ● The system will display the available
payment method. payment methods like COD, Credit/debit
card, GCash, Maya, Online Banking.

● The customer chooses his/her payment ● If COD the system will continue to
method. checkout the page. If not, the system will
ask for the desired payment option. If a
customer chooses online bank payment,
the system will display available banks
linked to the e-commerce site. If so, the
system will display a bank login form to
authorise the bank to link customer bank
accounts to Pay Express subject to bank
terms and conditions.

6. As a customer I want to update my personal information so that I can ensure that my details are
accurate for a smooth shopping experience.

UPDATE CUSTOMER INFO.

CUSTOMER INTENTION SYSTEM RESPONSIBILITY

● The customer updates their account ● Authenticate the user.

information successfully. ● Validate updated data
● Send confirmation notification

● User Enters invalid Email Format ● Display error message

● User fails to confirm current password ● Display error

● Validate password

● User updates shipping address only. ● Validate address format

● Send confirmation notification

7. As a customer I want to receive an order confirmation so that I can ensure that my purchases
were successful.

ORDER CONFIRMATION

CUSTOMER INTENTION SYSTEM RESPONSIBILITY

● The customer updates their account ● Process the payment and confirm order
information successfully. details
● Display confirmation page
 ● Send order confirmation via email
address

● The customer fails to confirm the order ● Process payment. Display payment page.
due to payment issues. ● Display “Try different payment method”.

8. As a customer I want to contact customer support so that I can get help with my order.

CUSTOMER SUPPORT

CUSTOMER INTENTION SYSTEM RESPONSIBILITY

● The customer contacted customer ● Provide a chatbot thru a chat icon on the
support via Chatbot and transferred to website.
Live Chat. ● The chatbot should greet the customer
and ask “How can I help you today?”
● Handle basic queries related to the order.
● Recognize when issue is beyond its
capability or transfer customer to human
agent when requested.
● Connect the customer to a live agent.

● The customer wants to report an issue ● Provide “Contact Us” form.

regarding their order and seek assistance ● Collect all these details
through support ticket. ● Generate ticket with a unique reference
number and provide response time.
● Notify customer via email about status of
their ticket.

9. As a customer I want to access a FAQS section so that I can find quick answers to inquiries.

CUSTOMER SUPPORT

CUSTOMER INTENTION SYSTEM RESPONSIBILITY

● The FAQ section should be accessible ● Update FAQ section

● they can view Order tracking FAQ and
● should be categorized if possible (eg
follow instructions to track their package
orders, payments, shipping, etc)
if unsure in tracking their order.
● customer should be able to search for ●
specific questions

● each FAQ should provide clear, concise

answers
● contact us should be available if the FAQS
don’t resolve the issue.

10. As a customer I want to access a FAQS section so that I can find quick answers to inquiries.
FAQs
CUSTOMER INTENTION SYSTEM RESPONSIBILITY
1. The FAQ section should be accessible • Update FAQ section
• they can view Order tracking FAQ and
2. should be categorized if possible (eg
follow instructions to track their package
orders, payments, shipping, etc)
if unsure in tracking their order.
3. customer should be able to search for •
specific questions
 4. each FAQ should provide clear, concise
answers
5. contact us should be available if the FAQS
don’t resolve the issue.

The second style of use cases is more detailed, and it captures the user’s goal when interacting with
product. In this technique, the main use case describes the normal course, that is, the set of actions most
commonly performed. Other possible sequences, called alternative courses, are then captured at the
bottom of use case.
For example:

1. The product site asks for the name of the customer.

2. The customer provides his/her name.
3. The product asks for mobile number.
4. The customer provides the mobile number.
5. The product asks whether the customer wants to provide alternate email.
6. The customer provides appropriate alternate email.
7. The product asks for password.
8. The customer provides the password.

Alternative courses

1. If the password is invalid:

1.1 the product provides an error message
1.2 the product asks to reset password.
2. If email does not receive reset link:
1.1. The product provides an error message
1.2. The product provides other way to reset password through code using mobile number.
Note that the number associated with the alternative course indicates the step-in normal course
that is replaced by this action or set of actions. Also note how specific the use case is about how
the user and the product will interact compared with the first style.
Understanding and creating use case diagrams

A use case diagram is a visual representation of the interactions between users(actors) and a
system. It helps to outline the system’s functionality and who interacts with which parts of the system.

Key components of use case diagram

1. Actors – represent external entities that interact with the system (e.g., customer, admin). It can be
a person, another system, or an organization.
2. Use cases (Actions) – describe the actions or tasks that the system performs, initiated by an actor
(e.g., “Log in”, “view products”, “search products”. These are represented by ovals or ellipse in the
diagram.
3. Associations – arrows or lines that show the interactions between actors and use cases (actions).
4. System boundary: encloses all the use cases and represents the scope of the system. Its depicted
as a rectangle.
5. Relationships
• Include – indicates a use case (action) that is always performed as part of another use case
(action) or because it’s a mandatory step or always part of the process.
• Extend – represents optional behaviour or feature or extra functionality triggered by
specific conditions or that extends the process of a use case (action).
Steps to Create a Use Case Diagram

1. Identify the actors – external entities that interact with your system (e.g., customer, administrator)
2. Define use cases (actions) – break down the system into specific tasks that the actors need to
perform based from the requirements.
 3. Establish the relationship – connect actors to appropriate use cases (actions). Identify the
relationships between use case (actions)
4. Draw the system boundary – enclose the use cases (actions) within a system boundary to show
the scope of the system
Example of use case diagram
1. Actors: customer, administrator
2. Use cases: Login, register, add to cart, checkout, manage orders, view product, search product
3. Relationships:
• The “Log in” use case includes “Reset Password”.
• The “Checkout” use case extends “Apply Voucher”

Tips for drawing use case diagrams

1. Use simple and clear labels for actors and use cases (actions)
2. Focus on the key interactions between users and the system
3. Ensure relationship are clear and logical between use cases
4. Keep the diagram readable; avoid overloading with too much information. The actors, use cases
(actions) and relationships and system boundary are the only entities that is in your use case
diagram.
Tools to create use case diagrams

DRAW.IO

Draw.io is a free diagramming tool where you can easily create use case diagrams, flow charts, ER
diagrams, and mock ups and so on. It’s widely used for designing UML diagrams because of its simplicity
and broad range of features. It has a free and offline version.
Key features of draw.io:

• Has online and offline version.

• Wide range of diagram types.
• Drag-and-drop interface. Easy to use with pre-built shapes and elements for diagramming
• Collaboration: you can collaborate with others by sharing your diagram (online version) making it
ideal for your group projects.
• File integration: diagrams can be saved to your device, or directly to cloud services like Google
Drive, OneDrive, etc. for easy access and sharing.
• Customizable templates. Offers library of templates to get started quickly with your diagrams.
• Export options: export your diagrams as PNG, JPEG, SVG, PDF and other formats, making it easy
to integrate them into reports or presentations.
How to create a use case diagram on draw.io:
 1. For online, visit the website draw.io.
2. For offline, just install it.
3. Create a new diagram: choose “blank diagram” or select template from the given category.
4. Choose shapes: use the left toolbar to find shapes like actors, use cases (oval) and system
boundaries (rectangle).
5. Drag and drop: drag shapes onto the canvas and arrange them to represent your system
6. Label the elements: click on each shape to label actors, use cases (actions), and system
boundaries.
7. Connect elements: use arrow to show associations between actors and use cases, and include and
extend relationship if needed.
8. Save and export: save the diagram to your device or cloud, and export it in your preferred format.

LABORATORY ACTIVITY: Based on the user stories and scenarios from your previous e-
commerce activity, create a use case diagram using draw.io.

Key points:

• A requirement is a statement about an intended product that specifies what is expected to do or how
it will perform.
• Articulating requirements and defining what needs to be built avoids miscommunication and
supports technical developers and allows users to contribute more effectively
• Traditional kinds of requirements: functional, and non-functional requirements.
• Scenarios provide a story-based narrative to explore existing behaviour, potential use of new products
under development, and futuristic visions of technology use.
• Use cases capture details about an existing or imagined interaction between users and the products.
LESSON 2: DESIGN, PROTOTYPING, AND CONSTRUCTION IN DESIGN THINKING
It is often said that users can’t tell you what they want, but when they see something and get to
use it, they soon know what they don’t want. Prototyping provides a concrete manifestation of an idea—
whether it is a new product or a modification of an existing one—which allows designers to communicate
their ideas and users to try them out.

What is Design thinking?

In the book of Rogers et al. (2019), they stressed that design thinking has been described as an
approach to problem-solving and innovative design that focuses on understanding what people want and
what technology can deliver. It is derived from professional design practice, and it is often viewed as having
five stages that together evolve a solution: the empathize, define, ideate, prototype, and test.

It was also defined by Dam, R. F., et al (2024). as an iterative process in which you seek to
understand your users, challenge assumptions, redefine problems and create innovative solutions which
you can prototype and test. The overall goal is to identify alternative strategies and solutions that are not
instantly apparent with your initial level of understanding.
It is more than just a process; it opens up an entirely new way to think, and it offers a collection of
hands-on methods to help you apply this new mindset. In essence, design thinking resolves around a deep
interest to understand the people for whom we design products and services; help us observe and develop
empathy with target users; enhance our ability to question (question the problem, assumptions, and
implications); proves extremely useful when you tackle problems that are ill-defined or unknown; and
involves ongoing experimentation through, sketches, prototypes, testing and trials of new concepts and
ideas.

Figure 2.1. Five phases of design thinking

A. EMPATHIZE
B. DEFINE
C. IDEATE
D. PROTOTYPE
E. TEST