Design history kew
-
Upload
karen-wieckert -
Category
Documents
-
view
251 -
download
0
Transcript of Design history kew
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