Capping IT Off

In this "it is all about me and my personal needs" web era where users of online applications are expecting ever higher quality and usability, it is becoming ever more difficult for application designers to meet these requirements. There really is only one sensible and effective way of achieving a high degree of user acceptance: involve the users in the design of the user interface that is aimed at them. You need their feedback as early as possible. You need a cost efficient way to quickly produce a series of prototypes that these users can preview and comment on. Put simply: be agile, flush your traditional waterfall methodology down the drain (seriously, do it). This blog post introduces a highly productive and effective process for producing high fidelity, steaming prototypes: Rapid Design & Visualization (RDV). What is RDV? RDV is an agile methodology for prototyping new business applications. If you practice RUP, it would start in the inception phase and probably extend well into the realization phase. RDV helps your IT projects to succeed by putting the focus on the end result rather than the process. This is achieved by doing very early simulations of that end result. In an iterative process, these simulations are developed and tested in close cooperation with real end users until the prototype is ready for the next stage: application development. This, by all means, is not really new. It borrows from agile software development methodologies, that have already proven their value during the last 10 years. What is new is the integrated approach in which the simulations are validated with the business, the end user and IT. Clear and proven advantages of such an approach are: 1. Overall project efficiency increases as less documentation is required and rework is kept to a minimum, 2. Much higher chances of acceptance by the end users, 3. Cost of training and user support will be lower and 4. Increased productivity of the users. All in all, if implemented correctly, RDV helps you to be highly effective and highly efficient at the same time. The picture below is making exactly that statement. RDV highly depends on prototyping technology for which there already is support from the software industry. For instance, to implement RDV, Capgemini partners with iRise , the vendor of the likewise named, mature and popular prototyping tool. Look at their amusing promotion video:
The Problem with Software Definition from iRise Video on Vimeo. Other promising developments around prototyping technology comes from the Adobe labs. Adobe is developing a photoshop like prototyping environment named Catalyst that enables designers to develop high fidelity prototypes in a format that developers can pick up right away and further develop. Catalyst produces development artefacts (pieces of code rather than pixels) that developers can easily integrate, i.e. requiring minimnal conversion, into the development process and then "wire to the backend". This is very important because this greatly reduces development time and cost. Capgemini has already been building much experience with RDV in the last 4 years (read the official press release of RDV here, and read about the official launch of the RDV center here). Myself, I have only recently been following up on RDV. At first glance, RDV seems to have adopted many good practices from agile methodologies. I definitely believe that RDV will help IT projects to build a good momentum in a short time. For my part, I would really like to know more about it and hope to become engaged in an RDV project. However, looking at RDV from a software engineering angle, I see something slightly concerning: What happens after RDV? How can the momentum achieved by RDV be continued in the development phase that follows the prototyping phase. RDV promises a steaming prototype, which should be used while it is hot. How do we ensure that the prototype doesn't cool down and end up in an expensive drawer where it is never seen again? My feeling is that the answer lies in the seamless transition from design to development, which is also referred to as the designer-developer-workflow and happens to be a much buzzed about subject, e.g.: here, here and here.