Hi, I'm Ryan Singer. I design products and manage teams at Basecamp.

« See my home page for more articles about interface design and product management.

Get the RSS feed to find out when I post new articles.

Follow me on Twitter for a steady stream of thoughts and relevant links.

Feb 5, 2011

"Cohesion" in code, interface and product design

I like finding areas where programming and interface design overlap. One example is the principle of “cohesion.” Let’s take a look at how programmers understand the idea, how designers use it, and what the two have in common.

Programmers say that code is cohesive when functions that belong together are close to each other and functions that don’t relate are far apart. It’s a question of whether the code is one giant bowl of spaghetti or many small plates.

You’ve probably seen PHP projects (or even written them — I have) where the whole project is in one file. Code that’s all mixed together has low cohesion because there’s no separation between functions that handle, say, logging in, and totally different functions like payment processing. Compare that with a well composed object-oriented app where the code for logging in is neatly organized in a Session class and code for payments is bundled inside a Payment class. Code cohension means that the parts you need at a given moment are close together and the things that don’t matter are somewhere else.

For interface design, “cohesion” happens on two levels: the large-scale level of multiple pages and the small-scale level of elements on a single page. First we decide how to divide functions of the product across different pages. What should the user see at the same time? Let’s say the product is a hotel reservation system. What does the front desk staff need to see and do on a single page when guests want to check in and get their room keys? Are there operations that should be placed on different pages — like offering a full refund — because they don’t happen as often?

On this larger scale, a UI is cohesive when information and actions relating to the same activity appear together on the same screen. And actions that don’t relate or aren’t as common are placed at a distance on separate screens. That’s the first level: grouping things into pages and separating them with navigation.

The second level of interface cohesion happens on a single page. There could be twenty different elements on a page. A guest name, a balance, a check-in date, a notice about special requests, a check out date, a button to perform check-in, a function to take payment, and so on. All these elements aren’t placed randomly. They’re grouped into different units depending on their relationships and the way that our eyes scan them.

Elements with strong contrast catch our eyes as they scan the screen. When an area of strong contrast carries a pertinent message (like “Reservation dates”, or “Create a room key”, or “Balance “) a halo of attention settles on that area. With our attention landed, we notice smaller nearby elements that didn’t have enough contrast to stand on their own across the whole page. These elements are grouped together with proximity and contrast to make up a gestalt. The page is then made up of many of these gestalts with space in between them. That’s the second level of cohesion: the page elements are organized into groups that tie elements together and separate them from other groups.

It’s interesting how these different kinds of cohesion on the software side and UI side share the same motivation. The compiler doesn’t care if functions are placed together in a way that is easy to understand in the source code. And the browser’s rendering engine doesn’t care if elements are placed into coherent gestalts on a web page. In both cases it’s the reader who creates the requirement that things should be clearly grouped and separated. The difference is only whether the reader is looking at code or looking at a rendered interface. Programmers have to “use” their code just as much as our so-called “users” use the interface.

This principle of cohesion is one example of how designers and programmers face similar problems in the different software layers. It would be smart for the two to collaborate early in the design process so that decisions about how to cohere the functions of the app can run up and down the stack, from UI to controller to model to data store. The more we can see coherency connecting the layers of the app, the easier it is to hold a clear picture of the system in our heads as we fix, change and improve our software products.

What do you think?