Hello,
I manage an IT desktop application which has about 2k users of various types. The application contains plenty of data which is both user-input and integrated from other Data Bases.
I'm having a hard time finding a design technique to show all of this data to the users. I tried graphs, trees, sphere and more, and couldn't find anything that will satisfy my users.
Each and every group of them wants to see certain pieces of the data, shown differently. Some of them, the managers usually, want to see it all in an overview, some in detail. Havoc.
Do you have any suggestions or tips of design practices for IT apps?
Thanks.

Let them choose what they want to see. In any case give them high quality output. Take a look at designer's infrographs. They are meaningful and beautiful at the same time. Everyone would love them.

Edik, there's no general Occam-razor'able solution to this problem. Some of us are "diagram people," others are "bullet point/ list people," yet another "executive buzzword/ acronym [EB/AS] summary people," etc.

The only somewhat-practical idea that I can supply is this: if your IT desktop application can be massaged to emit and allow subscription of RSS-coded streams of its various components (="user-input and data integrated from outside DBs"), a data-flow that is both textual and "diagramatical," then you should be able to steer your users towards personally profiled subsets of that. To cut down on the number of tools needed, integrate it with browser-native RSS readers, and make sure that each item carries a granular#link back to its source result in the desktop app's output proper (for verification and contextual study purposes).

Because not every user will immediately see advantages of such "some assembly required" strategy, you'll have to teach them that and also how to create such profiled RSS subsets on personal Need-To-Know™ basis. Tell us if it worked.

Supercharged - Letting them choose what they want to see is obviously a good option, but it would require to develop various "views" which is quite time-consuming and hard to accomplish in a competitive and time-to-market oriented environment. This is exactly the reason i'm looking for some proven best practices to avoid developing many different interfaces.

ianf - I'm afraid i didn't completely understand your answer, other than my app is a .Net standalone application which doesn't support any kind of RSS or streaming. The data update pace is also mostly user bound, thus constant feeding is pretty much useless. I'm interested in a well granulated mix of "diagrams" and "bullets/lists/tables" features, just like you mentioned in your first paragraph.

Thanks for the answers though, i hope we can develop a productive discussion here!

With 2k users, you can about forget developing any single, unified view of outputs that'd serve the purpose – which, I take it, is "providing granular, timely and valid data to managers at various levels of the organization, data on which day-to-day decisions will be based." Even if they all had 30" displays at their disposal, that single view would never be the "correct one" for most of them, and they'd risk spending more time weeding out data from the comprehensive view (or one of few such views), than it is worth. Providing too much information at a glance is every bit as dangerous as providing too little.

With that many users you have no option but to provide a TOOLBOX of some sort, and letting the individuals create their own data-flows in accordance with private preferences. I don't know if the .NET IT-app you're talking about has been developed in-house, but presume you have its source code. If you do not - mailto:bill.gates@microsoft.com [end of my advice ;-))]

Otherwise, that's where the RSS component comes in. If you could extend your app's individual modules with RSS-output [which is but streams of XML data], the more granular the better, then letting the end-users subscribe to named streams in their browsers in a mix of their own desire would become that toolbox output I was talking about [e.g. "sales volume of product group A per outlet"; "inventory of product group B per day;" "outstanding orders of product group C per unit price," etc. ]. The managers wouldn't be getting a single well laid-out screenful of diagrams and bullet lists and whatnot, but they'd get it sequentially in their browsers. It's not as elegant a solution as custom application, but it's a start. Every solution is a compromise between cost and utility; the utility here wouldn't suffer too much, while costs of extending the .NET app would presumably stay within reason. Plus, in time, after you've observed the patterns and overlaps in output types, you could attempt to make it more palatable, graphical.

To that end start studying (but do not implement nilly-willy!) Edward Tufte's presentational advice http://www.edwardtufte.com/tufte/ Be aware, however, that the very beauty of Tufte's graphical concepts may be hard to swallow for those managers who are more at ease with more "industrial-grade" output.

Let them choose what they want to see.