We received a comment from Tom Humbarger at iRise on an earlier post, which led us to take a look at their site.
iRise provides a tool for rapid prototyping of web-based applications, and there’s an overview of the products available. They have iRise Studio which allows people to create interactive prototypes of web-based applications, and iRise Reader that allows people to interact with their prototypes.
This is a good news, bad news, good news (at the end) situation.
The good news – they have an innovative idea – use prototypes to communicate requirements.
The bad news – Our initial excitement about their product quickly turned to skepticism while reading their copy…
Who are the target users?
” iRise Studio is a powerful, easy-to- use application definition solution used by business experts to quickly assemble functionally rich simulations of Web-based applications in a matter of hours.“
We are firm believers in the power of prototypes – especially when they can present a compelling vision for an application. The idea that a business expert can create a good one seems a little far fetched.
They’re going to do what?
“Business people can quickly lay out the page flow of simulations and create high fidelity pages that precisely mimic not only the look and feel of the final application, but the business logic and data interactions as well.“
OK, page flow of a mockup, maybe – but business people will not precisely mimic the look and feel of the final application. Even if they could – it would be a bad idea. We’ve talked about the imperative of not specifying implementation details as part of the requirements process. Specifying implementation details is one of our top ten use case mistakes.
The idea of doing the data modeling and business process simulation is cool. Lombardi Software, another Austin company does this stuff – but for enterprise clients. Some of the best people I’ve worked with are at Lombardi, I respect their opinions, and know that they are big fans of being able to do process modeling – and have it drive applications in the real world. If iRise has a comparable interface for modeling, it could be a great tool for rapid prototyping.
Why would they do that?
“The interactive simulations can become visual contracts between business and IT, serving as stable blueprints for what to build.”
OK – now I’m getting concerned. Why is it a good idea to have non-experts specify the branding, layout, interaction design, and usability of a web-based application? Assuming that an expert business process modeler is at the helm, we can expect that high-level workflow is well designed. But the user experience? Show me a business expert who’s competent at designing interfaces and I’ll show you a switch-hitter currently occupying the chair of a business expert.
But we need a good prototyping tool!
The screenshots showing how the application is used to build prototypes look very cool. This application looks like a good product, but their marketing copy sure is targeted at doing the wrong thing. Check out the bits about modeling of scenarios too.
What about the testimonials? Maybe we’re missing something.
Here are some excerpts from the testimonials (note: we’re starting to get excited about the product again)
- “…allow us to rapidly and iteratively validate the clientâ€™s needs early in the process ensuring we have the right requirements from the start“
- “to visually validate requirements and “test market” applications prior to investing time and money in development“
- “can engage their business stakeholders early in the process to visually identify missing system requirements, eliminate unnecessary functionality and discuss important process and policy issues“
Yes, yes, and yes!
This is exactly how a prototype should be used.
What should iRise do?
- Change the way they propose that their clients use iRise. Business analysts, while ideally suited to identify, prioritize and validate requirements, are in no way suited to the designing of software solutions. User experience experts are. A picture is worth a thousand words, and an interactive prototype is worth a thousand pictures. Why risk misleading or dissatisfying the stakeholders with a bad prototype? Why prevent your development team from being able to apply their skills to design a solution? If you’re outsourcing to a development group with limited capabilities, this mindset might seem rational. The answer is to bring design resources in house, not ask non-designers to design.
- Find small consulting companies with a lot of passion for product success and a big megaphone (hint hint), give them a free copy of the software, in exchange for an honest assessment of how well it works and suggestions on how to incorporate it into effective software development processes.