Some Notes on Design by Concept

This talk (on YouTube) by Daniel Jackson, Design by Concept: A New Way to Think About Software, was recommended to me by Michael Feathers. I just thought I’d take a few notes on it while I watch 🙂

Alright, let’s go!

The following is a mix of notes and my thoughts as I watched (numbered for reference only):

1. “I am more convince than ever. Conceptual integrity is central to product quality,” Fred Brooks, 1995
   1. BUT Fred never provided a definition of what he meant by this concept …
2. A “conceptual model” has been proven to be very useful in UI design, going back to work at Xerox PARC
   1. From there came the insight that the user comes to a system with a mental model and the design ought to help them align their model to the one intended by the designer and against which the system works … and should be consistent with
   2. We’ve developed a field of conceptual modelling, which ought to help with conceptual integrity, but it isn’t clear on what “concepts” are
3. An interesting thing that comes to my mind with the Dropbox example Daniel provides (beyond illustrating that having the wrong conceptual model can surprise users in an unpleasant way), is how some allowable uses of a system by users introduces semantic relationships about which its designers have not considered at all
   1. Also, shocking, the UNIX filesystem conventions are subtle and non-intuitive: and this causes all kinds of pain for Dropbox users – even those who self-identify as having “good knowledge” of Dropbox still only predict the actual behavior of a deletion about 60% of the time!
   2. To help provide clarity and formality about the concept behind how Dropbox folders work, Daniel represents as a state machine … presumably we’ll learn more about the power of this later in the talk
4. The concepts link the understanding of the user, the design of the interface, and the implementation in the code; yes there are relationships between those three things, but getting the concept right gives you a common lens to look at all three and better reason about each one and the system as a whole
5. Things that a concept needs:
   1. Name: essential for knowledge capture
   2. Purpose: why the concept exists
   3. Structure: localized data model
   4. Actions: observable & atomic
   5. Operational Principle: justifies and explains the design and how the behavior fulfills the Purpose
6. Key properties of a concept:
   1. It is inventive: someone created the concept (and perhaps it has been refined over time); it wasn’t “just there”
   2. It is purposeful, otherwise it wouldn’t persist over time … interesting: if you have a concept that doesn’t have a purpose that to a system’s user, see the next point too, then perhaps you just have a feature for a checklist?
   3. It is primarily behavioral: informal explanation is most naturally made with a story about a desire and the outcome (I don’t think that I get this point just yet)
   4. It is self-contained, and explainable in the abstract, which implies that it is also …
   5. Reusable across domains and applications
7. Things that concepts are NOT:
   1. Domain entries that are “just there”
   2. Arbitrary fragments of functionality (like features in a checklist :success-kid:)
   3. Data models or ontologies (although these play a critical role)
   4. Data types or modules
   5. Not domain-specific
8. Design rules for concepts:
   1. The Specificity Rule: make Purposes and Concepts 1:1; all kinds of trouble arises from redundancy (multiple concepts for a single purpose) and overloading (multiple purposes mapping to a single concept)
   2. The Familiarity Rule: steal, don’t invent; where the purpose is the same, use the same concept
   3. The Integrity Rule: when you use two (or more) concepts at the same time, they compose as expected and continue to work as they do independently, without any side-effects

A couple thoughts before were done. 1) I enjoyed the talk and especially found the stories Daniel used to be good illustrations of his points. 2) I value having a clearer definition of what makes a concept and three rules for designing and applying them. I expect to re-reference this post at some time to refresh myself on concepts and the rules for applying them well.