paulchinonline.com

Dial 'D' for Intranet Developers, Not Designers

By Paul Chin

Originally published in Intranet Journal's Chin Music (13-Aug-2008)

back back to portfolio


Who would you rather have planning and constructing an Olympic stadium: A team of engineers and architects or a team if interior decorators and designers?

Intranet-based content management systems (CMS) are a perfect marriage of form and function. The system's functionality and feature set allows users to achieve a specific goal while its design contributes to overall user experience and satisfaction. If you want to retain a large user base, you can't separate one from the other.

But an intranet CMS, unlike an Internet website, isn't meant to outwardly market anything. It needs to be functional first; good design is icing. A well-developed intranet with a bland design stands a better chance of surviving than a well-designed intranet with poor functionality. A good design, while lending to user experience, doesn't fulfill an immediate need within an organizational environment. Just look at all the legacy mainframe systems still in use today in larger companies. Do you really think those dazzling (snicker) and eye-popping (snicker, snicker) green or amber screens on rickety dumb terminals are any fun to use? Trust me when I say no because I've used them. These systems—developed in an era when design didn't extend beyond deciding on column alignment—did their jobs and they did them well. But they're about a enjoyable to use as a tooth extraction—yet many are still in use today.

Ideally, those responsible for the development and design of an intranet CMS will have experience and knowledge in both fields in order to maximize user retention. Or, if you're lucky, you'll have dedicated developers and designers working closely together. Unfortunately, due to financial constraints, this isn't always possible and the responsibility is given to a person who shouldn't have it.

Despite the maturity of intranets and CMSs, there are still those who don't know the differences between Internet websites and intranet systems, and leave content heavy CMSs in the hands of pure website and graphics designers with only elementary development knowledge, or with someone in the business process side of CMS development. But there's an inherent danger in shutting out true developers and relying too much on one discipline in a system that demands many.

Oddly enough, the "good news" with many business analysts or communications professionals I've spoken with is that they know that they don't know enough to tackle the project and ask me all the right questions. But many pure website designers know just enough to be dangerous and ask all the wrong questions at the wrong times. They're under the mistaken impression that, just because a CMS is Web-based, they can apply the same design principles and methodologies to both Internet websites and intranet systems.

A pure designer's "process path" is completely different from a developer's. They might be thinking layout, typography, and color at a stage when functionality, content types, and user input haven't even been established yet. Designers can adopt any number of free, open source intranet frameworks such as Drupal and can throw an intranet together that, while high on flash, does little to meet the needs of an organization's user community. And once an intranet is placed in a production environment for any length of time, users can potentially form an unhealthy reliance on an unsuitable system. The system will become a millstone around the necks of users that can't be easily removed.

The participation of true developers, and not glorified designers, is crucial in the development and implementation of a corporate intranet-based CMS. They know how to gather requirements and ask users questions about process and workflow. In my experience, pure designers don't do this very well. So if you ever decide to attend an event at a stadium built by an interior decorator, bring a hardhat and renew your life insurance before heading out.


Copyright © 2008 Paul Chin. All rights reserved.
Reproduction of this article in whole or part in any form without prior written permission of Paul Chin is prohibited.