2 AI and the HCD Process

The plan step is about planning, defining and organizing the HCD process → and therefore creating project plan

Planning activities are:

• appointing responsibilities and resources for the human centered design (HCD) activities.

• writing a project plan

• articulating objectives

The analyze step is about creating a description of the context of use.

• To describe the context of use there are different activities:

  • User group profiles

  • Stakeholders

  • Personas

  • As-is scenarios

  • Task models

  • User journey maps

The context of use describes

• Interviews — gather data by questioning selected individuals to understand the context of use.

  • Contextual interviews → interviews that take place at the location where the user’s interaction with the interactive system usually takes place.

• Observation — gather contextual data about the user needs by watching users perform tasks related to the interactive system.

• Focus Groups — focused discussion where a moderator leads a group of participants through a set of questions on specific topics.

• A user is a person that interacts with a system to perform a task.

• User groups are groups of users with similar characteristics and contexts of use (related to the system).

• A user group profile, is a generalized description of a user group.

• A Stakeholder is an individual or an organization with an active interest in an interactive system.

• All users are stakeholders, but not all stakeholders are users.

• Market requirements or organisational are requirements from stakeholders who are not users.

• A persona is a fictive description of a realistic user and of what they intend to do when using an interactive system.

  • they typically have a name, background, goals, aspirations, knowledge and interest about the interactive system.

• They are created using empirical data from observations or interviews

• Different persona types:

  • Primary persona → product must satisfy primary persona without disenfranchising any of the others

  • Secondary personas → would be satisfied by product for primary persona with a few additional needs addressed

  • Negative personas → someone who the product is specifically not designed for

• An As-Is Scenario is a narrative text description of the procedure a specific user currently follows to complete tasks.

• It describes the real-world situation including goals, tasks, environment, and resources.

• Example: “John Miller is a business traveller who often takes flights in the course of a week. He prefers to take his car to the airport. But every now and then he misses a flight and then regrets not having taken a taxi or tram to the airport. He simply underestimates the queues at the front of the car park and the walking time to the gate.”

It’s a description of the subtasks within a task that have to be carried out in order to reach the user’s goals.

• they should be written so that the users can understand and validate them

It should describe:

• contextual preconditions

• the steps needed for the task,

• the intended outcome of the task.

• A User Journey Map is a graphical or tabular description of all encounters users have with an interactive system, covering all touchpoints that influence UX.

• While an As-Is Scenario is a narrative focused on a single task flow, a journey map is broader — it can span from product discovery through purchase to usage.

• It is particularly useful as a communication tool for stakeholders.

• The outcome are precise and measurable user requirements that the interactive system should meet.

• The components are:

  • User needs identified in the analysis phase.

  • User requirements derived from the user needs.

• User needs are prerequisites necessary for a user to achieve a goal within a context of use.

• Requirements must be met by an interactive system (must be verifiable) to satisfy an agreement, standard, or specification. They are derived from user needs.

  • market requirements → maximize business opportunities, purchases and use

  • organizational requirements → organizational rules user have to follow while conducting the task

  • user requirements → basis for design and evaluation of an interactive system to meet the identified user needs.

• User stories are the agile software requirements.

• They are statements of intent describing something the system needs to do for a user.

  • "As a <user role / persona>, I can <activity> so that <business value>."

• They are short, user-focused, and intentionally non-prescriptive about the implementation.

The design step is about producing a design solution to meet the user requirements.

• For that the user needs and requirements are converted into a working interactive system (design solution).

• Inputs for the design activity:

  • context of use

  • user requirements

  • principles, guidelines, standards

  • conceptual models/theories

• Possible design outputs:

  • Use scenarios

  • Storyboards

  • Low fidelity prototypes

  • Wireframes

  • Information architecture (navigation structure)

  • High fidelity prototypes

  • Style guides

The process is iterative — each stage feeds back into the others.

1. Early Design converts user needs and requirements into use scenarios, storyboards, and user journey maps.

2. First Sketches produces wireframes, low-fidelity prototypes, information architecture (and navigation structure).

3. Refined Design produces high-fidelity prototypes, visual design, and a style guide.

A narrative text description that describes a usage situation with the interactive system.

• it provides an early basis for discussions about what the future interactive system could be like for the user (before prototypes)

  • “Before leaving for the airport, John Miller checks the availability at the airport car park with his new application. If enough parking spaces are available, he reserves one with his new application and then calmly drives to the airport. He knows that since the application has been launched there is a separate entry for cars with reservations”.

A comic style visual frame illustrating the user-system interaction (envisioning).

• Like a use scenario, but represented like a comic book

A limited representation of an interactive system that can be used for analysis, design and usability evaluation.

• facilitates early evaluation of a system, when changes are still cheap

• increases user interest in the new interactive system

• shows stakeholders a concrete example of the plan

• provides specification for the implementation (for high fidelity prototypes)

A low-cost, simple illustration of a design or concept used to gather feedback from users and stakeholders early in the design phase.

• often uses paper, pens, sticky notes. Or prototyping tools for screen mockups.

A wireframe is a screen or page in a low-fidelity prototype for a graphical user interface, comprised of lines, rectangular boxes, and text that represent the intended interaction design.

• It is intentionally simple — no colors, no real content — focusing purely on layout and structure.

Its the naming and structuring of the information that must be accessible to the user. Typically delivers:

• data model and content from the user perspective

• words used in user interface for navigation and content

• navigation structure (e.g. menu structure, site map)

• A high-fidelity prototype is a software prototype of the user interface that more closely resembles the finished interactive system (realistic visuals, interactions, and content).

• It is used in later stages particularly as a specification for developers and for realistic usability evaluation.

The evaluation is about finding out if the interactive system or the prototype meets the user requirements, principles and guidelines.

• The outcome is an evaluation report that determines if the system fulfills all requirements, principles and guidelines.

• The usability evaluation provides information about the usability of an interactive system.

• A heuristic evaluation is an expert-based usability inspection in which a system is compared to a predefined list of heuristics (design principles).

• It is a quick and cost-effective method that does not require real users.

They are a usability evaluation in which representative users perform specific tasks to identify usability problems, or to measure the effectiveness, efficiency and user satisfaction. Steps:

1. Prepare the test → write test plan, test script, usability test tasks, recruit participants

2. Conduct the test session → briefing, pre-session interview, usability task solving, post-session interview

3. Report the results → write the usability test report, communicate findings.

• moderated ones have moderators that encourage usability test participants to think aloud during the session, to understand the thought process.

• unmoderated ones are without moderator.

Rooms specially equipped for usability tests or focus groups.

• they often consist of a test room (for test participants)

• and an observation room where stakeholders can watch the test.

A document that describes the results of a usability test. Includes:

• executive summary

• findings

• test scripts used

• screenshots or pictures of important usability findings.

It’s a usability evaluation made by one or more evaluators, who identify potential usability problems and deviations from established principles, heuristics, guidelines and user requirements.

• unlike usability tests, usability inspections do not involve users.

A usability evaluation where users are asked to fill a questionnaire based on their experience using an interactive system.

Usability is a subset of UX.

• Usability covers what happens during actual use, specifically satisfaction, effectiveness and efficiency.

• UX is broader and includes the expectations before use and the fulfilment of expectations after use.

• A system can be usable, but still deliver a poor UX if it fails to meet expectations and leaves users unsatisfied.

• AI is the ability of a machine to perform cognitive functions associated with human minds: perceiving, reasoning, learning, problem solving, decision-making, and creativity.

• The six disciplines are:

  • Natural Language Processing (communicating in human language),

  • Knowledge Representation (storing knowledge),

  • Automated Reasoning (answering questions, drawing conclusions),

  • Machine Learning (adapting and detecting patterns),

  • Computer Vision & Speech Recognition (perceiving the world),

  • Robotics (manipulating objects and moving).

• LLMs are transformer-based neural networks that predict the next token in a sequence.

• Training happens in three stages:

  1. Pre-training → self-supervised learning on massive text to capture linguistic patterns

  2. Instruction Fine-Tuning → training on curated input-output pairs to improve helpfulness

  3. Reinforcement Learning with Human Feedback → human labelers rank outputs, a reward model is trained, so that the policy is optimized toward the preferred behavior

• Analysis phase → AI can generate synthetic/artificial users and personas, but they must be validated with real users.

• Specify phase → AI can help analyze and convert user needs into user requirements, or complete and improve the requirements.

• Design phase → AI code generation can turn wireframes or descriptions into working prototypes.

• Evaluation phase → AI can automate heuristic evaluation, score UI quality, test a prototype and verify if requirements are met.

• AI bias → LLMs can follow stereotypes or under/over represent user groups (e.g. when creating personas).

• Anchoring → In the design phase, when AI generates a design solution, designers tend to anchor that and stop exploring alternatives.

• Hidden assumptions → Design decisions that are not explicitly made. If unchallenged they can lead to a system that does not meet real user needs.

• AI outputs can be over-optimistic or shallow. They reflect training data patterns and not real user behavior. They should be treated as hypotheses to validate, not findings.

• AI performance varies. It gets worse when the design improves and it tries to catch subtler, later-stage issues.

→ Therefore humans should oversee and interpret AI outputs instead of acting on them blindly.