"Opinionated" design as design rationale
31 May 2021 Tags: RhetoricI see increasing use of the phrase “opinionated design”, frequent enough to risk it becoming a vogue word in our field. What makes a design “opinionated”? If someone declares a design to be “opinionated”, what might that tell you about it? How would a designer justify that claim?
Opinionated designs select one approach and favour it
The notion of opinionated designs became a common discussion topic over ten years ago. The Stack Overflow question, “What is opinionated software?”, was posted in 2009 and had contributions as recently as 2014 before being locked.
In 2014 Steve Bradley approached the question from a more design-oriented view, “Opinionated design—make more decisions and leave fewer options”. A succinct summary that agrees with all these perspectives was provided by Jason Skowronoski in 2019, “Opinionated or Not—Choosing the Right Framework for the Job”, featuring this pull quote:
Ultimately, being opinionated means the framework works best as it was originally intended, and varying from it can sometimes only be done with great pain. — Opinionated or not
The above articles focus on frameworks rather than languages, but the description can also be applied to languages. For example, Perl revels in its multiple approaches to solving any given problem, while Python emphasizes a single, “Pythonic” approach.
So it seems there is a widely-agreed meaning to the term. Yet knowing this meaning still leaves much unspecified. When is “opinionated” the best way to characterize a design? How pervasive must the opinion be? For that matter, what are some other ways to characterize a design?
Design rationales characterize a design
The background to the choices underlying a design’s is called a design rationale. In academic CS contexts, the phrase acquired the more specialized meaning of a highly detailed accounting that links every decision to its underlying rationale. This description is exemplified by the current (as of May 2021) Wikipedia page for design rationale.
For this post, I am using a broader meaning, featuring high-level discussions of the broad principles underlying a design. This definition of design rationale is closer to how the phrase is used by user experience (UX) designers. Rania Glass captures the purpose of this design-thinking-oriented style:
This is your goal for your audience when articulating a design rationale: describe the design in a way that clarifies things that haven’t yet been made clear, helping them to express what they’re thinking. You want them to walk away not just knowing more, but understanding more, and more clearly. You’re not simply telling them about what you did; you’re facilitating a conversation about what is being solved and how that’s being done. This is the difference between explanation and articulation; articulation supports the audience’s thinking while explanation only serves to demonstrate yours. [Emphasis added] —Articulating design rationale
From this perspective, a design rationale not only answers questions, it raises the questions in the first place. A design rationale is a lens for looking at a design. Different rationales will emphasize different features of the design by raising different sets of questions.
What are some of the different styles of design rationale and what questions do they raise?
Styles of design rationale—lenses on design
I’m going to propose a rough, informal taxonomy of design rationales. This has some overlap with the more formal taxonomy by Burge and Brown, although they were describing the more mechanistic, detailed “CS” rationales I mentioned above.
- Opinionated rationales focus on the group of users most
likely to benefit from the design. It asks the questions,
- What are the most frequent tasks these users perform?
- What is their workflow for those tasks?
- What is the essential information they need to specify at each step?
The opinionated rationale argues, “This design is great due to its simplicity of use for these users following these workflows and addressing these use cases”. The opinionated rationale also foregrounds the designer and the milieu in which they work.
-
Principled rationales focus on adherence to overall principles, especially ones regarded as important or elegant within the community. For example, the Tao of Hashicorp lists eight principles guiding Hashicorp’s designs, including the classic Unix principle of “Simple, Modular, Composable”.
The principled rationale asks the questions,
- What larger principles might account for the success of this design?
- What larger principles were ignored or even contradicted by this design?
The principled rationale argues, “This design is great because it exemplifies these valued principles”, simultaneously benefitting from community acceptance of those principles and reaffirming them. It is often used in teaching to highlight one or more design principles.
-
Historical rationales present the current design as the successor to prior designs. For example, Linux might trace its design lineage from OS/360 -> Multics -> Unix -> Linux, while Go might trace its lineage from (PL/I and B) -> C -> (Plan 9 languages) -> Go.
The historical rationale asks the questions,
- What prior designs influenced this one?
- How did this design blend and adapt ideas from those prior ones?
The historical rationale argues, “This design is great because it continues the development of this important type of tool”.
-
Generalization/abstraction rationales present the current design as a generalization or abstraction of a previous design. For example, containers can be presented as a generalization of virtual machines, where the virtualized layer is the operating system API rather than the machine instruction set.
The generalization rationale asks the questions,
- How can this design be seen as a generalization of other designs?
- What did this design gain from this generalization?
The generalization rationale argues, “This design is great because it makes this existing widely-used design of use in even more contexts”.
-
Technological advance rationales present the current design as a response to technology advances that rendered prior designs less effective. For example, designers of ScyllaDB argue that ScyllaDB is better-suited to the relative performance of current processors, disks, and memory.
The technological advance rationale asks the questions,
- How does this design exploit recent technologies more completely than others?
- What did this design gain from this increased utilization?
The technological advance rationale argues, “This design is great because it takes advantage of new technologies that are not fully-utilized by other designs”.
I propose the above categories as a loose, informal taxonomy of rationales. I do not consider them exhaustive and they are certainly not mutually exclusive. Most importantly, these are categories of design descriptions, not designs themselves. One could easily pick any of these approaches to describe any design, emphasizing different aspects. An actual design is typically the result of balancing nearly all these considerations.
Furthermore, different analysts can provide widely-varying rationales for a design. A designer may have their preferred rationale but it’s entirely feasible to analyze a design using an entirely different one.
“Opinionated” suggests a design’s audience
There are many possible rationales for a given design. Claiming that a design is “opinionated” is just one approach, an approach that prioritizes one group of potential users and their use cases over other groups. One could instead start from the principles embodied in the design, its historical lineage, how it generalizes prior designs, or how it takes better advantage of recent advances in other systems. “Opinionated” isn’t an inherent property of a design but one of several lenses through which we might view it. To the extent a design is best-characterized as “opinionated”, it indicates how tightly its use may be bound to a specific group of users and usage. Other users may find it awkward for their purposes.