Pretty pictures for programmers

How do you bridge the communications gap between developers and users? Try a visual approach

At a certain point, some projects make developers want to cry in frustration: "Just tell me what you want!" That's because the business side's inability to articulate how applications should work remains the biggest obstacle to building apps in-house.

No wonder. Nothing is more tedious than creating a requirements document in the old-fashioned waterfall model, where every application twist and turn and exception must be detailed in mind-numbing prose up front. Most organizations now use more agile methods, with multiple cycles of prototypes and business-side feedback -- yet businesspeople still have trouble expressing their needs in sufficient detail, resulting in too many cycles.

[ Read Neil McAllister's funny take on why user interfaces shouldn't be designed by developers. ]

One new solution to this problem comes from iRise, a startup that produces so-called visualization software by the same name that business analysts can use to mock up the functionality of proposed applications. In the demo I saw of iRise Enterprise Edition, creating lifelike mockups of applications, complete with widget options and logical flow, was fast and easy -- miles beyond tools like Visio.

Specifically designed for non-technical users, iRise can be preloaded with rules and libraries of graphic elements, preventing business users from visualizing their apps off into the stratosphere. Within those bounds, the stakeholders who want an app can rearrange elements on the fly by dragging and dropping -- in a meeting using a video projector, say, with decisions made in real time. The mockup of an application and its accompanying notes becomes a picture book version of a requirements doc.

I know what you're thinking -- there's some kind of funky code generation going on under the hood, right? Not at all. iRise is a communications and documentation tool. On the one hand, it seems something of a waste that all the work on application design results in a mockup and requirements, period. On the other hand, I think that's the best approach for "real" applications: Business analysts can mess around all they like with mashups or modest Web apps, but when the project requires real development, leave the coding to the coders.

iRise's CMO, Mitch Bishop, acknowledges that developers tend to be leery of his product at first: "We get asked all the time 'what's in it for developers?' To be honest, developers are fairly suspicious of visualization when we go into an organization." But they end up liking it, he says, for two reasons: A working mockup not only allows business people to express themselves better, it gets everyone on the same page about what the functionality will be, so there are fewer changes down the line.

Bishop makes aggressive claims about the emergence of visualization as a major new trend. I'm skeptical about that. But I think any tool that helps bridge the gulf of misunderstanding between developers and business is a good thing.