The iRise Blog

I meet with CIOs, application development groups, business analysts and architects all the time.  Our initial conversation always goes the same way; I explain what visualization is and why it’s important.  Within 60 seconds everyone, and I do mean everyone, GETS it.  You can SEE the light bulb go on.  Then….I wait for the inevitable question; “If the visualization is an exact replica of the application, why doesn’t iRise simply generate the code?”   Without fail, that question is asked in every single meeting.

Actually, it’s a really good question (it must be with so many people asking it).  But there are really good answers as to why iRise doesn’t generate code.  Let me try to articulate them here.

1. What code do you generate?  That’s a tricky one, since everyone’s architecture and standards are so different.  Do you generate Java/XML?  .NET?  SOA?  Which flavors?   If you had to worry about getting the code generation right, you’d quickly run out of resources to figure out all the combinations, test them and support the result.  This sounds a lot like the old CASE tools strategy in the 1980’s and 1990’s.  See how well THAT worked out.
2. iRise is specifically designed to be easy to use for business analysts, not developers.  The problem that iRise solves is getting business needs documented visually.   This is a business-facing challenge, not a developer productivity challenge.  If you started to worry about code generation in iRise, the product would become too hard to use and understand for business-facing analysts and usability professionals. 
3. Our primary emphasis is on rapid, high fidelity visualization.  To put any amount of emphasis on code generation will slow down the ability to visualize the right business needs quickly and rapidly iterate to the right result.  You don’t want to be distracted with figuring out ‘what code should I generate’ during this part of the process.  The people creating visualizations are the wrong people to be worried about code generation - that’s the job of architects, software designers and developers. 
4. And of course, the flip answer is this: “There’s no button on the side of the flight simulator for the Boeing 787 that generates the airplane!”   There MUST be a reason that other industries invest hundreds of millions in simulation technology without having the capability to simply press a button and build the thing.   You visualize things before you build them to produce better, safer products more quickly, with lower cost and risk.  The same is true with software and iRise visualizations.

It’s important to note that even though iRise doesn’t generate code, most of our customers report a 25% - 50% reduction in application development time due to the fact that proper visualizations virtually eliminate rework and allow downstream organizations like QA, training, documentation and marketing to get a head start on their work.

Share This

Investing in better design has always been a tough sell to non-believers, in part because there aren’t enough clear and easy ways to show different levels of design attention.  Here is one method I have used recently:

This chart shows the adoptability of a product based on where it sits on a continuum from Functional to Usable to Desirable.  Rough descriptions of each are:

• Functional = A user can finish what someone could describe as a functional task but doesn’t necessarily meet their needs or goals as a user.
• Usable = A user can meet needs and goals without frustration.
• Desirable = The satisfaction of needs and goals is done in such a way that a user builds a positive emotional association with the product (i.e. positive product equity).

Adoptability in the software world is a measure of whether or not people who have bought the product are actively using it.  In other words, is it used or is it shelfware?  Being used doesn’t just mean higher support costs… it means that a customer is actually getting value and associating that benefit with the product and the brand.

What this shows on the lower right side is that yes, there are software products that can be adopted that are almost purely functional if they provide a huge amount of relative value.  However, even if they are adopted in a temporary fashion, the negative product equity associated with them means that they are easily and enthusiastically displaced by competitors.  The dot shows a product that moves from no adoption, to adoption with negative product equity, to adoption with positive product equity.

Desirability Testing

One interesting implication of this is that software companies should do all three types of testing in order to drive the proper behavior in valuing each:  Functional Testing, Usability Testing, and Desirability Testing.  Desirability Testing doesn’t really yet exist in any formal sense, so this is a good area for further research and experimentation.

Product Equity

Product equity is like brand equity but focused just on the product and not the overall brand experience.  The impact of positive product equity is that customers will continue to use the product in the face of competitive alternatives and will buy additional products from the same vendor.

Are there other methods you have used or seen to meet the same goal of communicating different levels of design attention?

[This entry was originally posted to the blog The Product Architect on December 8, 2007.]

Share This