Designing locally usable and meaningful technology Magnus Li Joe - - PowerPoint PPT Presentation

designing locally usable and meaningful technology
SMART_READER_LITE
LIVE PREVIEW

Designing locally usable and meaningful technology Magnus Li Joe - - PowerPoint PPT Presentation

Designing locally usable and meaningful technology Magnus Li Joe Cooper DHIS2 Annual Conference 2019 Us Ma Magnus Li Jo Joe Cooper B.Sc. & M.Sc. in Information DHIS2 core UX designer Systems (UiO) joe@dhis2.org PhD research fellow


slide-1
SLIDE 1

Designing locally usable and meaningful technology

Magnus Li Joe Cooper DHIS2 Annual Conference 2019

slide-2
SLIDE 2

Us

Ma Magnus Li B.Sc. & M.Sc. in Information Systems (UiO) PhD research fellow (UiO) DHIS2 Design Lab lead magl@ifi.uio.no

Making locally meaningful technology - the DHIS2 Design Lab 2

Jo Joe Cooper DHIS2 core UX designer joe@dhis2.org

slide-3
SLIDE 3

Content

  • 1. Fundamental concepts (use, user, usability, utility, user experience)
  • 2. Understanding and involving users (aim, approaches, methods)
  • 3. Design and localization of Generic Software
  • 4. The generic-level design for end-use of DHIS2 (Joe)
  • 5. Supporting implementation-level design of DHIS2
  • 6. Group discussions

Making locally meaningful technology - the DHIS2 Design Lab 3

slide-4
SLIDE 4

Fundamental concepts

  • Us

Usability ty = quality attribute that assesses how easy user interfaces are to use. (Learnability, Efficiency, Memorability, Errors, Satisfaction)

  • Uti

Utility ty = whether the system is useful to certain users. That is, provides the functionality that they need / that are valuable to their work.

  • Mea

Meaningful = usability + utility

  • Us

User experience = all aspects of the end-user's interaction with the company, its services, and its products.

  • Us

Usability ty design = the design process aimed at assuring or improving usability

Making locally meaningful technology - the DHIS2 Design Lab 4

slide-5
SLIDE 5

‘Use’

  • “Use” in our context refers to utilizing some kind of technology (such

as DHIS2) to achieve some goal.

  • Use of one tool / software always unfold in a network or ecosystem of

tools, routines, people, communication mechanisms, etc..

Making locally meaningful technology - the DHIS2 Design Lab 5

slide-6
SLIDE 6

User and end-user

  • With large organizational systems, there are often a variety of user groups that use

the system. For instance;

  • Maintenance / implementers (technical).
  • Health /program managers

(on different levels).

  • Data entry clerks.
  • Doctors and nurses.
  • Community health workers.
  • Patients?

De Decreasin ing am amoun unt of

  • f:
  • Training attended?
  • Interest in, and time for using

and learning the system?

  • Participation in requirement

definition when system is developed?

Making locally meaningful technology - the DHIS2 Design Lab 6

slide-7
SLIDE 7

Usability is a relational phenomenon

  • Whether a system is usable depends on who’s using the system
  • What’s usable for someone in a certain context may be unusable to
  • ther people or in other contexts.

Making locally meaningful technology - the DHIS2 Design Lab 7

slide-8
SLIDE 8

Usability is a relational phenomenon

  • Pending on, for instance:
  • Established practices
  • Domain terminologies
  • Technical knowledge
  • Other tools and technologies
  • Environment of use
  • In office on desktop computer
  • On smartphone as community health worker in rural areas
  • While interacting with patients under time pressure.

Making locally meaningful technology - the DHIS2 Design Lab 8

slide-9
SLIDE 9

Matching the users’ mental models

Making locally meaningful technology - the DHIS2 Design Lab 9

slide-10
SLIDE 10

Usability heuristics (Nielsen, 1998)

  • Vi

Visibility of system m status The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

  • Ma

Match ch between system m and the real worl rld The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

  • Co

Consistency y and standards Users should not have to wonder whether different words, situations,

  • r actions mean the same thing.

Making locally meaningful technology - the DHIS2 Design Lab 10

slide-11
SLIDE 11

Usability heuristics (Nielsen, 1998)

  • Recognition r

rather t than r recall Minimize the user's memory load by making objects, actions, and options

  • visible. The user should not have to remember information from one part of

the dialogue to another. Instructions for use of the system should be visible

  • r easily retrievable whenever appropriate.
  • Flexibility a

and e efficiency o

  • f u

use Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

  • Aesthetic a

and m minimalist d design Dialogues should not contain information which is irrelevant or rarely

  • needed. Every extra unit of information in a dialogue competes with the

relevant units of information and diminishes their relative visibility.

Making locally meaningful technology - the DHIS2 Design Lab 11

slide-12
SLIDE 12

Example of mismatch between system and real world

Making locally meaningful technology - the DHIS2 Design Lab 12

Actual reporting periods Periods implemented in DHIS2

slide-13
SLIDE 13

Example of mismatch between system and real world

  • Data set
  • Organizational unit
  • Clear Cache
  • Tracked entity
  • ??

Making locally meaningful technology - the DHIS2 Design Lab 13

slide-14
SLIDE 14

Understanding and involving end-users

Making locally meaningful technology - the DHIS2 Design Lab 14

slide-15
SLIDE 15

Gap between designers and end-users

Making locally meaningful technology - the DHIS2 Design Lab 15

Understand Involve

slide-16
SLIDE 16

Classic methodologies for understanding or involving users

  • Participatory D

Design ( (PD) ( (Scandinavian t tradition). Emphasize highly participative design process for empowerment.

  • Us

User/H /Human-centered d design ( (UCD). Emphasis on understanding users and evaluating prototypes with users to ensure relevant and usable systems.

  • Ac

Activity-centered d design ( (ACD). Emphasis on understanding the activities of the end-users to make software that fit into their established practices

  • Sc

Scena nario-based d design ( (SCD). Based on the development of problem and solution scenarios that are build through investigation and involvement of end-users. The scenarios are used to communicate between actors, and to inform design of prototypes.

Making locally meaningful technology - the DHIS2 Design Lab 16

slide-17
SLIDE 17

Reasons for involving users seen in ICT4D projects

  • Empowerment (PD)
  • Advertisement (claiming PD, UCD etc.)
  • In

Increa ease u se usa sability ty a and u uti tility ty f for

  • r en

end-us users (UCD, PD, ACD, SCD)

  • Sit

Situated in innovatio ion (UCD, ACD, SCD)

Making locally meaningful technology - the DHIS2 Design Lab 17

slide-18
SLIDE 18

Understanding and involving end-users in the design process

  • In general, for ‘local’ usability and utility, the rationale is to create more

usable and meaningful systems by: a) a) Un Understanding end-users, their established practices, activities, and context of use. and/or b) b) In Involving end-users in the process of design to participate in decisions. And then reflect their mental models and needs in the design of user interfaces and functionality

Making locally meaningful technology - the DHIS2 Design Lab 18

slide-19
SLIDE 19

Understanding and involving end-users in the design process Un Understan andin ing pr practice Observe, experience, understand the activities, practices and context of the user to inform design

Making locally meaningful technology - the DHIS2 Design Lab 19

In Invol

  • lving u

user sers Let the users participate in decisions.

slide-20
SLIDE 20

Typical elements of a design process

Understanding practice Analyzing learnings Building prototypes Evaluating with users and actors

Working system

Making locally meaningful technology - the DHIS2 Design Lab 20

slide-21
SLIDE 21

Understanding practice – some typical methods

  • Focus groups and interviews
  • Contextual inquiry
  • Participatory observation

Making locally meaningful technology - the DHIS2 Design Lab 21

slide-22
SLIDE 22

Understanding practice – Focus groups and interviews

  • Fo

Focus gr groups involve gathering several users in a group focused around topics, such as:

  • How they work (activities, tools, processes)
  • Challenges they face
  • Collaborative prototyping / generating ideas for

solutions

  • In

Inter erviews s involve talking to one or several users in an open-ended or planned session.

Making locally meaningful technology - the DHIS2 Design Lab 22

slide-23
SLIDE 23

Understanding practice – Contextual inquiry

  • Co

Contextual inquiry y involves sitting together with end-users, observing how they work while asking questions.

  • For instance, ask them to perform a typical work

activity and observe what they do. Ask when something is unclear or needs elaboration.

  • Powerful approach to understand how tings

are done and issues faced.

Making locally meaningful technology - the DHIS2 Design Lab 23

slide-24
SLIDE 24

Understanding practice – Participant observation

  • Pa

Participant observation involves taking part in the end-users activities.

  • Doing tasks and activities
  • Testing technologies, tools and software.
  • Gives in-depth experience of the future use-

context of technology.

Making locally meaningful technology - the DHIS2 Design Lab 24

slide-25
SLIDE 25

Typical elements of a design process

Understanding practice Analyzing learnings Building prototypes Evaluating with users and actors

Working system

Making locally meaningful technology - the DHIS2 Design Lab 25

slide-26
SLIDE 26

Analyzing learnings – some typical techniques

  • Scenarios
  • Personas
  • Activity diagrams
  • Hierarchical task analysis

Making locally meaningful technology - the DHIS2 Design Lab 26

Name: John Title: Doctor Activities: Data entry Maps Analysis in pivot table ++++

slide-27
SLIDE 27

Analyzing learnings – hierarchical task analysis

  • Hierarchy of sub-tasks included in a tasks
  • May help identify a) what people do, b) how a tool is related to others, c)

where problems are, d where to potentially improve something

  • 1. Enter monthly report

1.1 Log inn

1.2 Open data entry 1.2.1 search for app

1.2.2 click app

1.3 find form

1.3.1 select

  • rg.unit

1.3.2 select program 1.3.3 se period

Making locally meaningful technology - the DHIS2 Design Lab 27

slide-28
SLIDE 28

Typical elements of a design process

Understanding practice Analyzing learnings Building prototypes Evaluating with users and actors

Working system

Making locally meaningful technology - the DHIS2 Design Lab 28

Often a iterative process from low-fidelity to high-fidelity

slide-29
SLIDE 29

Prototyping and evaluating

Making locally meaningful technology - the DHIS2 Design Lab 29

Prototyping Evaluating

slide-30
SLIDE 30

Typical elements of a design process

Understanding practice Analyzing learnings Building prototypes Evaluating with users and actors

Working system

Making locally meaningful technology - the DHIS2 Design Lab 30

Often a iterative process from low-fidelity to high-fidelity à Through processes of evaluation with users

slide-31
SLIDE 31

Design ‘never’ ends

Making locally meaningful technology - the DHIS2 Design Lab 31

slide-32
SLIDE 32

Design and Localization of Generic Software

Making locally meaningful technology - the DHIS2 Design Lab 32

slide-33
SLIDE 33

Generic software and usability

  • Generic software is different from bespoke software.
  • It is developed to serve different users in different organizations.
  • Makes design for usability challenging

Making locally meaningful technology - the DHIS2 Design Lab 33

Us Usability Sensitive to sp specific users practices and context of use Ge Generic Emphasise variety of users in different

  • rganizational contexts
slide-34
SLIDE 34

Dimensions of genericness and usability

Making locally meaningful technology - the DHIS2 Design Lab 34

(M. Li, 2019)

slide-35
SLIDE 35

Dimensions of genericness and usability: DHIS2

Making locally meaningful technology - the DHIS2 Design Lab 35

DHIS2

slide-36
SLIDE 36

Addressing usability in generic software

  • A jo

join int ef effort between the generic-level designers (i.e., the DHIS2 core developers), and the implementation-level designers (i.e., software implementers)

  • Generic-level designers provide

a) user interfaces and functionality for end-use on typical use-cases b) Adaption features in the software to facilitate localization during implementation

  • Implementation-level designers utilize adaption features to localize the

software based on specific organizational needs.

Making locally meaningful technology - the DHIS2 Design Lab 36

slide-37
SLIDE 37

Addressing usability in generic software

Making locally meaningful technology - the DHIS2 Design Lab 37

(Li & Nielsen, 2019)

slide-38
SLIDE 38

Addressing usability in generic software

Making locally meaningful technology - the DHIS2 Design Lab 38

slide-39
SLIDE 39

Generic-Level Design at DHIS2

slide-40
SLIDE 40

Our process

  • 1. Find out requirements/needs of users
  • 2. Understand requirements, translate into user stories
  • 3. Find the balance
  • 4. Prototype ideas
  • 5. Iterate
  • 6. Remain open for feedback
slide-41
SLIDE 41
  • 1. Find out requirements

Search controls TEI notes Enrollment summary Check for enrollment View audit log in modal Log glass breakage Attach reason to log events Sort/filter log events Multi-add forms Batch editing Inline table row edit Form/table input toggle Simple, fast data entry Inline feedback Keyboard navigation Custom forms

slide-42
SLIDE 42
  • 2. Requirements → User Stories

Search controls TEI notes Enrollment summary Check for enrollment View audit log in modal Log glass breakage Attach reason to log events Sort/filter log events Multi-add forms Batch editing Inline table row edit Form/table input toggle Simple, fast data entry Inline feedback Keyboard navigation Custom forms Person Management Data Entry Case Registration Audit Management

slide-43
SLIDE 43
  • 3. Find the balance
slide-44
SLIDE 44
  • 4. Prototype ideas
slide-45
SLIDE 45
  • 5. Iterate
slide-46
SLIDE 46
  • 6. Remain open
slide-47
SLIDE 47

Example: Organisation Unit Tree

slide-48
SLIDE 48

Example: Organisation Unit Tree

slide-49
SLIDE 49

Example: Organisation Unit Tree

slide-50
SLIDE 50

Example: Organisation Unit Tree

slide-51
SLIDE 51

Example: Data Visualization Guidance

slide-52
SLIDE 52

Example: Data Visualization Guidance

Assessing User-Designed Dashboards: A Case for Developing Data Visualization Competency, Chrysantina, Aprisa (et. al)

slide-53
SLIDE 53

Example: Data Visualization Guidance

slide-54
SLIDE 54

Example: Data Visualization Guidance

slide-55
SLIDE 55

Example: Data Visualization Guidance

slide-56
SLIDE 56

Example: Data Visualization Guidance

slide-57
SLIDE 57

Example: Tracker Capture

slide-58
SLIDE 58

Example: Tracker Capture

slide-59
SLIDE 59

Example: Tracker Capture

slide-60
SLIDE 60

Example: Analytical Expressions

slide-61
SLIDE 61

Example: Analytical Expressions

slide-62
SLIDE 62

Example: Analytical Expressions

slide-63
SLIDE 63

Example: Analytical Expressions

slide-64
SLIDE 64

Promoting usability with a system

slide-65
SLIDE 65

Promoting usability with a system

slide-66
SLIDE 66

Promoting usability with a system

slide-67
SLIDE 67

Promoting usability with a system

slide-68
SLIDE 68

Promoting usability with a system

https://github.com/dhis2/design-system

slide-69
SLIDE 69

Future Collaboration

slide-70
SLIDE 70

Future Collaboration

  • Bad timing. Feedback coming from a visit right after we finish building
  • something. Not aligned.
  • T
  • o specific. The implementation-level requirements are of course

specific, sometimes that means adding too much complexity. By default we would not be generic anymore.

  • Not enough feedback. We might make several different prototypes,

but it can be hard to locate the people best placed to give feedback. Access to the end user is hard.

slide-71
SLIDE 71

Future Collaboration

  • Bad timing. Feedback coming from a visit right after we finish building
  • something. Not aligned.
  • T
  • o specific. The implementation-level requirements are of course

specific, sometimes that means adding too much complexity. By default we would not be generic anymore.

  • Not enough feedback. We might make several different prototypes,

but it can be hard to locate the people best placed to give feedback. Access to the end user is hard.

slide-72
SLIDE 72

Future Collaboration

  • Bad timing. Feedback coming from a visit right after we finish building
  • something. Not aligned.
  • T
  • o specific. The implementation-level requirements are of course

specific, sometimes that means adding too much complexity. By default we would not be generic anymore.

  • Not enough feedback. We might make several different prototypes,

but it can be hard to locate the people best placed to give feedback. Access to the end user is hard.

slide-73
SLIDE 73

Future Collaboration

  • Bad timing. Feedback coming from a visit right after we finish building
  • something. Not aligned.
  • T
  • o specific. The implementation-level requirements are of course

specific, sometimes that means adding too much complexity. By default we would not be generic anymore.

  • Not enough feedback. We might make several different prototypes,

but it can be hard to locate the people best placed to give feedback. Access to the end user is hard.

slide-74
SLIDE 74

Usability as a priority

slide-75
SLIDE 75

Supporting implementation-level design & the DHIS2 design lab

Making locally meaningful technology - the DHIS2 Design Lab 75

slide-76
SLIDE 76

Addressing usability in generic software

  • As an implementation-level designer, you are faced with end-user

requirements on one hand, and the software to be ‘shaped’ on the

  • ther.
  • The localization-related resources provided by the generic-level

designers are thus important.

Making locally meaningful technology - the DHIS2 Design Lab 76

slide-77
SLIDE 77

Implementation-level design

Making locally meaningful technology - the DHIS2 Design Lab 77

DHIS2 Client Implementation-level designers Generic-level designers

Negotiating requirements “Good cop, Bad cop” Change requests (e.g., Jira), or support Adaption approaches

  • Configuration
  • Customization
  • Extension

Only generic requirements

E.g., HISP Tanzania ‘DHIS2 core developers’

Project managers Users

slide-78
SLIDE 78

Implementation-level design

  • Typical design-methods are not aligned with the adaption capabilities
  • f generic software
  • Also, to be usable (and sustainable beyond research projects), they

need to be time, resource and competence effective.

  • We often see that design methods are unattractive to developers,

implementers and client project managers.

  • Further, when we try to apply them, we often end up with «fighting

the software constraints»

Making locally meaningful technology - the DHIS2 Design Lab 78

slide-79
SLIDE 79

Difficult to solve usability problems

Making locally meaningful technology - the DHIS2 Design Lab 79

Actual reporting periods Periods implemented in DHIS2

slide-80
SLIDE 80

Implementation-level design: adaption features

  • Co

Conf nfigur iguratio ation (default options in the software, e.g., org.units, data sets, data elements, form builder)

  • Cus

Customiz mizatio ation (changing the core source code)

  • Ex

Extens nsio ion (building add-ons or third-party apps through the APIs)

Making locally meaningful technology - the DHIS2 Design Lab 80

slide-81
SLIDE 81

Implementation-level design: ad adap aptio ion ap approac aches

Making locally meaningful technology - the DHIS2 Design Lab 81

Configuration Customization Extension Time and competence Fast, easy Competence intensive (fast or slow) Competence and time intensive Upgrades Few upgrade problems Always upgrade problems Limited to API changes Design flexibility Limited High (ish) High

slide-82
SLIDE 82

The DHIS2 Design Lab

  • The new initiative, DHIS2 Design Lab aims to strenghten the resources

provided to implementation-level designers, to better support usability-related design on the level of implementation.

  • We refer to these resources as a «design infrastructure»
  • The infrastructure consist of
  • Adaption features in the DHIS2 software
  • Othert artifacts that supports implementation-level design
  • Soft resources such as guidelines, documentation and tutorials.

Making locally meaningful technology - the DHIS2 Design Lab 82

slide-83
SLIDE 83

The DHIS2 Design Lab

Making locally meaningful technology - the DHIS2 Design Lab 83

slide-84
SLIDE 84

(some of) or current projects

Ad Adapti tion

  • n
  • DHIS2 UI library
  • Shared web-app

component library

  • Terminology translator
  • Drag and drop form

builder

  • DHIS2 dashboard widget

resources

Making locally meaningful technology - the DHIS2 Design Lab 84

Tool

  • ols
  • DHIS2 prototyping tool

De Design me metho hods ds

  • Resource page with

tested design-methods

  • Aligned with adaption

features of the software

  • Frugal in terms of time,

resources, competence

slide-85
SLIDE 85

Readings

Making locally meaningful technology - the DHIS2 Design Lab 85

slide-86
SLIDE 86

Further readings

Bo Books (usability-related design in general)

  • The Design of Everyday Things (Norman, 2013)
  • Interaction Design (Sharp, Preece, and Rogers, 2015)
  • Usability Engineering - Scenario-based development of human-computer interaction. (Rosson and

Carroll, 2002) Articl cles (on supporting and conducting implementation-level design within generic software / DHIS2)

  • Making Usable Generic Software – A Matter of Global or Local Design? (Li and Nielsen, 2019)
  • Making Usable Generic Software – The Platform Appliances Approach (Li, 2019)
  • A Design Approach to Addressing Usability in Generic Software (Li, 2019)

Making locally meaningful technology - the DHIS2 Design Lab 86

slide-87
SLIDE 87

Group discussions

Making locally meaningful technology - the DHIS2 Design Lab 87

slide-88
SLIDE 88

Group discussions

  • We have prepared some questions
  • We want you to discuss in smaller groups (3-5)
  • For each topic, we want you to discuss for 15 minutes, and then

present your main points to us all.

Making locally meaningful technology - the DHIS2 Design Lab 88

slide-89
SLIDE 89

Group discussion (15 min)

1. Have you experienced usability issues in any implementation-project? 2. What are your practices related to design and usability during DHIS2 (or

  • ther software) implementation?

A. Understanding end-users’ practices B. Involving end-users C. Analyzing experiences, prototyping and evaluation 3. Are you (or your colleagues) using any of the methods and techniques discussed in this session? Why/ why not, and what are the potential issues with applying them? 4. What kinds of approaches do you find working and what does not work? Why?

Making locally meaningful technology - the DHIS2 Design Lab 89

slide-90
SLIDE 90

Group discussion (15 min)

  • 1. What experiences do you have with the design

infrastructure of DHIS2? That is:

  • Adaption features and approaches (configuration, customization,

extention)

  • Supporting resources (documentation, guidelines, etc.)
  • 2. What is lacking and what could help strenghten the

implementation-level design process? (to strenghten local usability and utility for end-users)

Making locally meaningful technology - the DHIS2 Design Lab 90