softwaredesign/raw/book/EssenceOfSoftware_Eng/concepts-151-180/concepts-151-180.md

10: Concept Familiarity

fig. 10.2 Organizing slides in Keynote and PowerPoint. On the le, the Keynote group concept, which reuses the familiar concept of the tree outline; in the middle, the PowerPoint section concept, which is novel and unfamiliar; on the right, some actions on sections whose behavior is unpredictable.

Grouping Slides: Avoiding Invention

When a designer has a choice between reusing a generic concept or inventing a new one, it's preferable to reuse the generic one—unless there's a clear respect in which the generic concept would not fulll the purpose so eectively.

To illustrate this, let's look at how two slide presentation tools let you structure the sequence of slides. e purpose here is to be able to organize a presentation into smaller groups of slides, so that you can work on each group separately. e expected operational principle is something like this:

If you group a contiguous set of slides, you can then apply actions to the entire group at once, such as showing or hiding the slides, moving them around, etc.

Apple Keynote provides the slide group concept for this purpose. A group is a sequence of slides that sits under a parent slide, shown by indenting the members of the group with respect to the parent (Figure 10.2, le). You can toggle the visibility of the group, and can move it around as a unit by dragging the parent slide.

Microso PowerPoint provides the section concept for the same purpose (Figure 10.2, middle and right). Each section can be given a name, and, like Keynote, has a toggle to display or hide its constituent slides. is works reasonably well, and is certainly not a terrible design.

But the Keynote design, in my view, is more eective and easier to use. Whereas PowerPoint's sections are limited to one level of organization, you can put groups inside groups (up to six levels deep). In these sample slides, you can see that, in Keynote, slide 11 sits below the slide with the title "grouping slides," which itself sits below "concept familiarity"; in PowerPoint, there can be no structure within the section entitled "concept familiarity" because sections can't be nested. You can move sections forwards and backwards in the presentation order, but you can't put a section inside another section.

e user interface of groups is more intuitive. To create a group, you select some slides that follow the slide that will be the parent, and you drag them to the right; to remove the group, you drag them back to the le. If you drag a slide that is in the middle of a group to the le, it will be promoted up one level (as you'd expect), and the group it previously belonged to will be split into two sibling groups.

Creating sections is more tricky. You might have thought you could select a contiguous sequence of slides (say all the slides that are about concept familiarity) and then invoke the command "add section." If you do that, it will indeed create a section, but that section will include all the slides from the rst selected slide to the end of the entire presentation. If the selected slide is within a section, the new section will follow it; if not, a second new section (which will be named "default section") will be created for the earlier slides.105

is is complicated! (And tedious to read about, I admit.) But worse, it's unpredictable. ere's no reason you should have been able to guess that adding a section would do this. It would have been equally reasonable (and perhaps better) to create a new section containing just the selected slides, for example.106

In contrast, Keynote's behavior is mostly simple and predictable. If you start with no groups, and you drag one slide to the right, you will have created one group in which that slide is the child and its predecessor is the parent. Unlike with sections, no other groups appear spontaneously. Perhaps the only behavior you might not predict is what happens if you select several non-adjacent slides and drag them to the right. In that case, you see visually (as you begin to

10: Concept Familiarity

drag) that the slides are grouped together into a single contiguous sequence, and will then become children of the same parent.

Why was Apple able to design a beer concept? In large part, it's because they didn't start from scratch. And this is also why Apple's concept feels more intuitive. We've seen it before, in other contexts. We might call it the outline tree concept. Every outlining tool and word processor has it: you can make a list of items (usually short sentences or phrases) and introduce levels, so that the resulting structure is a tree with an outline item at each node.

Export Presets: When Extension Breaks Familiarity

Our second example of an unfamiliar concept arises in a dierent context. In this case, we'll see that the design started out with a conventional and familiar concept, but it was then extended with new functionality, and the familiarity was lost.

e concept is preset. Its purpose is to save the user the trouble of entering parameters for a frequently used command. Instead, the parameters are saved as a preset, and when the command is invoked, the user can choose either to set the parameters explicitly, or to set them automatically by selecting a previously saved preset.

Adobe Lightroom Classic uses presets eectively for many dierent commands. ere are presets for printing, for editing, and for importing and exporting images. e troublesome example that I want to focus on involves the use of the preset concept for exports.

Take a look at the screenshot of the export dialog (Figure 10.3). On the right are the parameter seings; on the le is a (hierarchical) list of presets. You can adjust the parameters manually; you can also click on the name of a preset, which will cause the parameters to take the preset values, and you can then override those values if you like. All this is familiar to anyone who has used a preset dialog.

But now if you look carefully at the preset list, you'll notice that there is checkbox next to each preset name. is, it turns out, is a powerful extension that allows you to select several presets at a time. Now you may wonder: what can this possibly mean? Well, in general, for the preset concept, it doesn't make much sense, because only one set of parameters can be used when a command is executed. But for this particular command, one might want multiple

fig. 10.3 e export dialog in Adobe Lightroom, which uses an unconventional variant of the preset concept. In addition to selecting a preset by clicking on its name (le), you can also check the box (right); this allows multiple presets to be selected, which allow the same set of photos to exported multiple times, with dierent seings each time.

executions with dierent presets. You might, for example, export the chosen photos in both high and low resolution versions in one go.

e goal of this new functionality—namely to allow a sequence of exports with multiple presets—is totally reasonable, and was apparently requested by many users. But squeezing it into the preset concept produces some strange anomalies. For example, if you select a preset by checking it, you can no longer edit its parameters.

As you might expect, when this new functionality was added, many users posted requests for help on the app's community forum. Many (including me) didn't even realize that clicking on a preset name was dierent from clicking on the checkbox. And the graying out and the hiding of sections was puzzling to users. e presence of the "Learn more" link at the boom of the dialog suggests that Lightroom's designers are well aware of these problems, but have yet to solve them.

10: Concept Familiarity

Applying the concept specicity principle, we might detect here two distinct purposes: (1) saving common parameter seings for commands; and (2) repeating a command with dierent, but predetermined, seings. e rst is fullled by the preset concept. e second probably calls for a new concept, which would be independent of preset but used with it: maybe one like Photoshop's action to dene sequences of actions as lile programs that the user can dene and invoke.107

Conformity of Concept Instances

When a concept that appears in a design is an instance of a familiar, generic concept, it should adhere exactly to the behavior of the generic concept—unless there are very good reasons not to, and the deviations from the standard concept are made very clear. Otherwise users who are familiar with the generic concept will be confused, having assumed that the concept behaves the same way it behaves in the other instances they have seen.

To illustrate this, let's look at a dilemma in the design of Apple's contact concept. Most people use the Apple Contacts app on their phone. Aside from storing phone numbers so you don't have to remember them, it also fullls the useful function of aaching names to numbers when calls come in. Many people enter nicknames for friends and family members, so that on a certain Charles George's phone, a call from his mother might be shown with the name "Mummy" if he had failed to follow protocol and enter her name in his contacts as Her Majesty Queen Elizabeth II.

ere's no disaster here, but if the Prince of Wales now sent an email message to his mother, he might be distressed to discover that the email would include "Mummy" in the recipient email address of the message. Awkwardly, names aached to email addresses are passed on when a user forwards or replies, so if the message were about some maer of state that involved advisors, it might make its way around all the oces of Buckingham Palace until eventually every message sent to the Queen is addressed to "Mummy."

If the Prince were to make this mistake, I would argue that we would have to forgive him, on the grounds that he legitimately assumed that the Contacts app used a concept that we might call nickname that lets you use a convenient alias or nickname in place of a longer phone number or email address. at concept

keeps the alias private, so from that perspective the behavior of the Contacts app is deviating from familiar expectations.

In Apple's defense, we might argue that the concept never was nickname; from the start it was a contact concept that lets you store all the information you have about someone, including their full name. e Prince was misled by the fact that he happened to look up contacts by name, but Apple's app does lookups and autocompletion equally on phone numbers and email addresses. His expectations were also shaped by using contacts for phone calls (in which no name is ever sent) before he used contacts for emails.108

In this case, there is no right or wrong answer; the point is simply that familiarity with a concept, and the concomitant expectations it brings, are powerful factors that must be taken seriously in design.

Lessons & Practices

Some lessons from this chapter:

• · A good designer knows not only how to invent new concepts, but also when not to invent at all. If your purpose is addressed by an existing invention, you're beer o reusing that.
• · A concept is like any other invention in this respect. What's new is that concepts provide a way to structure knowledge and experience of soware design in small and coherent pieces, allowing more granular opportunities for reuse.
• · e easiest way to make a design usable is to build it from familiar, preexisting concepts. Using polished and well-understood concepts reduces the chance of mists, and makes the design intuitive to users.

And some practices you can apply now:

• · Before you invent a new concept, brainstorm existing concepts to see if there is one that meets your purpose. Remember that the concept you need may come from a very dierent domain.
• · When mapping to a user interface, a need for unconventional widgets may suggest that the underlying concept is itself baroque and unconventional.
• · If an existing concept seems to only partially meet your goal, rather than modifying or extending it, explore whether it might be composed with another familiar concept to give the functionality you need.

10: Concept Familiarity

· When the behavior of concept actions is unpredictable, and several possibilities seem equally likely, the concept design is likely at fault. A good design has a quality of inevitability about it.

Draft: not for distribution or quotation. © 2018 DanielJackson

11

Concept Integrity

When a system comprised of concepts executes, each concept runs as its own lile machine, controlling when an action may occur, and what its eect on the concept state will be. Synchronizations can constrain actions further, by making the actions of one concept happen together with certain actions of another concept.

One concept cannot modify the state of another concept directly, or somehow change the behavior of one of its actions. is is critical, and what makes concepts intelligible in their own right.

But this modularity only holds if concepts are properly composed, using the synchronization mechanism of Chapter 6. If the framework in which the concepts are implemented allows them to interact in other ways, or if there are bugs in the code, a concept may behave in an unexpected way, violating its specication.

e designer can also break a concept, tweaking its behavior so that, in composition with other concepts, it conforms to the needs of the particular app. Some adjustments might preserve a concept's specication while adding some new functionality, but others might break it.

For all these reasons, it is critical that the integrity of a concept be maintained when it is composed with other concepts. In this chapter, I'll show you some examples of integrity violations and the problems they cause.

Some integrity violations (such as our rst one, e Revengeful Restaurateur) are blatant and easy to x once discovered. Some (such as the second, Font Formats) are subtle and represent an ongoing design struggle that has yet to be resolved. Some (such as the third, Google Drive) are unsubtle but xable only with considerable eort.

A Blatant Violation: e Revengeful Restaurateur

Imagine a restaurant reservation app with a reservation concept with actions to reserve and cancel tables, and a review concept that lets users post ratings of restaurants they've visited.

Each of the two concepts has its dened behavior and its operational principle: for reservation, that if you reserve and turn up at the right time, a table will be available; for review, that aggregate ratings reect the individual ratings that were previously submied.

When these concepts are composed, the designer can synchronize them together. For example, she might decide that you can't review a restaurant until you've reserved it (or maybe even dined there). is synchronization will constrain the app by ruling out certain behaviors—in particular, ones in which a user reviews a restaurant they never made a reservation for. Despite the synchronization, every behavior of the app will still make sense when viewed through the lens of a particular concept.

Now suppose a restaurateur, frustrated by bad ratings, decides to hack the app to punish ungrateful customers. He modies the behavior so that a customer who enters a bad rating is able to make a subsequent reservation, but then nds—even though there was never a cancel action—that when they arrive at the restaurant there is no record of the reservation, and thus no table.

is hack does not correspond to any legitimate synchronization. Not only does it couple together the two concepts, but it breaks the reservation concept. e operational principle of that concept says that if you make a reservation and don't cancel it, a table will be available. With this hack, the principle no longer applies, and the app cannot be understood in terms of the original concept. is is what I will call an integrity violation.

Suppose, on the other hand, the revengeful restaurateur hacked the app so that when any customer posts a low rating, a cancel action is performed on any reservation the customer has at any restaurant. e poor customer probably gets a notication (due to synchronization with the notification concept) of the cancellation, despite never intending to cancel.

is behavior, however mean-spirited and annoying it might be, does not violate integrity because the new behavior is perfectly understandable in terms of the specication of the reservation concept. It might annoy the customer to

11: Concept Integrity

fig. 11.1 e format toggle concept in the rst versions of MacWrite (1984).

discover that a cancellation has been issued without their consent, but the behavior is still consistent with the concept (its specication being silent on the question of who is allowed to cancel a reservation).

Font Formats: A Long-Standing Design Problem

In the rst word processors, text was formaed with three simple properties: bold, italic, and underline (Figure 11.1). Each property had an associated action that toggled it, so if you applied the action bold to plain text, it would become bold; and if you applied it again, it would return to plain. is concept is so familiar and remains so widely deployed that it seems silly to have to name it. But for the sake of our discussion, let's call it format toggle. You can nd it today in thousands of apps from email clients to embedded rich text editors.

Another important (and early) concept for formaing text is typeface. Its behavior is simpler: there's a list of typefaces, and you can choose one and apply it to some text. In the early days, the format toggle concept was implemented as a transformation that was applied to the characters provided by the typeface concept: a character was italicized by applying a slant to the leer form, and made bold by a dierent transformation that increased the weight.

Real typographic italics, however, have never been just slanted versions of the roman forms, but are typically more owing and calligraphic; nor are the

fig. 11.2 Integrity violation example in TextEdit: bolding once (second line) turns the text om light to bold; bolding again (third line) leaves the text in regular, not light.

bolder versions of type just faer. Computer typography advanced, and with the advent of PostScript fonts, it became common to provide distinct bold and italic versions of the typeface in separate font les, and to use transformations only for scaling. e implementers of word processors were able to maintain both concepts, format toggle and typeface, by a clever trick. When you set some text to italic, it switched to the italic font le; seing it to bold would then switch to the bold-italic font le; seing it to italic again would then switch to the bold font le; and so on. In this way, the design preserved the integrity of both concepts.

en, with the arrival of professional fonts, trouble hit. Now, instead of just having a few variants of each typeface, a much larger collection was provided. e dierence between these and the old fonts is usually additional weights such as semibold (between roman and bold) and black (heavier than bold), as well as additional variants for use at dierent sizes, such as a display font (for text set in very large sizes), or a caption font (for text set in very small sizes).

With these enrichments, all hell breaks loose, and format toggle no longer works. Figure 11.2 shows what happens in Apple's TextEdit. You can see I've selected the typeface family Helvetica, which has six variants. e rst line was set in the Light variant. I then copied the text to the second and third lines. To the second line, I applied the bold action once, and to the third line I applied it twice. If format toggle works correctly, applying the bold action twice should take you back to where you started, so the rst and third lines should look identical. But they don't, because applying bold once changed the type from Helvetica Light to Helvetica Bold, and applying it again changed it to Helvetica Regular (and not back to Helvetica Light).

11: Concept Integrity

Char	racter Style Optic	ns
	Name: Emphasis	5
Basic Characte	r Formats
Font Family: Font Style:
Size:		∨ Leadir
Kerning:		∨ Trackin	ıg: 🗘 🔻
Case:		Position	n:
■ Underline ■ Ligatures ■ No Break ■ Strikethrough

fig. 11.3 e character style dialog in Adobe InDesign: formats are specied by selecting styles such as Italic and Bold, which undermines the value of partial styles.

In short, the implementation of format toggle in TextEdit does not meet its specication, but not because there is a bug in the code. e problem is a deeper one, and involves the interaction between the two concepts. e extension to the typeface concept has broken the format toggle concept.

Apple tried to x this problem in its productivity apps such as Pages. e dialogs looks just like TextEdit, but the bold and italic actions behave dierently. If you bold some text in Helvetica Light, it will now be in Helvetica Bold (naturally); if you bold it again, however, it will be back in Helvetica Light (in accordance with the specication of format toggle). But this behavior is achieved with some hidden magic, which introduces new problems.111

is critique might seem nitpicky, but it's actually a serious problem in desktop publishing. Figure 11.3 shows the character style dialog in Adobe InDesign. Here, I'm dening a style called Emphasis to be used for text that is to be emphasized. By making it a style, I am hoping to be able to factor out whether some text is emphasized from how it is emphasized (by italics, bold or even underlining, say). For an initial denition of the character style, I've selected the "font style" Italic. Note there is no selection for the "font family"; this is essential, because it allows the character style to be applied to text in dierent typeface families.

At least that was my hope; in fact, it doesn't work. To apply this Italic seing, InDesign switches the typeface to the one whose name is the typeface family concatenated with the string "Italic." So if the text is in "Times Regular" it will

set it to "Times Italic." So far so good. But if the text is in "Helvetica Regular" it will try to set it to "Helvetica Italic." As you can see from the TextEdit screenshot (Figure 11.2), my version of Helvetica calls the italicized form "Helvetica Oblique." So the character style is not in fact typeface-independent, and can only be applied successfully to text in certain typefaces.

ere have been other aempts to x this problem, but there seems to be no satisfactory solution. e format toggle concept just cannot be reconciled with more sophisticated typographic concepts.

Losing Your Life's Work with Google Drive

My wife keeps most of her work documents in Google Drive. Having seen accidents in Dropbox (Chapter 2), I was worried about her losing her work, and began looking for ways to protect it.

I learned that Google Drive itself does not provide backup,112 so I would have to devise my own scheme. An obvious idea came to mind. I would install the Google Drive app and keep all of her cloud les synchronized to a folder in her local disk, and would then add that folder to the selection set of the backup utility that I already had running on her laptop. at way, whenever one of her Google Drive les was modied, the local version would be updated, and would then be backed up to the cloud.

I was surprised to discover that this apparently straightforward scheme does not work. Searching online to see if anyone had come up with a solution to this dilemma, I came across a sad story of someone who had relied on a variant of this scheme and paid a heavy price.

e story is illustrated in Figure 11.4. On the le is the starting state, in which there are two les, book.gdoc (a Google document) and book.pdf (a PDF export of the document), both stored in the Google cloud and synchronized to the Google folder on the local disk. Our protagonist then moves the les out of the folder on the local disk, resulting in the state shown in the middle. e Google Drive synchronizer then runs, and seeking to make the contents of the local folder and the cloud folder identical, it removes both les from the cloud.

At this point, you might imagine that, whatever happens to Google Drive, the les are safely stored on the local disk. Sadly, this was not the case. As our hapless user reports:

11: Concept Integrity

fig. 11.4 Integrity violation in Google Drive: the cloud-app concept breaks the synchronization concept. A user moved les out of his Google drive in order to make space in the cloud, but the les he moved turned out just to be links to les in the cloud that no longer existed.

e next morning, I go to open a .gdoc le and get this error: "Sorry the le you have requested does not exist." My heart sank. What happened to the work om yesterday? I opened another le. en another. All of them the same message. I was starting to eak out.

Indeed, most of his les were gone, for good.113 His summary: "I lost years of work and personal memories that I saved as Google Docs les because of a poor user interface." As we shall see, though, the problem was deeper than the user interface: it was a concept integrity violation.

Our user was relying on the behavior of synchronization. e purpose of this concept is to maintain consistency between two collections of items; the operational principle is that any change made to one collection is propagated to the other. Synchronization, unlike backup, also propagates deletions; this allows you to keep items organized. A fundamental property of synchronization is that the copies of the items in the two places should be identical.

Unfortunately, the Google Drive synchronizer does not always create faithful copies. It does for conventional les, such as book.pdf. But for Google app les, such as book.gdoc, it doesn't copy the le's data to disk at all. Instead, it creates a le that contains just a link to the le in the cloud. at's why aempting to open the le on the local disk produced an error message: clicking on it opened a web page in the browser for a le in the cloud that no longer existed.

In addition to synchronization then, there's another concept at play, which we might call cloud app. is concept embodies the idea of documents in the cloud that are accessed through a link. In concept terms, combining the two concepts has violated the integrity of the synchronization concept.

From a concept design point of view, there is no obvious barrier to xing this problem (in contrast to the case of the format toggle concept). I suspect it's just not a priority for Google to implement a solution, although it's surprising that more users of Google Apps aren't more concerned about not having backups.

Lessons & Practices

Some lessons from this chapter:

• · When concepts are composed to form an application, they may be synchronized (as explained in Chapter 6) so that their behaviors are coordinated. is synchronization may eliminate certain behaviors of a concept, but can never add new behaviors inconsistent with the concept specication.
• · But if the concepts of an application are assembled incorrectly, behaviors may result which, viewed in terms of the actions and structure of a particular concept, break that concept's specication.
• · ese integrity violations confuse users, because their mental models of concept behavior are broken.

And some practices you can apply now:

• · When designing an app using concepts, even if you are not dening synchronizations precisely, at least convince yourself that every interaction between concepts can at least in principle be viewed as a synchronization.
• · If you're having trouble using an app, or analyzing a usability problem, and you discover that a concept is behaving in an unexpected way, ask yourself whether interference from another concept may be to blame.
• · To ensure integrity, make sure that a concept that purports to be generic really is. In the Google synchronization example, the integrity violation is evident in the non-uniform way in which dierent types of les are handled.

fig. 11.5 A pictographic summary of the principles of Chapters 9 to 11. A line between a purpose and a concept indicates that the concept fullls the purpose; the broken line (for the integrity violation) indicates non-fulllment, due to the interference of another concept; lines between concepts denote composition; doed boxes represent applications.

Draft: not for distribution or quotation. © 2018 DanielJackson

Questions to Remember

In closing, I'd like to review the key ideas of the book, and suggest how readers in dierent roles might apply them. e suggestions are organized around a series of questions.

For Strategists, Analysts, and Consultants

For those strategizing about a product and its evolution, the identication of concepts and their value dominates, with the design details of individual concepts taking a back seat.

What are the key concepts?

Consider the system, service, or application to be built—or the one that already exists—and ask yourself what its key concepts are. By constructing an inventory of the concepts, you'll get a bird's-eye view of the functionality, a kind of landscape within which to consider your strategic moves. Arrange the concepts in a dependence diagram to see how they are related to one another, and which ones lie at the core.

How old are your concepts?

When you look at the concepts in your existing system, determine when each concept was introduced, and investigate whether it has changed over time or remained stable. Are there concepts that have morphed dramatically (like Facebook's post—see Note 48) signaling a major shi in the entire system or becoming new concepts as they evolved? Have some concepts been introduced and then retired? Which have most successfully stood the test of time?

What are your most valuable concepts?

Do you have a killer concept (like Photoshop's layer or the World Wide Web's url) that is responsible for the success of your product and your competitive

advantage? Are some concepts (like Gmail's label) the linchpin of your product without which it could barely function? Are some concepts key to revenue, perhaps because they dene a premium version of your product, or because they bring the greatest value to your customers?

Do you have troubled concepts?

Does your product include concepts that have confused users, as evidenced by frequent help requests, or whose complexity has led to a disproportionate share of defects or system outages? If so, are these troubled concepts shared with your competitors, or might they be self-inicted wounds?

What shared concepts dene this family of products?

If you view several of your products as members of a single family (such as Adobe Creative Suite, or Microso Oce), can you identify the key concepts that are shared between them? Are these shared concepts implemented using a common infrastructure, or are they implemented anew in each product? Are the various instances of a shared concept consistent with one another, or are there small and perhaps arbitrary dierences between them? Do those dierences create problems as users move from one product to another? Do they cause integration and data sharing problems?

Maybe the products belonging to the family don't currently share concepts, but they could in the future if concepts appearing in multiple products were unied. Would such a unication bring benets not only to the family as a whole, but also to the individual products?

What is the purpose of each concept?

For each concept in your inventory, can you give a simple and compelling purpose? Do these purposes contribute to the larger goals of the product, and the vision of your organization?

Whose purpose does each concept serve? Does the purpose serve the interests of your customers? If so, which customers does it serve—the users or the advertisers? If it serves the interests of your organization, does it exact an unnecessary cost from customers? Are the purposes that are intended to serve the interests of customers communicated eectively to them, and do they align with their true needs?

Are there missing concepts?

Can you identify a purpose that is not being fullled that suggests a missing concept (such as the correspondent concept missing from email clients)? If you can identify such a concept, is there an opportunity to add it to your product, and thus acquire a competitive advantage?

What are your competitors' concepts?

Look at the competing products in the same domain, and inventory their key concepts. Do they dier from yours? Are the concepts that you have and that your competitors lack signicant? Do they give your product an advantage, or are they a source of needless complexity? Are the concepts that your competitors have but that you lack a threat to the future of your product? Have you adopted industry-wide concepts? If so, do they make it easier for new customers to start using your product? Or do these concepts trap you in the awed assumptions of past products?

For Interaction Designers & Product Managers

Many of the questions that apply to strategists and consultants also apply to interaction designers and product managers, but there are new questions focused on the design and mapping of individual concepts, and on tracing usability problems back to concepts.

Are the concepts consistently conveyed to users?

Does your product succeed in projecting—through its interface, user manual or help pages, training and marketing materials—a mental model that matches the actual concept model? Review the way that your product's functionality is described in the user interface and all supporting materials. Do these all present a consistent image of the product's concepts? Is there a common vocabulary for concepts and their purposes?

How are concepts explained?

Are the product and its associated support materials organized systematically around concepts? In your support materials, do you explain what the purpose of each concept is? Do you sometimes fall into the trap of explaining in detail

what a concept does, without explaining what it's for? Do you provide compelling usage scenarios, and do they highlight the operational principles that show convincingly how the design of each concept fullls its purpose?

What kind of usability problems do you have?

Reviewing feedback from users and requests for technical support, can you identify the primary usability problems in your product? en, for each problem, can you determine what kind of problem it is, assigning it to one or more of the three levels of interaction design?

Which concepts make you happy or sad?

As a designer, you undoubtedly have a deep understanding yourself of the product and its qualities. Make a table for aspects of the design that are successful, problematic, or something in between. When you've lled up this table, review each item, assign it to a design level, and for all those items that turn out to be conceptual, name the concept that is responsible.

Are any of your concepts redundant?

Can you nd redundant concepts (like Gmail's category concept) that serve the same purpose of other concepts in your product, giving you the possibility of simplifying and clarifying the design by eliminating a concept, and extending the other (if need be) to cover the functionality of the eliminated concept?

Are any of your concepts overloaded?

Do you have concepts (like the cropping concept in previous versions of Photoshop—see Note 101) that seem to serve multiple purposes? If so, these might be the cause of usability problems. Can you nd scenarios in which the dierent purposes of a concept conict with each other? If not, can you formulate a coherent and compelling purpose that encompasses those apparently distinct purposes, thereby arguing that the concept is, in fact, not overloaded aer all?

Can some of your concepts be split?

Look at your more complicated concepts, especially those that are overloaded, and consider whether you might split them (as we did with Facebook's like concept) into multiple concepts, each with a simpler and more compelling pur-

12: questions to remember

pose. Might doing this give you an opportunity to use a concept more widely and uniformly in your product? For example, if you factored a notification concept out, could you provide notications of a wider class of events, and give the user control over which notications occur?

Are familiar concepts used eectively?

For each of the concepts in your product, ask yourself whether there is a more familiar concept that might take its place. Are any of your concepts (like the section concept of Microso PowerPoint) close in purpose to existing, more familiar concepts? If so, would anything be lost by replacing them with their more familiar counterparts? And if you determine that your use of an unfamiliar concept is justied, are the ways in which it diverges from more familiar concepts made clear and understandable to users?

How are concepts composed?

Which concepts are tied together by synchronizations? Can you draw synchronization diagrams to show which actions are tied together? What kinds of compositions do your synchronizations achieve: free, collaborative or synergistic? How much of the power of your design comes from synchronization, and how much from the concepts themselves?

Do you have under-synchronizations?

Are there cases in which you could spare the user some manual work by increasing the synchronization between concepts, so that some actions are performed automatically? Could such synchronizations be provided as defaults for naive users, and in a more customizable form for experts?

Do you have over-synchronizations?

Are there cases in which concepts are synchronized too tightly, taking too much control from the user? Would more orthogonality between concepts (that is, a looser synchronization) give the user ner control, making available functionality already present in your concepts?

Are you exploiting synergy?

Do your existing concept compositions create synergies (as with the trash/folder example), in which one concept amplies the power of another? Can you nd additional opportunities for synergy? One way to think about this: could you adjust the behavior of one concept, perhaps generalizing it slightly, so that it could incorporate some of the behavior of another concept, but oer that behavior more consistently and widely?

Are the concepts mapped eectively to the user interface?

Does your user interface present concepts transparently to the user, or are the concepts buried under a layer of complex controls that makes it hard to see them and keep them separate? Is it easy for the user to discover how to select actions and their arguments? Is the state of each concept visible to the user? Does your user interface make not only individual concept actions available, but also more complicated sequences of actions that users are likely to need?

Have you analyzed your concept's dependencies?

Construct a dependence diagram for all the concepts in your product. Is the justication for each concept solid in terms of the concepts it depends on? Does the diagram suggest subsets you had not considered, perhaps for simpli cations of the product?

Are the concepts assembled with integrity?

Each concept may be sound in isolation but undermined when combined with other concepts in the product as a whole. Does the design preserve the integrity of each concept? Or are there subtle ways in which a user's understanding of a concept has to be modied due to interference from another concept?

Is your concept wisdom safely documented?

A concept design may evolve over many years, accruing a host of xes and re nements from multiple generations of designers. If this knowledge is captured only in the code, then—as the fate of the range concept in Apple Numbers suggests—it can be lost when a new programmer is unaware of subtleties, and makes a change that erases years of insight in seconds. For this reason, it's im-

12: questions to remember

portant to maintain a design journal for a product that tracks the development of each of its concepts. A briefer concept catalog or handbook that records the distilled wisdom of each concept the company has designed can enable sharing between products and help bring new designers up to speed.

For Technical Writers, Trainers & Marketers

Some additional questions apply to those who provide the crucial materials that users turn to in order to become familiar with a product and gure out what to do if they get stuck.

Are the supporting materials organized around concepts?

Are the user manuals, help functions and technical support articles organized around the key concepts? Are the actions of a concept explained together, in a coherent way?

Do you give clear purposes for concepts?

When introducing a concept, do you explain why the concept exists, what it's for? Do the purposes you give satisfy the criteria of well formed purposes (cogent, need-focused, specic, evaluable)? Have you avoided misleading metaphors?

Do you explain the operational principle of each concept?

To explain how to use a concept, do you give a compelling operational principle, or do you just list actions and leave the user to gure out what the archetypal usage scenario is?

Are concepts explained in a rational order?

If some of your materials (a user manual, for example) are sequential, do they present concepts in an order that is consistent with the dependence diagram, so that each concept can be motivated at the point at which it is introduced without forward references to concepts that have yet to be explained?

For Programmers and Architects

e above questions about the concepts, their purposes, and their relationships to one another are all fundamental for implementers too. e depen-

dence diagram can be used to phase development incrementally, and to plan partial releases.

What set of concepts forms a minimum viable product?

is is of course a vital question for strategists too, but it has particular signi cance for implementers because they can more readily assess the costs of building the concepts.

Which concepts will be challenging to implement?

Can you identify which concepts will be the most challenging to implement? Which concepts have the most complex state, or will present performance challenges because of the volume of data they will embody? Do the operational principles of any concepts hint at consistency problems that may require distributed consensus algorithms? If so, might eventual consistency suce?

Can you avoid reinventing the wheel?

If you're implementing a familiar concept, can you nd implementations of that concept in your own organization or elsewhere that will give you guidance and help you avoid known problems?

Are standard library concepts used where appropriate?

Has your designer invented a concept that requires a non-standard library or plug-in, when a standard one might have been just as good? Is there an existing implementation that is close enough to a proposed concept that it may be worth adjusting the design to accommodate it?

Are concepts as generic as possible?

Are the concepts in the design needlessly specialized to particular datatypes, or could they be expressed generically? For example, if the design includes a comment concept, is the target of a comment any item, or does the design (and worse, the implementation) assume that the target is always a post or an article?

Can you implement the concepts as separate modules?

If your implementation entangles concepts together, is the lack of modularity really justied? Or are you building up technical debt that will eventually have

12: questions to remember

to be repaid? If you have succeeded in modularizing concepts, are there code dependencies between them that can be eliminated so they can be modied and reused more easily?

Are there complex synchronizations between concepts?

If the product relies on concepts being synchronized in rich ways, does the synchronization produce complexity in the code? If so, might there be a beer way to organize it, for example using an event bus or implicit invocation architecture, or by using callbacks and dependency injection?

Do some concept actions involve complex conditionals?

Do some of your concept actions perform elaborate checks on their arguments, or have a complex conditional control ow? If so, this might be a symptom of a troubled concept. Might such an action represent multiple actions (dependent on the arguments presented) within the same concept? Could spliing into several distinct concepts simplify such actions? Is a lack of synchronization between concepts leading to inconsistent states that should not have to be handled?

For Researchers and Soware Philosophers

ere are many important questions that my evolving theory of concepts cannot yet address. Maybe some of you will be inspired to take up the challenge and help build a more complete theory and method of concept design. With that in mind, here are some open questions.

How should a concept catalog be structured?

A catalog or handbook of concepts would allow designers to codify their knowledge, making it easier for novices to acquire expertise, and would encourage greater reuse of concepts and help designers avoid known pitfalls. How should such a catalog be structured? Should catalogs be domain-specic (e.g., a catalog for social media apps, and a catalog for banking) or should a catalog emphasize concepts that cross domains?

Are there composite concepts?

I have explained how concepts can be composed together, and how sometimes the remedy for an overloaded concept is to factor it into multiple concepts. When a concept is decomposed into smaller concepts, does the larger entity remain as a concept in its own right, and with its own purpose?

Are there dierent kinds of purpose?

I have given criteria for what makes a good purpose, and a coherence test for identifying when a purpose is composite. But I have neglected some important distinctions regarding the role that a purpose plays. e purpose of a concept, as I explained, motivates its inclusion a design. But inclusion can mean two different things. One is related to the general benet the concept brings; the other is the particular benet that it brings in contrast to other concepts that might have been used instead.

For example, both the label and folder concepts fulll the purpose of organizing items, and this purpose would motivate including either of them; but only label fullls the purpose of organizing items into overlapping categories. It is not clear to me that this more granular distinction between concepts is even a purpose; perhaps it's a quality that distinguishes concepts with the same purpose.

What issues arise with instantiation of generic concepts?

I've argued that concepts should be stated in a generic form when possible. Doing this allows you to get to the essence of your design, eliminating domain-specic complications that may lead to needlessly unconventional and unfamiliar concepts. When composed, generic concepts are instantiated; when the trash concept is composed with the email concept, for example, the items of the trash become messages. Is there a way to systematically abstract domain-specic concepts (and purposes) into generic ones?

Instantiation of a generic concept may entail composition with a domain-specic concept. In a restaurant reservation system, the generic reservation concept, which knows only about resources, may be composed with a table concept that knows about restaurant tables. Exactly such a structure is imposed by the Google Maps reservation API, which requires restaurants to convert a table

12: questions to remember

that can seat four to six people into three distinct abstract resources. Is this its own kind of composition? Are there general principles that lie behind it?

Is action synchronization enough?

Composition of concepts relies entirely (in this book) on action synchronization. Should concepts be allowed to synchronize on state as well? e synergistic composition of trash and folder, for example, might be expressed as an invariant that relates the items in the trash to the les and folders that are descendants of the trash folder. (See Note 71.)

Can mapping principles be articulated?

Are there general principles for evaluating a mapping? Such principles would presumably rest on well-known principles of user interface design, but would address the connection to concepts more directly. For example, researchers have explored notions of visibility of state (especially with regard to hidden modes), but usually in the simpler seing of a single state machine. What visibility rules might apply to an app composed of concepts?

What role do assumptions about user behavior play in concept design?

Some concepts fulll their purposes only when users behave in a certain way. e password concept, for example, can only provide eective authentication if users pick passwords that are not guessable, remember their passwords, and do not share them. Could such assumptions be expressed as prerequisites of the operational principle?

Can concept implementations be fully modularized?

Concept design suggests a new programming idiom. I explained (in Note 81) why a traditional object-oriented style of programming typically leads to undesirable couplings, oen producing a structure in which the dependencies point in exactly the wrong direction. A direct implementation of concepts as modules might produce a more exible and decoupled codebase (see Note 32). What kind of modularity mechanisms would allow exible synchronizations and compositions?

Microservice architectures might be a useful basis for concept implementation in which each microservice represents a single concept, and so might be

called a "nanoservice" instead. How are nanoservices dierent from microservices? Can they be synchronized in the manner I've described, without the usual dependencies in which the internals of one service make calls to the API of another?

Can concept design aws be detected in code?

Ill-formed concepts confuse not only users but programmers too. When experimenting with a conceptual design issue in an application, I have oen found the application crashes or exhibits other failures not immediately related to the design issue at hand. I suspect that when concepts are unclear, the code reects the confusion and defect rates rise; this is certainly my own experience writing code. By mapping les in the codebase to concepts, could source code mining or static analysis exploit this connection? Might conceptual confusions at the design level be predicted by higher defect rates in the code? Might concept design aws suggest places in the code meriting more careful review?

Can concepts be applied to internal API design?

Concepts are by denition user-facing. But many of the issues that arise when a program makes internal use of a service or API are similar to those faced by users. Might programs in one layer of an implementation stack be regarded, from a concept design point of view, as the "users" of concepts in the lower layers? If so, could concept design principles be applied to code design?

For All of Us

Beyond all these workplace situations, I hope that the ideas of this book will be helpful in that most common scenario—when we're struggling to make sense of yet another application or feature that isn't quite comprehensible. Maybe a lile concept analysis will reveal what's going on. At the very least, it might make our daily discussions about the technology we use more grounded and substantive, and help us see more clearly the path to beer design.114