Web applications have long outgrown the interaction limitations found on the early Web. Today’s online services enable people to do much more than navigate from page to page and fill in forms. The ability to communicate, collaborate, and even create is present in many Web applications. This increase in possibility, however, does not come without consequence.
It’s not uncommon to find a “social” Web application that enables users to email, rate, review, tag, save, share, subscribe to, discuss, and distribute content. It’s also likely that these activities produce playlists, favorites, recommendations, trackbacks, related lists, user profiles, and more. When you add in the metadata about a content object such as source, quality, date, location, description, category, title, format, size, etc. –you are looking at a lot of information and interactions. The sheer quantity of these actions and their outcomes can ultimately overwhelm the content itself.
Fortunately, there’s a set of design methods that can help weather the feature storm that social applications bring with them. Before allowing the rain of tags, comments, ratings, and trackbacks to drown out the content in your interface designs –leverage the power of Epicenter Design and Systems Thinking.
Epicenter design (so named by 37signals) requires a designer to define the primary purpose of each user state. For instance: read a news article, interpret a data set, or send an email message. This definition then drives the design of the screen, its content, and associated actions.
“So, why is Epicenter Design better? The best reason is that it helps you focus on the pure purpose of the page. It allows everything else on the page to be based on the pure purpose of the page instead of the other way around.” -37signals
Systems Thinking gives you the opportunity to determine how elements should be presented within the context of an application. When adding an element to an application consider how it relates to the whole:
- Is it more or less important than other elements in the application?
- Is it very similar or very different from other elements in the application?
- Does it logically fit within specific content or actions?
- How does it relate to the overall goals and vision of the application?
Documenting these relationships provides an effective way to begin building an interface design language that guides user action and understanding. Applying that language each time you design gets you closer to more focused and thereby effective interface design. There’s also a direct corollary between systems thinking design and object-orientated programming. A topic I have yet to dive into.