Four years ago, I left academia to join a small design startup, Mile Two. Ironically, after more than 30 years in academia teaching about applied cognitive psychology, human factors and cognitive systems engineering, it feels like my education on design has just begun. I discovered that essential people on our design teams were trained very differently than I was and brought skills and talents to the team that I was lacking. I recently collaborated with some of these teammates on a chapter to reflect on some of the different perspectives that contribute to the development of software to support cognitive work. The first figure was our attempt to summarize some of the different disciplinary perspectives and the second figure is a more elegant revision of that figure suggested by my friend and colleague Fred Voorhorst.
Figure 1. Multiple perspectives on design from Flach, Bennett, Butler & Heroux (In press Handbook of Human Factors).
These diagrams suggest four classes of constraint that must be considered in the design and development process:
- Agency Constraints: These are properties of the "agents" in the system. Traditionally, the agents have been humans, but as machines becoming increasingly autonomous - we now have to consider the internal constraints of these autonomous agents.
- Implementation Constraints: These reflect properties of the computers that will host the software. They include things such as the types of displays and the control/input devices.
- Functional Constraints: These are properties of the work domains or the problem spaces that are the targets for the cognitive work. These include the physical, regulatory, and organizational dynamics that limit the range of possible actions and consequences.
- Aesthetic Constraints: These are properties of the psychological and cultural values that determine the degree of satisfaction or frustration associated with using the software products.
All of the four disciplines, at least implicitly, recognize the full range of constraints, however, each discipline tends to emphasize a subset of these constraints in training and practice.
Human Factors [HF] tends to emphasize the constraints associated with human agency. That is, the focus is on specifying the physical [e.g., reach envelops], perceptual [e.g., visual acuity] and cognitive [e.g., working memory capacity] limitations of humans, so that these limitations are respected in the final design.
User Interface Design [UI] or Human Computer Interaction [HCI] tends to emphasis the impact of various computer capabilities on performance. For example considerations include types of displays [e.g., table-top, large-screen, hand-helds, or head mounted], types of controls [e.g., keyboard, mouse, game controller, touchscreen], and types of mediation [e.g., co-located or distributed via internet].
Cognitive Systems Engineering [CSE] focuses on the problem or work domain constraints. This involves describing the means-ends relations in terms of affordances and exploring alternative strategies or heuristics that might be used to efficiently navigate the functional space.
User-eXperience Design [UX] tends to consider the larger psychological and cultural context of use that impacts people's self-image and sense of satisfaction when using the design product.
I come from an HF perspective and was involved in the early development of the CSE perspective. Thus, much of my career has been spent arguing for the value of a CSE perspective for filling gaps in the design space that I felt were not adequately addressed by the HF perspective. The point was not that the HF perspective was wrong, but that it was not sufficient.
However, over the last few years spent developing software products I have come to realize that even the combination of HF and CSE leaves many gaps in the design space that require skills and perspectives associated with UI and UX design. I realize that my sense of the full demands of design were still quite naive and inadequate.
I now regret that I did not have and was not able to give my students a broader sense of the full breadth of the design challenge. Yet, I realize that it would be impractical to cover the full breadth of design in any reasonable course of study. Thus, much of the education must continue beyond the formal course work. And ultimately, I have come to the conclusion that design is a team sport that requires a diverse set of perspectives and people who are open to and who welcome alternative perspectives. To function on such a team I have had to dampen my tendencies to be an advocate for a particular perspective and I have had to heighten my ability to listen to and appreciate the value of alternative perspectives.
What a great summary and insights!
Thanks for the kind feedback.
Hi Dr. Flach,
I truly appreciate your reflection on how becoming a practitioner made a significant impact on you and your mental model since leaving academia. When you spend too much time in one place, you end up siloing yourself into one way of thinking and retarding your growth.
I am curious, though: in the Figure 2, what is the significance of those jigsaw-like pieces going into specific disciplines, but not others? For example, does it mean that CSE influences HF and UX, while HF influences UI/HCI? And why does HF not touch UX and vice versa, except barely in the center of the diagram?
On a completely separate note, I’ve been working with a Content Strategist a lot here recently. It’s made me think of how people process language either through auditory or visual means, and how that impacts their success at accomplishing a task or influencing their mood. So, I was curious as to what your thoughts are on how psycholinguistics would fit into and/or impact your model?
Anyways, I hope you and your family are all well and safe and sound.
Thanks,
Zac
It reminds me of Socrates.
“Wonder is the beginning of wisdom”
John: I've also found that we need to fit into a broader context in terms of other design/engineering communities with other priorities (cost, marketing, materials, all the types of "engineering" (ME: EE; CE; etc), and we tend to fall under the banner of "systems engineering" which have processes with associated inputs and outputs that might impact how we communicate and package our CSE/HF outputs/recommendations/requirements. The systems engineers and project/product managers often "own" the table at which we sit with all of the other analysts/"designers"/engineers... so bearing this in mind might add other (real, professional and other) constraints on our processes and outputs as the sole voice for the humans inside the now-extended system boundary (as opposed to the humans being outside the system boundary or a black box inside the boundary). Gavan Lintern, Sterling Wiggins, and Steven Deal have all talked about this challenge for the human/user advocates in complex engineered systems. It's not just "the choir" of HF, CSE, UI/UX who all agree where the human/s belong/s in the conception of "the system" boundary.
Rob, I agree. I was preaching to the choir. Ultimately, we have to convince the money men, technocrats, and engineers to get stuff done.
I was wondering what the definition of constraints you were using? Are they constraints in the sense of limitations to flow? Or are they constraints in the broader David Snowden and Alicia Juarrero sense? It might be more powerful if this was the latter, and it would be interesting to see design take on aspects of that latter school of sensemaking and complexity thinking.
Yes - I believe I am using it in the broadest sense possible. There are many different types of constraints - physical, functional, cognitive ... Together these constraints shape the fields of possibilities for experience - what we can do? what we can see? what we find to be attractive? what we value?