Nudge Theory and Graphical User Interfaces

Nudge theory is an intriguing fairly new take on how to manage societies and modulate the behavior of people to make them behave in a “better” way. My layman’s interpretation of the idea is that instead of threating punishment and setting up rules, you try to encourage desired behavior with rewards and discourage undesired behavior by making it require an effort. When working with the new Test Runner view in the Simics 4.8 GUI, I realized that we had invented exactly such a nudge.

The Test Runner is a view that shows you all the tests defined for all devices in your current Simics workspace, and it really nothing that special. It shows all the device model unit tests that exist, and whether they have been run, failed, or succeeded.

What was interesting with this view was how it came to affect my use of Simics. In the past, I have honestly not been that good about writing unit tests for my simple test and demonstration devices (the real engineers have been almost religious about doing it, so this just my lazy marketing personality showing through). Now, when I suddenly got a list of all the test that existed I got an urge to fill it. This simply looks far too meager, and I want my views in Eclipse to be full of pretty information. As a result of this nudge, I started adding unit tests to my demos, which is really good for their maintenance going forward.

Another example of a nudge is the way in which the new System Editor makes device and component documentation and metadata stand out. In the past, you needed to go in and do “help” on a device from the command-line to see the documentation strings and short descriptions. Now, in the System Editor, you just accidentally select it and glance and the properties view. This made me go over the same demo devices and update the information to be more complete, better written, and more informative. Making things visible encourages the good behavior of adding good information to the devices. For example:

The System Editor also encourages you to give good understandable names to the object inside a component, so that a new user can understand what they are and how they map to the functionality of the system.

Overall, it was interesting to see just how the simple feature of exposing information that was already there in a GUI nudged me towards building nicer device with more unit tests, better metadata, and more descriptive names.

I highly recommend listening to the BBC programme where I caught on to the idea.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.