I spent quite a few years of my career designing user interfaces. One of the software tools I developed was a service creation environment (SCE) used to build and deploy applications that presented speech and telephony interfaces. I was lucky enough to be able to study user interfaces from the perspective of the tools that modeled the application (the GUI the developer used) as well as the voice interfaces the design tool modeled (VUI of the application produced by the SCE).
There are some fundamental UI principles that one can glean from literature, research, and of course from actually creating good interfaces, especially when you are working with creative people. There are some really neat techniques specific to the environment you are trying to make effective, usually with the objective of making things so intuitive that, as a user, you don’t even notice them. Like quality service from a good waiter, you get what you need but are not constantly aware of his presence.
In many ways, all these best practices and UI techniques roll up into a very high level guiding principle – and that is to not “break the flow” of the user. What does this mean? According to Wikipedia, “Flow is the mental state of operation in which the person is fully immersed in what he or she is doing, characterized by a feeling of energized focus, full involvement, and success in the process of the activity. Proposed by psychologist Mihaly Csikszentmihalyi, the concept has been widely referenced across a variety of fields.” (http://en.wikipedia.org/wiki/Flow_(psychology))
So “breaking the flow” means diluting that immersion, sapping that energized focus, and jeopardizing the “success in the process of the activity” through distractions. Some examples of “breaking the flow” for a computer user include making him stop what he is thinking about or entering into the application to consider where to save a file to disk, needing to search through a list of icons to find the right tool for a task, clicking through many unrelated forms to accomplish a task, or having to read help to find a feature. In short, anything that requires the user to turn his attention away from the task he is trying to accomplish to tend to the needs of the software.
I find myself considering this principle as it applies to a broader set of activities in the collaboration process, especially as this area explodes with opportunity. Working collaboratively can inherently “break the flow.” You need to wait for someone to update their section, review your work, or post comments to a forum which will change you next actions. While everyone recognizes the value collaboration can bring, there is often little attention paid to the additional efforts involved.
But here I want to specifically consider the role that the environment plays to fold these necessary collaboration activities into “the flow.” Does the environment help to minimize the “break in the flow” that is part of collaborating? This is a question I have begun to ask myself as more and more computer-based collaboration tools materialize. Does the supporting software minimize interruptions or make them worse? Are the interruptions constantly diverting attention or are they grouped in a way that minimizes changing the train of thought? Are interruptions necessary to collaboration or missed opportunities for transparency? In short, does the environment “break the flow” or support collaboration through existing work habits.
I find the following activities consistently “break my flow.” Having to find a URL of a portal for one of the many teams I am working with so I can check out and download a document before I can edit it – after I have logged in of course. Having to deal with finding a temporary spot on my disk to make an “interim copy” which I then have to upload and check in later. Discovering that the document I wish to work on remains checked out to a coworker who just left for an undeserved two week vacation to Aruba. Getting emails that tell me someone posted the word “Thanks!” to a forum. Having to cut and paste information such as URLs from one collaboration area to another. Oh yeah, and rummaging through long lists of loosely related documents to find the one I am supposed to comment on.
All of these activities have the characteristic of making me figure out some tangential aspect of the collaboration process, interrupting the flow of the work I am trying to get done. Some of these could and should be solved through better interface design in the collaboration tools. Some can be addressed through better integration of tools (e.g. single sign on, well structured portals, searches, and tools that support how I work today such as integration with email and shared disk drives). Some can only be solved by creating social norms around the collaboration process (use “reply all” sparingly).
This idea of “not breaking the user’s flow” is really very simple but often very hard to achieve. It is frequently overlooked as a design objective, especially amongst the more geekish who understand what is going on behind the scenes. To sponsors of development projects, it can feel like a bit of paradox to invest heavily to make something as simple and transparent as possible. When something is elegantly simple, it’s easy to say “what was so hard about that?” Once you see it, it’s obvious. But this is a hallmark of good design in any discipline. Simplicity can be complex to achieve.
So while it may seem obvious, “don’t break the flow” might be a simple guide to help organizations choose, configure, and integrate collaboration tools. I firmly believe it is the critical element to adoption. Like the waiter who can clear your table without interrupting your conversation with fellow diners, a collaboration environment should enable you to incorporate the additional tasks involved in interacting with others so seamlessly that you are not distracted from actually collaborating!
This blog originally published at BlogSpot on December 11, 2007