Chapter 15: The Divorce of Design
- The Divorce of Design from Use and from Implementation
- Most appalling development in the design disciple in the 20th century has to be divorce of both the user and the implementer.
- Several designers back in the 19th century and onwards have invented significant amount of things.
- However designers can rarely use their own personal experiences as a user, and must seek advice from other.
- There are exceptions to the divorces, and one exception is software engineering.
- "Software engineering, for example, is still so young that system architects were once programmers" (Brooks, 176).
- "The designers of UNIX and especially the Open Source designers of Linux start with their own needs, build tools for their own use, and share with their own peers. I reckon this accounts for both the use success and the user passion" (Brooks 177).
- Why the Divorces?
- Advances in the 20th century required specialization and attention from special engineers and in specified time. The implementation was critical in specialization.
- Some things designed are much more complex and demand a lot of energy from the designer, as well as the cases mentioned above about time and specialization.
- Fallout from the Divorces
- Most divorces happen due to miscommunications.
- "Architects build elegant buildings that are hard to work in" (Brooks, 177).
- Sometimes communication is poor which can prevent the engineers in knowing exactly what is needed.
- Remedies
- Remedy 1: Use-Scenario Experience
- A small amount of experience is better than not having any.
- "This “user” experience led to the design of the first operator’s console to be program-controlled (essentially a close-connected terminal) rather than directly reflecting and affecting the hardware, a capability that enables multiple consoles for multiple operators, and a flexible allocation of tasks among operators, as well as online interactive debugging of programs" (Brooks, 178).
- Remedy 2: Close Interaction with Users via Incremental Development and Iterative Delivery
- Remedy 3: Concurrent Engineering
- Remedy 4: Education of Designers
No comments:
Post a Comment