This week I'll be starting another new stage in my career, as I take on the role of Director of User Experience at Traction Software, Inc, marking my return to the subjects you've read me blogging about in the past: design of information retrieval and content management systems, knowledge management, and social networking and social software for the enterprise.

It's with great pleasure that I return to work on the application I used as a client, and to the team that I contributed some interface design work to over a year ago as a consultant. You'll be reading me return to blogging about the topics I mentioned above, but this time from the design and product development end of the conversation. Previously I wrote mainly about grassroots needs for social software and km and how blog/wiki tools meet these needs. In addition, I expect to show details of the application and its use for various forms of personal and enterprise knowledge management. I've used this tool in the past on a range of needs, including serving as a tracking system for usability testing issues, documenting project information (wiki style), and simply for logging my own projects and todo lists (personal km style wiki).

There will be more to come. I look forward to sharing with you.

Register here to get the free TeamPage5 installer. About TeamPage5:

Traction® TeamPage5™ is a free version of Traction Software's award winning TeamPage™ Server product. TeamPage5 supports up to 5 projects (blog / wiki spaces) and 5 named user accounts with individually defined permissions and identities. Projects can also be opened to Visitors (e.g. you can open any space so that anyone on your intranet can read, edit, comment or post). Registration for TeamPage5 provides a personal account on our support server to download software updates, read customer and product FAQ's, and participate in Traction's customer Forum.

Traction® TeamPage5™ is simple to download, install and manage. TeamPage software can be deployed on your intranet, corporate DMZ or on the public internet using a computer that supports Java server software, see TeamPage System Requirements. TeamPage5 provides a free way to create a collaborative communication hub which can scale to meet your future needs. You can easily upgrade to TeamPage15 or TeamPage at any time.

Excellent news for enterprises and now even individuals who are ready to take their knowledge management work to the next level.

It's the little details that make the difference in a clunky design and one that communicates with brevity and elegance. One thing that I've always hated in my Drupal blog is the wordiness of my author/date/comment line. You know what I'm talking about. In node.tpl.php it's the stuff you get when you print out $links.

Well, I resolved to make things cleaner in the next blog theme I work on, so that I can get displays more like this:

By jibbajabba on 21 Feb | 1 comment

Rather than this:

February 21, 2007 - 10:06am
jibbajabba's blog | 1 comment

I know it seems like such a minor thing, but it's little things like wanting to change that, but being too lazy to go figure out how to do it that keep me using the default display in my themes. Well, no more. On the bike blog (Love & Sprockets) I'm going to do it this way:

Or using the format_plural function, which chx pointed out:

Ahhh. I feel better now.

IBM Internet Technology Group chooses Drupal to deploy of a collaborative Web site. The article series describes their project requirements and why they chose Drupal among other CMS frameworks including Mambo, Typo3, Ruby on Rails, Movable Type, WordPress and TextPattern.

Gerry McGovern makes excellent observations on CMS feature simplicity and sustainability of use in his article, "Complexity delivers short-term gain but long-term pain". He bases his argument on the "feature fatigue" phenomenon, cited by researchers at the Smith School of Business, which claims that most people focus on features when buying a product not on usability. The study notes:

"Consumers give more weight to a product's capability benefits and less weight to a product's usability before they use the product than after they use the product-despite the fact that a product's usability strongly influences their satisfaction with the product."

McGovern argues that the same can be said of CMS and that buyers of CMS should beware this tendency to be wowed by features over usability.

Feature fatigue and CMS

The Smith study focusses only on pre-purchase behaviors and perceived satisfaction during use. They say that it's only in the actual use of a technology that you can determine satisfaction. I don't know if the study mentions any data about sustainability, but the article on the Smith study implies that when users of consumer electronics are confronted with complex, unfriendly technologies they may eventually abandon them, as they say "chucking it in frustration".

I'm a believer that satisfaction is a good determining factor when it comes to sustainability and that another statement would also be true. If users are confronted with an easy-to-use technology, they will be more likely to continue to use it. You'd have to prove that, of course and I don't know if it follows logic to simply say that since unusable technology has one effect, that usable technology should have the opposite effect. But it seems obvious. I would go further to say that an even worse outcome is that if a given technology is necessary for running your business and that technology perceived as a user-hostile experience, that it will interrupt the normal flow of one's work and slow the company down.

Putting the feature fatigue concept in the context of enterprise CMS seems a logical analogy. However, there are variables in corporate environments that may make it difficult to make a clean-cut transition out of existing systems unless there is understanding from the top of what pains users lower down the chain. The concept of user satisficing—the tendency to select the first option given that can work for the situation rather than the "optimal" solution—is one phenomenon that contributes to the complex issue of use and sustainability. People make do with what they have.

That leads me to wonder what the path to change is when people have become accustomed to using complex software that is difficult to use? What factors exist in this situation? Are people on the low-end able to communicate upwards what they experience in terms of dissatisfaction? Is that information received? Can it be used to evaluate current technologies as successes or failures in supporting sustainable information management processes?

It may seem difficult to change in the direction of usability and satisfaction when you've invested heavily in technologies that are the cause of your pain. Moving away from a family of products may feel disruptive if bulk licenses are already paid for and staffed to support those specific technologies. But the bottom line for decision makers is that the payoff comes in business intelligence, the ability to make sound decisions based on experience. That past and ongoing experience is retrievable because your employees capture it in an easy to use CMS. Let's look at a few dimensions affected by ease of use to illustrate why it's an important element in affecting a company's bottom line.

1. Ease of use leads to satisfaction with CMS and sustained use
2. Sustainability leads to a richer information repository (CMS)
3. Rich information repositories lead to more meaningful information mining
4. Rich information mining leads to more informed decision making
5. Better decision making leads to fewer dollars lost and more business opportunities

In the end, it's about money. If you believe that ease of use leads to making more money, you start to take it seriously. We need to see some studies demonstrate that. But what we're talking about here in terms of actions is simply ensuring the satisfaction of your key asset, your knowledge workers. To put it simply, if employees are happy to keep adding reusable knowledge to the business, the business benefits in explicit terms that may be traced back to the information capture. If you want to prove it, it would seem that if you can capture longitudinal data to compare the flow of knowledge into the CMS with ease of use and satisfaction dimensions, then you can provide some insight into return on investment.

Evangelizing simplicity in the enterprise (the software user's story)

So the question for corporate decision makers feeling the pain of complex and unusable technology becomes, "how do we sell our company on the idea of usability as a strategic move?" If the revolution can't happen from below, the vision has to come from above. But the people above need to be convinced through the experience. Sometimes, the perfect pitch can go nowhere without concrete examples. The way you sell it is by demonstrating value through use.

First, point out success stories. If you read and agree with 37 Signals' popular ebook "Getting Real" then you don't need to be convinced that simplicity and usability can equal dollars. They focus on simplicity because it ensures satisfaction in 95% (or some high number like that) of their customers. That 95% uses 37 Signals' customers comes to 37 Signals because the specific solutions they provide are the antithesis of what they've used for processes like project management and collaboration. They want small, simple and efficient and they leave satisfied that they can get in, do what they need to do to collaborate or organize their stuff and get back to work. How's that for a productivity pitch?

Second, prove the concept. Set up real world demonstrations. Put it before people and show them how it works. Remove obstacles and make it easy. Provide an open testing period, do a super-short training screencast or cheat sheet and then let your staff have at it. You can set up pre-determined areas for activity and open up the system for personal information management. This way, users determine it's usefulness. But most importantly, they get to try it out and experience an environment that makes their information management process simpler and more satisfying.

I've been privy to demonstrations where vendors allow some testers to use their software beta in order to build up some excitement around their software's release. Vendors get potential customers to start experiencing their sofware ahead of releasing. And if they create an environment of open communication they also get to establish a relationship with their customers. Other benefits include word of mouth recommendations, feedback on improvements,and if their software is well received, better assurance of its use. All of this before they even release the software commercially. It should go without saying that a vendor would benefit greatly from beta tests.

As a CMS customer, a company could follow this lead and do the same thing, testing vendor software in an enterprise environment. Set up a private testing period for a select set of users and create an open environment of communication around it. Let the feedback stream in and use it to build momentum around the technology. If it's received as a simpler, more usable way of doing business, you're on the right track. Use the feedback to improve how it integrates with your processes. Use that feedback to get better usability improvements out of your vendor. When you're happy that your test users are satisfied with the experience, release it to the enterprise and keep the communication environment open.

Using simplicity as a design strategy (the vendor's story)

And how do you employ usability as a strategic factor if you are a software vendor? First, believe that ease of use should lead to satisfication with your product, and that usability in turn leads loyalty to the company in terms of renewals. I hate to sound like a Mac Fanboy, but the Macintosh Operating System is proof of that. Google search may be proof of that as well.

Consider that usabilty and simplicity is one of the key factors making weblogs attractive as replacements for complex CMS in the first place. It's the main reason that many corporates took the leap and tried this new thing, blogs as the 99 cent KM solution. Many were likely comparing the simplicty of blogs to failed KM solutions they bought. Use that knowledge to your advantage. Simplify your experience to show customers a better way.

When the software you have developed has evolved over time into a more and more complex environment, are you out of luck? Of course not. You step back, take a look at the customer's experience of using the software -- everything it evokes as they use it. Find ways to make it easier. Simplify where you can. Remove obstacles. Do whatever you can to take the pain away. Guage satisfaction constantly by listening to feedback and factor it back into improving the user experience with your software.

It may not happen over night, but making your software usable is a worthwhile goal. Overall, it's not impossible to change in the direction of simplicity. More concrete advice is to break the process down into smaller steps.

1. Cement your strategy with user experience and usability as a keystone.
2. Understand your users by creating personas that describe who your users are and what their goals are. Focus design on them (persona-based user-centered design).
3. Describe the use cases that apply to personas.
4. Describe specific scenarios for each use case above. What types of actions would they take with your software in order to achieve goals?
5. Prescribe improvements to the user experience that match with the expectations found in the use case scenarios. Suggesting flow and interaction improvements. Suggest usability improvements to elements of your user interface.
6. Validate the implementations and test against real people.
7. Use the feedback to validate information about the design process you just underwent. Iterate.

That's all there is to it! Well, no, there is a lot more to it, but this is a start.

Food for thought

The Smith study and McGovern's article should be enough food for thought. It's our job as users and makers of software to just understand that satisfaction can be improved when software, however complex or simple in features, is easier to use.

Applying the Smith study's consumer electronics research is just a start I think. It would be valuable if someone did longitudinal studies that track satisfaction and abandonment or sustained use in other areas, especially with regard to personal and enterprise productivity and content management software.

Jeffrey Veen doesn't like open source CMS (OSCMS). He succintly states the most common of purpose of a content management system -- a statement that I agree with completely:

Ultimately, a content management system should be designed to empower writers and editors to do content creation and maintenance themselves. I'd like to see it take a step further: empower designers, information architects, and site owners with the ability to make the CMS work for them.

I couldn't agree more. These are the primary purposes of content management systems -- to allow content authors and managers to publish and manage content. Problem is many OSCMS are designed by and for techies. There is often not enough attention paid to designing for typical content managers, who are not usually technical people, but are people who want to work with a content publishing and management tool without needing to know how things work in the background.

The "of and by the programmers" characteristic is almost an inseparable part of most open source projects. The reason is obvious really. Open source projects are often created to fill a developer need and to provide a community for building the project together. The community codes what they want in order to serve their specific needs as developers who will use what they produce. OSCMS are therefore often unrefined tools until you have a programmer or consultant customize it to suit your needs. And although this probably generally true of OSCMS, I think these systems can be made to be more content manager-friendly without too much effort. But making it friendly enough for everyone seems to be difficult for developers of open source projects, and I can understand why they might see little incentive for doing this.

Take Drupal, for instance. At a high level, a few of us -- including some very talented and well-known web designers -- outlined how certain areas of Drupal could be made more usable. We documented these suggestions on my wiki. Some people wireframed and flowcharted the interaction of some of the components. Some of these suggestions seem to have made into the next release, but apparently not all.

I guess it's hard, with a community-driven effort, to simply make a suggestion like, "Installation should be driven by a wizard following this scenario" or even "Here's the flow and wireframes of the corresponding UI for function x. Go make it happen.". It's just hard to keep all these issues in mind. Dries made an offer to Jeff that he would get behind what Veen might suggest in a design review and make those changes happen. I'd like to see that happen. But I don't know. Adaptive Path exists to make money. Veen would have to buy into the idea that something like Drupal could be a tool they can exploit in their paid projects. But it should be obvious that getting behind it's design and helping guide how it works will mean they get to use a CMS created to suit the needs they try to meet in customer projects. He's first gotta believe that it's a tool worth backing.

I don't have a pitch for Drupal. I use it because I think it works well and I know how to configure most of what I need. Anything more and I usually get some decent answers on the Drupal forums.

Here's an example. I've been working with a customer to develop a document library. Take a look at these wireframes for the project (PDF, 84K) and then come back here. Really simple requirements for this project. Using Drupal 4.5, users are maintaining a repository of support documents. So far so good. These people hated using QuickPlace and we're finding that Drupal is a capable replacement. We can make it more usable, but the reason it's a viable tool is because the required functionalities are there. But it won't be usable until I get under the hood and customize how it looks and feels to the end user.

In my work as an in-house developer and IA, I've generally found that tools unfortunately *do* require both a designer/IA and a programmer to make them usable. They're very often created to suit some common-deonminator of needs, and therefore don't suit any specific needs very well until they're customized. This is perhaps one of the reasons groups with a programming staff might want to build versus buy. What you have with some of the OSCMS available to you out there are merely platforms -- they're only lumps of clay waiting to be molded into things of utility. That said, I believe a lot of the things that Jeff mentions are useful but perhaps not universal. Looking closely at my users' needs (in my case above I look at public users, moderators and administrators) helps me decide where to tweak the tool to make it more usable depending on levels of access (roles).