Category Archives: Design Theory

FAQ: Digital Machine Theory 0.5beta

What is Digital Machine Theory?

It is a method I am developing to teach systems design to interaction design students.

I believe the theory demonstrates how to connect classical systems theory of the Forrester/Meadows school to the practice of interaction design.

The primary assertion is that interaction design may be understood as the design of a digital machine defined in terms of cybernetic principles.


I am not familiar with the terminology used to describe Digital Machine Theory.  Do you have a plain language presentation?

Why yes, I do!

I have prepared a series of 6 short lectures that explain the theory in plain language:

  1. What is a system?
  2. From System to Software
  3. The Conceptual Model
  4. The Interaction Model
  5. The Object Model
  6. The Data Model

What is the value of digital machine theory?

I propose the theory has value as:

  1. a theoretical framework to train individuals in the basics of software design practice
  2. a communication framework for planning the design or redesign of a software application

How did you come to develop it?

It is an outcome of my work as adjunct professor at California College of the Arts Interaction Design Program.  I teach a course called Systems to undergraduates.

Why are you calling it a beta release?

Because I am a nerd.  Also because I feel like beta sets an appropriate (in my world, at least) expectation for the quality level of both the theory itself and the materials I have put together to explain it.  I think it has some good bones, but the whole thing needs some banging on still.  Do so and send me comments, timsheiner at

On the relationship between system, interaction and business models

A very short post to share a simple formulation I have developed for explaining the relationship between the models I find most central in developing interactive systems.

First, a high level statement presenting the models and their relationship:

<business model><interaction model><system model>.

My meaning with respect to the “><” is that you can read this statement from left to right or right to left, or start in the middle.  This is because all the models are connected through feedback loops.

Your choice about where to begin depends on what you know initially, what most interests you, or what direction you want to drive change.

A presentation of the overall system of models in a tree, with more detail about their respective composition is this:

  • Business Model
    • Value Proposition
    • Cost Model
    • Revenue Model
  • Interaction Model
    • Conceptual Model
    • Object Model
    • Data Model
    • Error Model
  • System Model
    • Purpose
    • Objects
    • Relationships

And there it is.

Breaking Down Search and Browse

The point of this post is to describe concisely the technical difference between search and browse.

In so doing I will expose a paradox:

browse experiences are more intuitive but less novice-oriented

search experiences are less intuitive but more novice-oriented.

Examining the Difference

From a computational perspective searching and browsing have a single specific difference:

browse: display objects in terms of a fixed hierarchical structure

search: display objects in terms of shared intrinsic properties.

Let’s examine how this difference plays out in some example interfaces.

Example 1: The Mac Finder

mac finder browsing

The Mac Finder is a great example because, while it prioritizes browsing, it also attempts to integrate the two navigational modalities.

The characteristics of this experience are that:

  • the default interaction mode is browse
  • the organizing principle of the display is directory structure; objects are displayed only in terms of their location within that structure.
    • objects to the left are always closer to the hierarchical root than objects to the right.
    • each pane displays the contents of the selected directory to its right.
  • the design assumption of this display is that the file structure has meaning to the user, and displaying it will help him find his way to the object he seeks.

The overall utility of this display for navigation turns on this last assumption: if the file structure taxonomy has meaning to the user then an interface that faithfully traverses it will be useful to him.

Of course, we all know that this assumption is often not true.  The structure may not meaningful to the user because:

  • he didn’t build it
  • he did build it, but then he forgot the rules he used to build it
  • it is incomprehensibly vast and idiosyncratic like the world wide web.

These issues are in fact different aspects of a single problem: while the concept of using hierarchical categories to organize objects is natural and intuitive, the assumptions underlying any particular taxonomy are arbitrary and idiosyncratic. Thus a browse interface is only efficient as an object-finding tool for a user already expert in the taxonomy being displayed in the tool. Any other user must spend time exploring the hierarchy before he can use it to locate objects of interest to him.

For this reason search is often a more efficient navigational experience because it permits the user to create object displays organized around a particular object characteristic that is meaningful to him.

The Mac Finder affords a transition to search by integrating into the experience in two ways:

  1. the search box in the upper right
  2. the saved search options in the last grouping in the right hand pane.

While these search affordances are visually integrated into the UI, using either of them produces a modal shift in the display:

Mac Finder Searching

The most apparent difference between display modes is that the panes have disappeared.  With them has gone the concept of directionality or left to right flow because that presentation relied upon the assumption that the most important object property to display was the container in which the object was located.  Instead this display groups objects in terms of a user-defined search query, in this case ‘search mode’.

And yet, in this example, reference to structure is still provided as a refinement feature.  At the top of the display pane there is a set of controls that can be used to set the search scope (where to look for objects) and the search field (what to look at within each object):

scope bar

These buttons represent a type of affordance called a filter.  Interacting with them provides the user with a means to reduce (or expand) the objects matched by his search in terms of additional dimensions beyond the query string.

Put another way, these buttons expose to the observant user that the true search expression is more complicated than simply the text query he entered.  In fact the complete expression involves, by default, certain types of metadata.  The fact that the Mac Finder offers structurally-based refinement options by default is an honest reflection that search has been added on top of a system that has as its intrinsic organizing principle the concept of directory structure.

The next obvious question is what about a system that does not have a simple, pre-defined organizational principle? What is the interface that permits users to locate objects in this system?  Let’s consider the world’s most successful example of this kind of interface: Google.

Example 2: Google Search Results

Google Spelling disambiguator

The Google search results page is excellent counter-example to the Mac Finder because it comes at the problem of directing users to objects of interest from the absolutely opposite perspective.

The characteristics of this experience are that:

  • the default interaction mode is search
  • the organizing principle of the display is the user’s query; objects are displayed in terms of their relevance to this query
    • objects at the top are always more relevant (per the rules of Google’s search algorithm) than objects below
    • each listing highlights (literally) the way it is relevant to the user’s query.
  • the design assumption of this display is that the search term has meaning to the user, and organizing objects around it will help him find the best match for his query.

The overall utility of this display for navigation turns on this last assumption: if the query describes the user’s true interest then an interface that displays objects relevant to that query will be useful to him.

Of course, we all know that this assumption is often not true.  The search may not return results meaningful to the user because:

  • the query is spelled incorrectly
  • the query is ambiguous
  • the search algorithm defines relevance in a way that is not intuitive for the user

These issues are in fact different aspects of a single problem: creating a precise rational expression that represents our current interest is hard for people to do. Recognizing this issue, the Google experience provides a number of subtle cues and affordances that help an inherently irrational human create a concise and rational search expression.  In fact, in the image above we can see how Google automatically offers a spelling correction to address one significant source of error.

In the image below we see another tool that Google provides to help users create more specific queries called facets.

Screen shot 2009-11-21 at 10.44.50 AM

Selecting any of the choices in the left pane narrows the results in the right pane accordingly. If multiple selections are made they are applied sequentially to produce a more and more refined set of results. It turns out that this refinement experience feels very browse-like even though it does not actually result in traversing a single fixed taxonomy. This suggests a clarification to the statement that the process of browsing is intuitive. In fact what is intuitive is the process of refinement: iteratively evaluating and editing information until I have thrown away enough of what I don’t want that I can see clearly that which I do want.


Thus we conclude our brief tour of these two interfaces with the interesting observation that, in an effort to overcome the limitations of browse the Mac Finder offers search and, in an effort to make search disambiguation more intuitive Google offers facets as a browse-like option.

Here, then, are our design takeaways:

  1. The more navigating your system feels like a process of refinement the more intuitive it will feel
    1. Navigation tells a story; told correctly the end coincides with the place the user wants to be
    2. His reward for each navigational decision he makes should be an obvious elimination of information from his view
  2. Because browsing is for experts there are only two cases where a browse interface is good design:
    1. You are certain your users will be experts in the system taxonomy
    2. You are certain you want your users to become experts in the system taxonomy
  3. Except for the two exceptions the best choice for navigational design is to base it upon search
    1. Search is better for novices because it does not require an expert understanding of the system taxonomy
    2. Most people are novices with respect to most system taxonomies
  4. A search-based navigational system can, but does not have to, include an actual search field
    1. Links can be used as affordances that trigger searches
    2. Facets can be used to offer an intuitive refinement experience