design method alibek barlybayev, [email protected] almaz kungozhin, [email protected]...

PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS (544319-TEMPUS-1-2013-1-FR-TEMPUS-JPCR)

DESIGN METHODAlibek Barlybayev, [email protected]

Almaz Kungozhin, [email protected] -5


1. User Centered Design2. Task and Activity analysis3. User Modeling4. What is personas5. What is scenarios6. Task model formalism

7. Formal specification8. Design technics

8.1 prototypes8.2 storyboards8.3 sketching

Agenda2


User Centered Design3


User Centered Design

Design: Including Users during whole process Iterative process

Understanding and Specifying the context of use

Understanding and specification of user requirements

Proposing design solutions (from the abstract to the code)

Solutions Evaluation regarding the requirements

4


User Centered DesignSome basics principles

5


Needs Analysis6

Task and Activity analysis

PROfessional network of Master’s degrees in Informatics as a Second Competence – PROMIS (544319-TEMPUS-1-2013-1-FR-

TEMPUS-JPCR)

Process of analyzing and documenting how people perform their jobs or activities

Task-subtask decomposition

7

Task Model Example- Borrow Book

Sequences added as annotations

Goal

Tasks tocomplete goal

Subtasks tocarry outone task


TEMPUS-JPCR)

8


Task Model Example- Another representation

0. In order to borrow a book from the library 1. go to the library 2. find the required book

2.1 access library catalogue2.2 access the search screen2.3 enter search criteria2.4 identify required book 2.5 note location

3. go to correct shelf and retrieve book4. take book to checkout counter

9


Task and Activity analysisProcess Improvement Analyzing Processes Understand and define organizational process

requirements Perform problem identification and analysis Conduct organizational context analysis Business process mapping Process requirement engineering Workshop facilitation Enterprise business process model analysis

10


Needs Analysis: User modeling11


User modeling12


User modeling: Types

Static user models Dynamic user models Stereotype based user models Highly adaptive user models

13


User modeling: Methods

Asking for specific facts while (first) interacting with the system

Learning users' preferences by observing and interpreting their interactions with the system

A hybrid approach which asks for explicit feedback and alters the user model by adaptive learning

14


Needs Analysis: personas15

Needs Analysis: personas


TEMPUS-JPCR)

16

In user-centered design and marketing, personas are fictional characters created to represent the different user types that might use a site, brand, or product in a similar way.

Marketers may use personas together with market segmentation, where the qualitative personas are constructed to be representative of specific segments.

The term persona is used widely in online and technology applications as well as in advertising, where other terms such as pen portraits may also be used.


Needs Analysis: personas17


Needs Analysis: scenarios

18


Needs Analysis: scenarios19


Needs Analysis: scenarios (1) Many types of scenario are in use in system development.

Alexander and Maiden list the following types: Story: "a narrated description of a causally connected

sequence of events, or of actions taken". Brief User stories are written in the Agile style of software development.

Situation, Alternative World: "a projected future situation or snapshot". This meaning is common in planning, but less usual in software development.

Simulation: models to explore and animate 'Stories' or 'Situations', to "give precise answers about whether such a scenario could be realized with any plausible design" or "to evaluate the implications of alternative possible worlds or situations".

20


Needs Analysis: scenarios (2) Storyboard: a drawing, or a sequence of drawings, used to

describe a user interface or to tell a story. This meaning is common in Human–computer interaction to define what a user will see on a screen.

Sequence: a list of interactive steps taken by human or machine agents playing system roles. The many forms of scenario written as sequences of steps include Operational Scenarios, Concepts of Operations, and Test Cases.

Structure: any more elaborately-structured representation of a scenario, including Flowcharts, UML/ITU 'Sequence Charts', and especially in software development Use cases.

Negative scenarios or misuse cases may be written to indicate likely threats which should be countered to ensure that systems have sufficient security, safety, and reliability. These help to discover non-functional requirements.

21


Needs Analysis:task model formalism22


Needs Analysis: task model formalism

Task Models describe how to perform activities to reach users' goals.

Of the relevant models in the human-computer interaction field, task models play an important role because they represent the logical activities that should support users in reaching their goals. Knowing the tasks necessary to goal attainment is fundamental to the design process. The need for modelling is most acutely felt when the design aims to support system implementation as well.

If we gave developers only informal representations (such as scenarios or paper mock-ups), they would have to make many design decisions on their own, likely without the necessary background, to obtain a complete interactive system. Task models represent the intersection between user interface design and more systematic approaches by providing designers with a means of representing and manipulating an abstraction of activities that should be performed to reach user goals.

23


Needs Analysis: formal specification24


Needs Analysis: formal specification

Task models can be represented at various abstraction levels. When designers want to specify only requirements regarding how activities should be performed, they consider only the main high-level tasks.

When designers aim to provide precise design indications then the activities are represented at a small granularity, thus including aspects related to the dialogue model of a user.

The subject of a task model can be either an entire application or one of its parts. The application can be either a complete, running interactive system or a prototype under development. The larger the set of functionalities considered, the more difficult the modelling work. Tools open up the possibility of modelling entire applications, but in the majority of cases what designers wish to do is to model some sub-sets in order to analyse them, and to identify potential design options and better solutions.

25


HMI Design technics: prototypes26


HMI Design technics: prototypes

Objectives We shall cover

Design guides What they look like Perils of using them

Rationale: It is impossible for designers to be expert in all

the disciplines of HCI, so guidelines are constructed to guide non-experts in matters such as psychology, art, sociology etc.

27


HMI Design technics: prototypesDoing the stuff So, you have conducted requirements

analysis, read your design guides and considered the users’ mental models

It is time to actually make something That something is a prototype

Most modern lifecycles require iteration about a prototype

28


HMI Design technics: prototypes What is a prototype

Cardboard box, storyboard Piece of software Chunk of plywood (Jeff Hawkins - Palm Pilot)

Dummy box

29


HMI Design technics: prototypes Why Prototype?

Evaluation and feedback are central to interaction design

Stakeholders can see, hold, interact with a prototype more easily than a document or a drawing

Team members can communicate effectively You can test out ideas for yourself It encourages reflection: very important aspect of

design Prototypes answer questions, and support

designers in choosing between alternatives

30


HMI Design technics: prototypes What is Prototyped?

Technical issues Work flow, task design Screen layouts and information display Difficult, controversial, critical areas

31


HMI Design technics: prototypes Low Fidelity

Uses a medium which is unlike the final medium, e.g. paper, cardboard

Is quick, cheap and easily changed Examples: sketches of screens, task

sequences, etc ‘Post-it’ notes storyboards ‘Wizard-of-Oz’

32


HMI Design technics: prototypes Wizard of Oz -

research experiment in which subjects interact with a computer system that subjects believe to be autonomous, but which is actually being operated or partially operated by an unseen human being

33


HMI Design technics: prototypes Low-Fidelity Examples

34


HMI Design technics: prototypes High Fidelity

Uses materials that you would expect to be in the final product.

Prototype looks more like the final system than a low-fidelity version.

For a high-fidelity software prototype common environments include Macromedia

Director, Visual Basic, and Smalltalk. Danger that users think they have a full

system…….see compromises

35


HMI Design technics: storyboards

36


HMI Design technics: storyboards Borrowed from the film/animation/comic industries

One panel = One Scene Presented to a group of people Gauge their reactions, understanding Takes time up front, saves time later

Intended to visualize our scenarios Provide a mechanism to gracefully move from

conceptual design to screen design Allow us to make mistakes early, in paper (cheap

and quick), instead of later, in software (expensive and tedious)

37


HMI Design technics: storyboards General Concepts Screens

You are not designing the detailed interface yet Include general layout, navigation elements, core concepts Capture relevant information, remove extraneous information

Scenes Personas in their physical context Cultural/Interpersonal relationships or handoffs

Show sequencing of main ideas Although these can be quite visually attractive, they are not

works of art: Black & white, pencil Quick No renderings!

38


HMI Design technics: storyboardsTips Use your scenarios and personas! Use long paper Use one square per scene Number each scene Visually group similar scenes into conceptual

tasks Include a text description of each scene Call out interesting or important aspects into

the margins and annotate them

39


HMI Design technics: sketching

40


HMI Design technics: sketching

41


HMI Design technics: Responsive Web Design

42


Responsive Web Design

The goal of RWD is to deliver a quality experience to users no matter how large or small the display they use is and no matter what device it is being viewed on

43


Responsive Web Design

RWD is not only about changing the way elements are displayed in a web page

RWD is also about how to provide easy reading and navigation with a minimum of resizing, panning, and scrolling across a wide range of different devices (from desktop computers monitors to mobile phones).

RWD techniques are compiled in design patterns, common solutions to different design problems (layout patterns, navigation patterns, menu patterns, form patterns)

44


Questions?

Thank you45

design method alibek barlybayev, [email protected] almaz kungozhin, [email protected]...

Documents

competence promis

jpcr design

jpcr process improvement

jpcr hmi

process iterative process

design solutions

task model example

design technics