Artificial Selection

Evolutionary ideas for designing better interfaces.

We’re all familiar with the concept of “natural selection,” it is the evolutionary process in which biological traits become more or less common through genetics as a result of interactions with the environment. But, what term describes the process in which mechanical objects, such as interfaces, evolve? Mechanical Evolution? Progressive Adaptation?

Much of the change that occurs with interfaces is more intentional and guided than that of actual evolution. With that in mind, the phrase Artificial Selection can be used to describe the process in which interfaces seem to “evolve.”At Radius, we frequently discuss how our application can improve our customers’ experiences. Most of the time the results of these discussions yield iterations and A/B tests. Lately, however, we’ve been hypothesizing about how changes to the interface might occur in a more sophisticated way — allowing Artificial Selection to play a role.

Artificial Selection is the gradual, predetermined process in which interface elements and components change as a result of observing a user’s interactions. The interface adaptations are made possible by external and historical information about the user.

There are many possible processes in which Artificial Selection could occur, but this post will only discuss 3 of them: Responsive, Reductive, & Additive.

Responsive processes allow the interface to change based on environment and preferences of a user.

Environmental responses provide a customized user experience by manipulating the scale and layout of the interface to better fit the device and viewport of the user. The building of responsive interfaces has come a long way since I first read about them 10 years ago, but developers and designers have only scratched the surface of responsive interfaces. For example, environmental responses aren’t the only kind of responsive interfaces.

Cooperative responses are changes that work in parallel with the users’ preferences. It is fairly common for applications, primarily search and maps, to provide results that are different, and customized, based on GPS coordinates. This is a cooperative response. Another simple example of a cooperative response would be the elimination of a “home” portal from applications. Instead, the responsive process makes the “home” of the application the page that a user spends the most of their time.

There are 3 options for viewing messages: Inbox, New, & All

Picard spends most of his time in “All Messages,” so the interface uses that location as his “Home”

Riker, on the other hand, spends most of his time in new messages, so that becomes his “Home”

Reductive processes are those in which interface elements are removed, decay, or are not shown depending on the evolutionary stage of a user profile.

A “natural” removal of the verbose components of certain interface elements occurs as users become accustomed to using those elements. LayerVault calls this process “Progressive Reduction.” LayerVault has written up quite the explanation, so I won’t go into details, but you should read their article. Also, their thoughts on what they call “Experience Decay” are especially informative. Below is an example of Progressive Reduction.

Picard begins with verbose buttons “Compose” & “Group” for creating new messages

Once Picard becomes accustomed to the buttons, the verbose components decay

Unlike Progressive Reduction, in which there is a predetermined set of elements that decay, Consequential Reduction is a process that involves decaying or removing entire pieces of the interface. With Consequential Reduction it’s possible for users to have different interfaces from one another. Applications that are robust would benefit the most from Consequential Reduction.

Salesforce is an example of an app with a robust interface. Based on the 80/20 rule we know most people will only use 20% of the features found on Salesforce. The problem is that no one uses the same 20%. What if Consequential Reduction could help Salesforce remove the interface componets that certain users aren’t using? It would work like this:

By default there are 3 options for viewing messages: Inbox, New, & All

As a consequence of not using “All Messages” Riker will no longer see the option

Exclusive Reduction is the minimization of the interface by removing specific components until a user needs to access them. The most common use is for on-boarding or initiation processes.

Exclusive Reduction would also work well in support and help environments. For instance, if a user indicates that help is needed for performing a specific process (or better yet the interface automatically recognizes a repeatable point of failure), it could hide elements not essential to completing the troublesome process. Below, Riker needs help replying to messages.

Because Riker needs help, the interface excludes all elements not related to replying to messages

Additive Processes are those in which interface elements are added. In many cases additions to the interface work in conjunction with reductive processes.

Often certain features are dependent on other functions of the application, and in those instances it is critical for a user to have an understanding of the base feature, before exposing a more advanced option. Proficient Addition is a way of adding new elements to the interface once a user became comfortable with using the basic elements of the interface. This technique is a great way for exposing advanced features to a user.

Riker frequently uses the group message button, and often sends messages to the same group

Because Riker frequently messages the same group, he is given the “Favorite Group” option

Deanna never used “Group Message”, so she has never seen the option for “Favorite Group”

Necessary Addition occurs when a critical feature is added to the application. Typically new features get added to applications and coupled with an announcement modal and/or an on-boarding walkthrough. However, Artificial Selection requires that we Approach Necessary Addition in a way that is more “natural” to the user. Simply put, our modals might be different for each user.

Riker only uses interface buttons to send messages so the announcement highlights the new button

Data, the android, uses interface buttons & shortcuts, so is notified accordingly

I’m sure there are a large number of questions and thoughts on the topic of Artificial Selection. Below are a few of my own questions, but I’m most interested in your thoughts and responses. Feel free to hit me up on Twitter @jgadapee or leave a note here. I’ll likely addend this post with your thoughts and questions.

A few of my questions:

• How much user data can we realistically store?
• How do users resurrect “dead” parts of the interface?
• Where does the “graveyard” of zombie features live in the interface?
• How do we create good measurement algorithms for knowing when it’s time to evolve the interface.
• Is it possible to make the artificial (predetermined) aspect of these processes more natural or automatic?
• How do we allow the Artificial Selection process to influence external communications? i.e. push notifications, SMS, or social networks?

The full, fake messages client:

I know Darwin never studied Toucans.