HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or...

43
http://www.cs.tut.fi/ihte HCPro Lecture 12 (25.2.2014): Integrating user experience into product development Jarmo Palviainen

Transcript of HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or...

Page 1: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

http://www.cs.tut.fi/ihte

HCProLecture 12 (25.2.2014):

Integrating user experience into product development

Jarmo Palviainen

Page 2: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Topics of the lecture

• Usability as part of product development• Why integrate• Challenges• How to• Examples

• Role of UX experts/teams in the organization

• A little about Usability Maturity Model• Processes, maturity level, basic processes• How to…

Page 3: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

What is integration?

Integrating HCD with other SE (software engineering)activities aims to merge the two processes in such away that HCD actions will be performed as part of thecompany SE process.• Usability is institutionalized when usability

engineering has become a routine part of productdevelopment and “usability practitioners are fullyaccepted and well understood part of the designprocess”.

• “a strategy is developed which leads to key usabilitybenefits and supports overall business objectives”.

Page 4: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Why HCD should be integrated?

• HCD is natural part of product development (PD) ofsuccessful products

• When integrated, it cannot be left out because of resourcereasons

• It’s easier to apply a ready process rather than each timechoose the appropriate methods for different stages of theprocess

• HCD cannot be done separately• If not integrated, HCD/UX can be sold (or left UNSOLD) to

the customer as a separate extra service• What if software architecture was treated the same way? E.g. offer

the customer a project, where architecture design is left out or thecoders do it among their other work as much as they can.

Page 5: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Goal from a real case

• Projects have multidisciplinary teams• business management, marketing, customer support, maintenance,

assembly, mechanical & electronics design, user, sw design, graphicaldesign, UX expert

• Products have defined levels of usability• The PD process has established parts supporting

usability• In addition to UX expert, a remarkable part of PD

personnel knows UX design and user study methods

Page 6: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Challenges of integration

• HCD and software development have developedseparately + Young fields

• HCD terminology confusing• Only little know how in many companies• The standard HCD process is not possible to

implement in a straightforward manner• Too generic model which needs to be applied to the specific

company/field• Applying requires decent amount of expertise

Page 7: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

How to integrate?

• Two main approaches• ”Renew the whole process”

• Not recommended (change resistance, price of the change)• Make it part of the current process

• Recommended (”policy of small steps”)• E.g. some additions to project checkpoints• What if the current process is not specified?

• Both require knowledge and know how• Consulting/internal talents

Page 8: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Changes that follow Integration

• Attitudes• Influences the whole company and its values

• A new position for an employee does not change anythingpermanently

• Change management/leadership, change agent• Totalitarism! From customer centrism to user/human centrism• Allowing also a certain level of failures

• Training and reflection• Understanding the benefits• Different professions need to work together and respect each other• Discussion!• Learning methods and processes

Page 9: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

What it takes to integrate

• Management support• Change starts from management which gives the

resources and supports the change• Who is given what responsibilities

• An appropriate process• Individual for each company• Milestones, timing (in project planning level)

• Appropriate tools and methods• Training

Page 10: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Change resistance & myths

•Beliefs, attitides, myths• E.g. ”usability is a matter of opinion”,

” usability is not important”,” usability is created in testing”

•Change resistance• There will be changes in the organization, processes, habits,

responsibilities and in power distribution• New roles, experts, procedures, milestones, responsibilities• It’s natural that people have fears and doubts e.g. about their

own position (weakening)

Page 11: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

• Incentives• Individual incentives are needed to promote change

• What is measured and rewarded, counts• Also take care of: motivation, attitude towards work and how it is

experienced as meaningful

• Conflicting interests• Technical: better UI vs. need for more memory & CPU power• Individuals: urge to try out new (not so functional) technologies• Social and team factors: making compromises may undermine UX• Business goals: urge to keep the current product portfolio without the

need for extra training

Classical problems, part 1

Page 12: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Classical problems, part 1

•Organizational structures• Affect on the product

• Separate parts & organizations• Ease of organizing projects vs. usability

Team

Team Team

TeamTeam

Team

Team

Lead

Lead

Page 13: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

• Organizational conventions• Separation of designers and implementers• Separated organizations under different management

• Marketing, production, training…• Formal communication

• Missing efficient tools• Focus on system analysis, not on the user• Copying former structure of work

• Inefficiency of manual world transferred to digital

Classical problems, part 3

Page 14: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Change motivators

•Fiasko•Strong individuals (Steven Jobs at )•Market need, competition•Corporative objectives•Consultancy•Training

Page 15: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Success factors

• Credibility. You need:• Demonstration of special skills• Ability to understand technical and organizational factors

•Communicate UX requirements effectively•”Buy-in”

• Actions done as part of the design work

• Engineering approach• Product development is mostly engineering anyway• You need to be able to understand the ”engineering reasons” at

least in high level – and to make your point in similar terms, notonly in ”UX-language”

Page 16: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Success factors

• Alliance (as opposed to UX-police)• Invest in succeeding together, not in inspecting and failing separately

and afterwards•Well defined end results

• Answering to questions related to product specifications or UXmethods

• Clear reporting about found problems• Managing expectations

• UX work does not solve all problems• Point out the added value

• Rationalize the economical feasibility• Use methods that can demonstrate the benefits!

• Demonstrate the different methods and results• Testing is efficient and concrete way of demonstrating benefits in the

early stage• It should not be the only used method!

• Observations, paper prototyping, Contextual Design…

?

?

Page 17: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Success factors in integration

• Support from the management• Resources and the motivation for the change• Communication

• Why integrating• What is the goal• How to reach that goal• What is going to change

• Organizing, recruiting, division of roles and authority• ”Usability Champion”, ”UCD evangelist”• Team/person responsible, in the beginning possibly

consultancy• Appropriate process

• Suited for the company, takes the current processes in toaccount

• Milestones, time tables (in project planning level)• Appropriate tools and practices

• Handling and sharing information• Document templates, forms, style guides

• Training[Palviainen 2008]

Page 18: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Success factors in integration• A high-level usability chief, director or above. One single

responsible person who reports on the same level as thedevelopment and marketing leaders.

• The usability team either as a part of product management, ormarketing or development

• Power re-definition; authorizing the usability team. UX teamnot seen as a service organization

• Communication and awareness of UX or HCD both inside andoutside of the organization

• Embedding HCD both into formal and informal processes;changing both processes and practicalities in the company

• Clear funding. Preferably one single source of funding or setpercentage from each organization line

[Viikki, Palviainen 2011]

Page 19: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Tasks of an established UX team

• Maintaining activity (and esteem)• ”Missionary work”• Training• Guidance• Standards• Testing• Metrics• Responsibility• Reporting to the management

Page 20: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Organizing UX work in a company

• Centralized vs. distributed ÚX work• Centralized:

• Group of experts from which support and training is requested• ”Resource pool” – ordering services (often too late)

• Distributed:• Experts as part of development teams

• Consultancies, partners• Challenge: Outsiders don’t know the product or the user well enough• To what extent outsourcing UX work is possible?

• ”Everyone is a UX expert”• Challenge: no one is an expert?• Developing expertise throughout the organization is important

• Still specialists are needed, who else would take care ofimproving, instructing, training etc.

• Combination of centralized and distributed model can workthe best

• Differences between small and big companies

Page 21: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

The role of an UX expert in a company

• UX expert’s role at best is showing directions in prod.dev. projects based on user needs and visions.

• Includes also ”basic usability work”: user tests, interviews, writing andreviewing reports and publications etc.

• Both technical and process know how needed to haveimpact through the whole company, not only individualprojects

• In companies with low maturity in UX the role is alsolobbying & pioneering

• Communication skills!

Page 22: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

http://ohjplone.cs.tut.fi:8080/usabilitymateWarning: not updated in a while…

Page 23: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

HCD-process (in companies followingwaterfall –style process)

Page 24: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

An example of a real process developmentproject: IHTE & Metso Automation 2007-2010

• Interviews & questionnaires (2-4 weeks)• Tuning the dev. process (~2 months)

• Decide: Immediate and future changes

• Pilot cases (~2 months)• IHTE experts involved when necessary• Trying out and selling the methods, works also as training

• In parallel, e.g. :• Training about usability (methods, concepts)• Creating forms, document templates• Documenting user data

Page 25: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Chronology…

Page 26: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Status in 2010:• New processes implemented• Document templates, gateways

and instructions done• First projects started in the new

way

ProposalSurvey andInterview HCD Implementation

Institutionalized HCD processand practicalities

Leads &Manages HCD

work

ExecutiveUsability Group

Practices HCD

Everybody

Discusses andadvises in

usability relatedissues

Usability Clinic

Piloting

CI

Paperprototyping

Heuristicevaluation

Usabilitytesting

Observation

UMA

Participantobservation

Interviewingmanagers

PreliminaryproposalFindings

Support&Observation

Communication

Education&Training

Measuring&Verifying

UMA

Page 27: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Metso Innovation process & suggestedHCD-methods (slightly generalized)

Page 28: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

The greatest changes to previousconventions

• The level of usability criticality is chosen when setting up a project(default level is 2):

1. Usability critical project2. Usability attentive project3. Project ignoring usability (No user interface whatsoever)

- Definitions about what HCD-methods to use in levels 1&2.

- Earlier usability team was split in two: ”clinic” + ”strategic HCD”

Page 29: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Methods in level 1 or 2 projects

Usability critical Usability attentive

G0 Preliminary decision of the usability level Preliminary decision of the usability level

G1 Rough metrics and user groups, feedbackanalysis, user and context study, competingproduct evaluation

Feedback analysis, final usability level

G2 Task analysis, plans for feedback gatheringand usability testing

The user, tasks and context are defined,usability requirements

G3 Parallel designs, iterative rapid prototyping,evaluation, usability testing

Style guide, prototyping, heuristicevaluation

G4 Confirm that requirements are met, finalizethe feedback gathering

Confirm that requirements are met

G5 Feedback collection and analysis

Page 30: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Experiences

• A single master’s thesis is too short to have real effect• Analysis, plans, pilots and some training can be done, not much time to collect

feedback• Not possible to ensure that the changes became permanent

• Process perspective and management support critical• It helps, if there has been a lot of communication and shifting the

attitudes• E.g. using style guides

• In process oriented organizations seems to be a good way to start sellingusability approach

• Still necessary to ensure that usability/UX is understood to be wider than usingstyleguides

Page 31: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Usability Maturity Models, UMM(Käytettävyyden kypsyysmallit)

Note, this material is shortened strongly from what itused to be, since it seems to be less in fashionable in

the industry

Page 32: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Maturity models – why?

• Improving processes or getting acertificate

• When defining a future state of anorganization, it helps to understand thecurrent status

• Helps to focus on essential• Helps to manage and measure

Page 33: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Central findings in the past years(in Finnish machinery automation)

Urgent issues to fix• Requirements definition & management• More systematic ways of collecting the user feedback• Setting usability goals• Involving the users in the design• Documenting contexts and users (market areas)• Integrating designing usability activities to be part of normal project

planning

Strengths• Systematic requirements elicitation and management (in some

companies)• Contact with the end users, understanding different user groups,

though deficiencies in documentation• Design is iterative (and schedules are reasonable)• Thorough prototyping with the users

Page 34: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Maturity models

• Most well known software maturity model is the CMM(Capability Maturity Model)

• Earthy has developed a similar Usability Maturity Model (UMM),with 7 processes (in the following slide)

• Defined in standard ISO TR 18259

Page 35: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

7 processes and their base practices in UMM

Page 36: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Executing UMM: terminology

• Processes are using and producing workproducts

• Processes consist of base practices• Base practices are evaluated with nineattributes (process execution level,managing execution, managing workproducts etc. See the picture)

• Four values for attributes• Six levels for processes

Page 37: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Attribute values

• An attribute can reach on of the following4 values

• Not achieved (execution level <15 %)• Partially achieved (16-50 %)• Largely achieved (51-85 %)• Fully achieved (>85 %)

Page 38: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Values for the attributes

N Not achieved 0-15%P Partially achieved >15-50%L Largely achieved >50-85%F Fully achieved >85-100%

Attributes:1.1. Process execution2.1. Managing execution2.2. Managing work products3.1. Defining the process3.2. Following the defined process4.1. Measuring the process4.2. Controlling the process5.1. Developing the process5.2. Optimizing the process

Page 39: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Maturity levels

0. Not executed1. Executed: Individuals executing the processes2. Managed: The organization recognizes and controls

the quality, time and resource requirements3. Established: The process is executed in a defined

way with defined resources4. Predictable: Processes executed with predicted

resources and within quality requirements5. Optimized: The organization can modify the process

suitable for different situations

Page 40: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Process maturity levels (ISO 15504-2)1/2

Level Process attributes Values

1. Executed 1.1 Process execution Largely of fully

2. Managed 1.1. Process execution2.1. Managing execution2.2. Managing work products

FullyLargely of fullyLargely of fully

3. Established 1.1. Process execution2.1. Managing execution2.2. Managing work products3.1. Defining the process3.2. Following the defined process

FullyFullyFullyLargely of fullyLargely of fully

Page 41: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Process maturity levels (ISO 15504-2)2/2

Level Process attributes Values

4.Predictible 1-2 as in previous3.1. Defining the process3.2. Following the defined process4.1. Measuring the process4.2. Controlling the process

FullyFullyLargely of fullyLargely of fully

5. Optimizing 1-3 as in previous4.1. Measuring the process4.2. Controlling the process5.1. Developing the process5.2. Optimizing the process

FullyFullyLargely of fullyLargely of fully

Page 42: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

Jokela, T. (2001). Assesment of User-Centered designProcesses as a basis for improvement action, academicdissertation, Oulu University

Doing it in practice

Page 43: HCPro Lecture 12 (25.2.2014) · the customer a project, where architecture design is left out or the coders do it among their other work as much as they can. Goal from a real case

References• D. J. Mayhew. ”The Usability Engineering Lifecycle.”• P. Ketola, “Integrating Usability with Concurrent Engineering in Mobile PhoneDevelopment”, Academic Dissertation, Tampere University, Tampere, Finland,2002.• B. Göransson, J. Gulliksen, I. Boivie, “The Usability Driven Process – IntegratingUser-Centered System Design in the Software Development Process”, SoftwareProcess Improvement and Practice, vol. 8, no. 2, pp. 111-131, Aug. 2003.• Palviainen, J. Transforming Machinery Design Traditions into User CenteredDesign - Principles, Challenges and Experiences. Proc. of Smart Systems 2008Conference, ISBN 952-5598-04-7, 4-5th June, Seinäjoki, Finland, pp.13-18.• Viikki, K. & Palviainen, J. Integrating Human-Centered Design into SoftwareDevelopment - An Action Research Study in Automation Industry. Proceedings ofthe 37th Euromicro Conference on Software Engineering and AdvancedApplications, 2011, IEEE Computer Society.• A. Seffah, E. Metzker, “The Obstacles and Myths of Usability and SoftwareEngineering”, Communications of the ACM, vol. 47, no 12, pp. 71-76, Dec. 2004.

Usability maturity models:• Usability Net: Assuring Usabilityhttp://www.usabilitynet.org/trump/methods/integration/assurance.htm• Earthy, J., Usability Maturity Model, Lloyd’s Register, INUSE project, 1998.• T Jokela ”Assessment of User-Centered Design Processes As A Basis ForImprovement Action.” Academic Dissertations, Oulu University, 2001.