September 28, 2009

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.

White Paper

D2D Virtual Tape Library Replication Primer

This whitepaper explains the terminology and concepts behind Data Replication technologies and establishes some sizing rules through worked examples. Learn the new paradigm in disaster tolerance—protect data anywhere.

Download now »

White Paper

An Alternative to Virtualization for Datacenter Cost Savings

Server virtualization is a popular option for dealing with mounting datacenter costs. Another equally promising approach is the use of an Application Delivery Controller. Citrix NetScaler provides a low-cost way for organizations to reduce their server count and accrue cost savings from a reduction in space, cooling, power and personnel.

Download now »

White Paper

Why Your Firewall, VPN, and IEEE 802.11i Aren't Enough to Protect Your Network

The emergence of WLANs has created a new breed of security threats to enterprise networks.

Included in HP ProCurve WLAN solutions is security technology that alleviates threats from WLANs through:
* Monitoring wireless activity inside and out of the enterprise
* Classifying WLAN transmissions into harmful and harmless
* Preventing transmissions that pose a security threat to the enterprise network
* Locating participating devices for physical remediation

Download now »

White Paper

Bringing the Edge to the Data Center

Effectively address data protection challenges, implementing solutions that help store and protect business–critical data while cutting costs and improving efficiency and reliability.

Download now »
prowness 28-Sep-09 11:48am
There could be a kind of placebo effect taking place, where playing with the new toys keeps the users paying closer attention for a longer amount of time, thus resulting in a higher quality spec. It's an area that needs help, so if the improvement is really only an accidental side effect of the technology, that's fine with me.
mulithats 28-Sep-09 1:07pm

This tool might help. In my experience, users know they have a business task they need to accomplish, but the work flow details are difficult to visualize until they get a prototype to work with. Programmers are trained to break things down into very small steps and take nothing for granted, but users are not. Users assume when they ask for a data entry screen certain things that are "obvious" are included, such as moving field to field using just the enter key. Not only is that requirement not "obvious" to the programmer, it can be a completely foreign concept, especially if the programmer has not ever used or even seen a good old fashioned DOS or UNIX data entry application. It is not reasonable to expect users to be able to think like programmers, so programmers need to learn to think like users so they can ask the right questions in terms users can relate to.

mtsinc 28-Sep-09 2:22pm
1 reply
I guess what goes around comes around. Didn't Mitck Kapour or someone like that announce a similar effort in the pre-Macintosh days after VisiCalc got bought? The problem with mockups in IT is that unlike architectural models, where any idiot can tell the difference between a toy skyscraper and the real thing, users look at a computer mockup and figure it can be in production in under 2 weeks. After all, "All you have do do is..."
mwryder 28-Sep-09 3:51pm
You mean something like Demo2? I still use it from time to time when designing screens as I can move things around until it looks right.
TL65 28-Sep-09 8:47pm
Some years ago another project used a tool called "Software Through Pictures". I did not have direct experience with the tool, but the developers had their own name for the tool, "Software Through Pain". I once used a tool that generated requirements documents from pictures. When something in the document needed to be changed, one had to find the text associated with some graphics element in some diagram in order to change it. This was not easy with a real system with real requirements. Experience with these and similar projects may not be applicable to current tools, but a simple demo would not be persuasive.
OpLaunch 29-Sep-09 12:45pm
Since your post did not include any of the cautions from the implementation of 'pretty pictures,' I propose the following for your consideration: Often, businesspeople and customers are subject matter experts and familiar with popular solutions to current problems. However, businesspeople and customers are not typically trained as designers or architects. One role for designers is to transform information into knowledge. One role for architects is to take a systemic viewpoint. Great designers and architects build on the information obtained from businesspeople and customers and envision what is possible within the constraints. The caution when empowering businesspeople, customers, or other novices to create 'pretty pictures' that may become part of a 'requirements' document is premature convergence. Premature convergence is settling on the first solution instead of the best solution. More subtle than premature convergence is a designed-by-committee, bureaucratic solution. Another caution builds from the phrase "Just tell me what you want!" in the original post. Often when products are implemented using a 'just tell me what you want' method is that there is moment during product evaluation that has a businessperson or customer assessment such as "But this is not what I meant." The problem is that most businesspeople or customers can't articulate all of their product requirements. This limitation should drive the development efforts to enlist the appropriate designers and architects. Pretty pictures can be comforting but if the development team implements a naive design, the project is likely to be mediocre and not have a sustainable competitive advantage.
suem 6-Oct-09 9:20am
All my work is in-house, and I'm blessed in that we're small. I agree that users are unable to articulate what they want, but they also don't KNOW what they want. I've gotten to the point where I listen to them talk, ask them as many questions as I can about the process they're trying to automate, and then just take my best shot at it. I roll it out to them with the expectation, clearly communicated to them, that I'm sure they'll want to change things once they've worked with it for awhile and that's ok. It's part of the process.

Sign up to receive InfoWorld Resource Alerts

Subscribe to the Today's Headlines: First Look Newsletter

Find out what will be news for the day, with our first-thing-in-the-morning briefing.

©1994-2009 Infoworld, Inc.