1

Managing Design: Materials, Structure

Karen E. Wieckert

2

Outline

•  History, background •  Design

–  Context of design, implementation, use…

•  Methods –  Qualitative, case-based

field studies •  Retrospective •  Ethnographic •  Participant observation

•  Expert systems –  Innovation in design

•  Medical decision support –  Elaboration of solution

•  Web site design –  Usability and materials

•  Case-based research and teaching

3

History

•  Research and teaching –  AI: Knowledge

representation, natural language processing

–  Social analysis of design

–  Human computer interaction, usability

–  Sociology of science and technology

•  IT industry and consulting –  Design –  Project management –  Training

•  Web design –  Information

architecture –  Usability –  Ecommerce

coordination

4

Design

•  Design happens in present within design context. •  Artifact(s) of design implemented and used by

others within uncertain contexts in future. –  Bridge present and future through management of

design. –  Engagement of materials - physical and

representational - to project artifact into future contexts (implementation, use, …)

–  Articulate and project views of multiple stakeholders into future contexts

5

Traditional Design…

“artifact toss”

Design Use

6

Software engineering…

“artifact toss”

Context of design Use

• Life-cycle models

• Design teams

• Project management

7

User-centered design…

(2) “artifact toss”

Context of design Context of use

(1)

8

Participatory design…

“artifact evolves”

Context of design

Context of use

user/designer team

9

Design in situ…

“artifact evolves”

Context of design

Context of implementation, use…

Sales/Marketing

Management

Infrastructure Users

Design team Model of users

Work process

Information needs

Model of market

10

Research methods

•  Small “N” Field studies –  Case-based –  Stakeholder interviews,

e.g., •  Designers •  Decision makers •  Users

–  Observations, e.g., •  Meetings •  Work activity •  Offices, desks, shelves!

–  Participation

•  What is a case? –  Comparative sampling

•  Large vs. small •  Short vs. long term

–  Conceptual development, e.g.,

•  Quality of user modeling

•  Elements of context of use

•  Effectiveness of design materials

–  Ease of access (!)

11

InstrumentMaker: Scientific Instruments

•  Designers (CS, biochemistry) building lab-based DSS for planning centrifuge runs. –  Ultracentrifuge mature,

successful product. –  Specialist retiring.

•  Public and explicit representation of specialist’s practice conflicted with marketing and sales policy for ultracentrifuges.

•  Marketing required DSS to support use of line of rotors for ultracentrifuge.

•  Specialist viewed those rotors as inappropriate for “scientific” practice.

•  Within context of use, provided two plans: optimal and lab plan. –  After specialist retired,

single plan provided.

12

AeroSystems: Aerospace firm

•  Designer (third grade school teacher turned developer) building informational tools for assembly line workers –  Translation of technical

information into user vocabulary.

•  Specifications from engineers AND shop floor workers (users). –  “How do you describe the

sound?”

•  Managers of assembly line forbid workers to consult directly with informational system –  Authority over schedule,

information, job descriptions, etc.

•  Designer intervened to allow direct access. –  Change of work process in

context of use provided more productive use of time as well as educational material.

13

!!AcmeAir: Aerospace Firm!

•  Designers creating expert system to ``replace'' retiring craftsman expert in power engineering.

•  Numerous cycles through design problems and articulated solutions.

•  Trouble constructing artifact supportable on infrastructure for users in their work.

•  Final artifact became decision support system and DB of physical plant.

•  Within context of use directly connects to: –  Users (craftsman), –  supportable infrastructure

(existing DB and its administrator),

–  robust work process (work ticket logging), and

–  model of information (blueprints and construction documents).

14

Medical Decision Support

•  T-Helper: Decision support system to aid in recommendations of patients with HIV disease to clinical research protocols. –  Support non-research

medical personnel within county health clinics.

•  Design needs (Phase I) –  Representation of

protocols –  Logic matching patient

characteristics to protocol criteria

–  DB of patient information, including lab data

15

T-Helper

•  Representation of Protocols –  Translation of text into

rules (imperfect) –  Proprietary interests on

trials (who has authority).

–  Tracking availability of patients and protocols (scooping the “good” patients).

•  Logic matching patients to protocols –  Science versus practice

(placing pts. on protocols) •  Lab data (information)

–  Institutional responsibility and authority

–  Computer vs. paper –  Std’ized formats

•  DB of patient information –  Nurses input: NOT! –  Work process redesign for

medical personnel

16

DB of Patient Information

•  Connection to existing systems –  Patient registration, ...

•  Connection to clinician reporting methods –  Progress notes

•  Integration of reporting from multiple health professionals –  Physicians, social workers,

…

•  Infrastructure –  Computers, ethernet, space

in exam rooms –  Technical support

•  Electronic patient record –  Computer use by physicians –  Vocabulary development –  Intervention into work

process

17

T-Helper: “Surgery was a success, but…”

•  Ultimately, some computerized systems are far ahead of their time

•  Immaturity of material elements in context of use : –  Out patient clinics in county hospitals lack computing

infrastructure. –  Computer use by medical personnel growing, but low. –  EPR systems slowly gaining ground. –  Standardized medical vocabulary required. –  Systems to support the collaborative nature of health

work required. –  Agreed upon treatment for people with HIV disease. –  …

18

Web Site Development

•  Voluntary use of web sites by customers –  Control over context of use minimal, but material

maturity high •  PCs and Apple (sort of) •  HTML, JS, Java, ASP, IE, NSCP, Logo/home, “Amazon-like”

navigation/search/check-out/registration, etc.

•  Usability as important as technical and visual design: –  If user cannot find information, use an application, or

(!) complete the check out process, loss of revenue. –  Collaboration between technical, visual, and UI design

(if it exists), and marketing.

19

Material Support for Collaboration

•  Making context of implementation and use visible within the context of design: –  User modeling, stakeholder interviews, competitive

landscape, usability tests –  Business objectives –  Page and site information architecture, navigational

support –  Vocabulary development –  Style development: colors, fonts, page comps,

templates for DB driven data –  Design/UI/Technology Guidelines

20

Williams Sonoma Web Site

21

Williams Sonoma Sign In

22

User Flow: User Sign In

23

Account Wireframe

24

Specification: Design/UI/Technical

25

Specification: Design/UI/Technical

26

Specification: Design/UI/Technical

27

Specification: Design/UI/Technical

28

Specification: Design/UI/Technical

29

Common Findings Across Cases

•  Material maturity critical (design must anticipate and rely upon resources in contexts of implementation, adoption, use)

•  Single stakeholders cannot dominate (for artifact to successfully travel)

•  Success/failure too blunt a metric (partial, mundane use as effective)

•  Ruts good (exploit existing organizational structure) –  But, finding “good” ruts hard…

30

Material Support for Collaboration

•  Materials create boundary objects between differing interests of organizational groups

•  Work of articulating trajectories of each group’s interests happens over and around these materials

•  Research focus on the existence, quality, flexibility, authority, mobility of these materials