Paul A asks: When you synchronize actions between two concepts, does that result in new properties holding which do not hold for each concept in isolation?
Yes, it does, because there are now properties that cross concept boundaries. For example, the composition of Upvote and Karma satisfies a property like “a user can’t downvote a post until they have received karma awards of…”.
Mihail S asks: How many systems do you think are there which have such flaws? Is concept the solution to all such failures?
All systems have flaws, and I believe that all systems have conceptual flaws. Concepts help with the conceptual flaws, but there are other kinds of flaws. For example, there can be simple bugs in the code, or low level failures in the UI design. And at a higher level there can be architectural flaws that cause performance problems that cannot be traced to conceptual design flaws. I do believe, however, that when you look at the key flaws that make a system hard to use, and you’ve eliminated the straightforward UI design flaws, it’s usually conceptual flaws that remain, and it’s the prevalence of these flaws (and the fact that they haven’t been well addressed until now) that makes concept design useful.
Lisa R asks: I am a product/HCI designer just starting with a large energy company. How do I present evaluations without saying “Your system is outdated, you need to start from scratch” and not get fired.
I think your best strategy is to find small, incremental design changes that are possible to make and that are likely to have a large impact. Then you can show your colleagues why your work is valuable, and can improve the system, and hopefully that will lead them to consider larger scale changes. Another (but riskier) strategy is to propose developing a small prototype that explores how some piece of functionality could be rethought and presented in a better form.
Terry B asks: How much of usability amounts to a detailed analysis of the existing expectations and mental framework of the most likely user community?
I think that’s less important than some people assume. What Steve Jobs showed us is that if you design a conceptual model that is simple and powerful and readily understandable, then you can get people to happily adopt a new model that they didn’t have before.
Thomas O asks: From your examples, there seem to be 3 types of concepts: nouns, verbs, relations. Do they have different charactristics? Does one think differently about them while designing the system?
Not sure what you have in mind here. If I had to identify nouns, verbs and relations in concept design, I’d place them within a single concept. The data model embodies nouns and their relationships; the actions embody verbs that changes those relationships. Sometimes it’s better and more intuitive to start with the data model and then move to the actions, but sometimes the reverse is easier and more compelling. Often I find myself oscillating between the two. Imagine you’re building a concept to represent a virtual call or meeting in an app like Skype or Zoom. I’d probably start with the data model (you have calls with participants eg) and then move to the actions (join and leave eg), and then come back to the data model when I realized the subtleties of some actions (for example, the fact that when the initiator of the call leaves, the whole call might end, suggests that the data model should include a relation that associates each call with an owner).
Camile G asks: What is your point of view on exposing such concepts to the end users (maybe through the UI, or some sort of API), to increase their ability to customise the software they use? For instance, enabling end users to plug in their own UI components to manipulate a concept such as an upvote/downvote system.
Are you asking whether you could build an app so that users could switch out concepts and insert new ones the way they currently do with some kinds of plug-in? That’s an exciting idea that we’ve thought about a little bit, but it’s a challenging research problem.
Juan A asks: What about using a rating system that could help not only users but also developers to understand the level of difficulty certain concept or functionality could have so they can asses this functionality with more precaution
That’s an intriguing idea. A concept handbook could warn you that some concepts are tricky and hard for users to grasp and that you should be wary of using them. In drawing or visual editing apps, for example, the concepts of Layer and Mask are very powerful but are much harder to grasp than a concept like Group (in which multiple elements can be treated as a single element) or Stacking (in which elements can essentially have different Z coordinates).
Gunjan J asks: Do concepts have a bounded context within which they are valid - such as cultural boundaries? E.g. “Karma” was a culture-specific term till a few years back, and still I can imagine a lot of cultures not being exposed to this concept
Fascinating point! Yes, this is definitely true, and cultural dependencies in design have been a subject of study in HCI for a while. For example, researchers have noted that the extent to which users are influenced in entering their own preferences by the preferences they see of others may be correlated with the degree of individualism vs collectivism in a culture, affecting the design of concepts such as Schedule (as in Doodle) that solicit user input to find good times for a group (see: https://courses.cs.washington.edu/courses/cse510/16wi/slides/09-OtherCultures.pdf). Your point about Karma raises a separate issue, which I discuss in my book, namely that understanding a particular concept is a cultural phenomenon. Restaurant reservations were not common until the end of the 19th century for example, so the whole concept of Reservation would have been less familiar before then.
Vito T asks: How could one apply the idea of concepts in dynamic systems, where the definition of one concept, and how it interacts with other concepts, changes frequently?
I haven’t looked into this, but it’s a good question, and perhaps concepts could give you a constructive way to design such systems and support dynamic reconfiguration.
Bert B asks: Do you think concepts will be universal, or that different groups of people will define their concepts different from others?
Concepts can be for the most part universal, because they respond to the need to solve a concrete problem (the purpose) with a mechanism (the state and actions), and good solutions tend to be widely adopted. My book discusses, for example, the way that the Style concept was invented at Xerox PARC and is still spreading to new apps.
Sachin D asks: Great talk. Very thought-provoking. Could you provide one example of how the collection of system representation artifacts such as user stores, use cases, logical data models, sequence diagrams etc. not be able to adequately explain the structure and behavior of a phenomenon quite as well as a Concept handbook would? OR, is the Concept handbook meant to complement the existing representational artifacts? Thank you.
Thank you!
I suspect that all of those languages could be used to describe individual concepts. What they don’t give you is the modularity of concepts. In just the same way, you don’t strictly speaking need any programming language features beyond those of early LISP or Pascal to structure a system using abstract types. The real benefit concepts bring is the division of the data model into smaller models one per concept, and the recognition that concepts capture reusable design knowledge. All that said, concept purposes and the operational principle do add ideas that are not present in conventional UML models (eg), and the modeling of behavior in terms of actions on state taken from formal methods is (in my opinion) superior to the sequence diagrams and use cases of UML etc, because it’s more succinct, abstract and (as tools such as Alloy and TLA+ demonstrate) analyzable.
Terry B asks: Isn’t rapid prototyping vital to all of this for discerning otherwise unforeseeable consequences of seemingly reasonable interface choices?
Rapid prototyping becomes much less necessary when you reuse concepts that come with a lot of accumulated design wisdom and experience. You don’t really need to prototype an Upvote concept for example (although you might well want to do a user study to see if the concept works in the social context of use that you’re planning). New concepts can certainly benefit from prototyping.
Gabriel B asks: Do concepts change through time? How do I know if a concept is outdated?
Yes! In my book I discuss the evolution of the Trash concept, for example, which in its early appearance in Windows disaggregated folders when they were trashed. Whether concepts get outdated is an interesting question. Concepts can certainly die because better concepts replace them. For example, there is a concept of Alignment in many drawing apps in which (the OP is that) you select a few objects and then execute an action like alignMiddle. This concept is still around but has largely been displaced by the concept of SnapGrid in which objects snap to a grid, and to guide lines that appear when they are at the same position as other objects.
Stefan C asks: How do you envision evaluating the notion of “concept” in terms of how useful it is in software design? How can we tell if it is more useful/better than other/existing ways to think about software design?
In my view, methodological advances are best judged by the wisdom and experience of the community, as people discover whether a method brings value or not. To my knowledge, none of the attempts to bring empirical evidence in favor of even the most widely adopted and successful methodological ideas in software engineering (such as data abstraction, interfaces, decoupling, etc) have been successful. Some might say that means we should not trust these ideas, but I don’t accept that. I think they’re just too hard to test empirically, and a better test is the accumulated experience of developers who use ideas for many years and build informed opinions based on their experience. Or to put it more mundanely: people figure out for themselves which tools allow them to work more effectively. If a tool never works for you, you stop using it; if it brings value, you keep using it. That’s why when I hear people ask whether there’s empirical evidence for typing in programming languages for example, I think that’s missing the point. Programmers who use types know exactly what they’re getting from them, and so people use them judiciously according to context. The question of whether the whole world should change from JavaScript to TypeScript, or Python to Haskell, doesn’t seem to be a very useful one, because the answer is obviously context dependent. And no, I don’t have much hope for empirical methods being able to distinguish contexts. Now all that said, empirical methods, carefully and narrowly applied with a clear purpose in mind, can yield good insights (and I give examples in my book of Jonathan Aldrich’s work in this respect).
Richard S asks: Please repeat your comment about a system for storing and assembling concepts.
I was probably referring to Deja Vu, a platform for assembling apps from prebuilt concepts developed by Santiago Perez De Rosso (https://deja-vu-platform.com)
Michel B asks: All three examples have to do with distributed state where the effects of a user’s action are not visible to that user. Is this an accident or are these particularly tricky?
That is a great observation. I would agree with that, but I’d note that it’s not so much the distributed aspect as the fact that the behaviors are extended over time and involve multiple users. I believe all those problems would arise if the applications were completely centralized, so long as they still had different users performing actions that are connected to one another through persistent state. (I suppose the word “distributed” still applies here in a social sense even if not a narrow CS technical sense.) It’s because of this “action at a distance” that I think concepts are necessary for thinking about design, and more traditional notions (such as Don Norman’s signifiers/affordances) are not sufficient. Tagging someone on Facebook, for example, is not like opening a door because you don’t see the immediate effect—-and in fact you might not see it at all (in that the primary consequence is that the tagged item becomes visible to a larger group of users).
Maxim S asks: Is it possible to build software automatically based on the concept formalization?
Great question. It surely wouldn’t be easy, but the containment that concepts provide might make synthesis of code easier.
Yash D asks: Given the touchiness of these concepts within the bounds of “ethical programming”, and given the issues with software and its acceptance within the political climate of recent times (controversy of “big tech”, privacy, etc.), can we introduce concepts and interfaces without causing much commotion when implemented at a larger scale?
I think you’re onto something interesting here. Just as there are dark patterns of UI design, there seem to be dark concepts. Upvote is in some ways a dark concept because of the social damage we know it inflicts on teens for example. Perhaps recognizing the risks of these concepts allows us to stop just blaming Facebook but realize that there are repeated design patterns that many developers use that have negative social impacts.
Henrique C asks: Are you familiar with the work of Christopher Alexander, specially the book “Notes on the Synthesis of Form”? If so, do you see similarities with the design processes he proposes and your “concept design”?
Yes, I love that book, and I discuss it in my book (as well as other aspects of Alexander’s work). I don’t think concept design has that much in common with the method he describes in NOSF (although I have been very inspired by his notion of misfit, which I use in my book as a way to describe concept design failures). Concept design has more in common with his pattern language work that came later—and concepts seem to be closer to what he had in mind than the GOF design patterns (which made Alexander famous to computer scientists), because those are more about implementation, while concepts, like Alexander’s patterns, are more about the user’s experience.
Nicolai N asks: Do you not think that the FLOTUS issue is more a UX issue? I personally think it is more likely that she either meant to use the Share->Bookmark feature or simply didn’t realize that she had liked the tweet. For Instagram at least, a stray doubleclick with like a post. I do agree, though, that the whole idea of using a Share button to bookmark something is a failure of conceptualizing the UI.
Of course we’re just guessing what she was trying to do. However, I would note two pieces of evidence in favor of my interpretation: (1) many people were already using the Upvote concept in Twitter for setting aside tweets to visit again later (see the slide entitled “a conceptual flaw in Twitter” in an earlier talk of mine at https://people.csail.mit.edu/dnj/talks/eross20/eross20.pdf which quotes various users); and (2) the Bookmark concept did not exist when she made this mistake, so she simply had no choice in this respect (it came in March 2018, and her mistake was in 2017). This second point is the essence of my argument: that the concept she needed was missing.