Primary tabs

Last year I was running a series of requirements visualisation workshops at a major bank in South Africa. Right after my kick-off presentation, during the first coffee break, I was pulled aside by a technical architect at the bank who didn't look very happy.

"What you're doing here is just going to make our job more difficult!" she grumbled discretely.
"Why do you say that?" I asked her.
"Because this way we're going to have to basically build the solution twice, once in design stage and once in actual build, this is a total waste of time!".
"OK, so until now you've been getting your applications right every time, first time, right?" I asked.
"Erm… no. But that's… that’s different…"

This type of conversation is one I've had many a time, but very rarely more than once with the same person. That's because by the end of these workshops people like that technical architect are often your champions.

But why does this conversation still occur in the first place? The answer can be found by looking at how application requirements are elicited today. It is still mainly an antiquated activity that results in a massive paper document that gets bandied around the organisation to be amended, approved and signed off. That's how we've always done it, so why change now, I often hear.

A recent Geneca survey revealed all the typical problems we encounter today with software projects. And they can all be traced back to one root cause – the definition of applications via text documents. Text is inherently ambiguous and our interpretation of words and sentences depends on a large number of factors. And yet we’re still basically asking product managers, business or users to "divine" the solutions up-front and then treat what comes out of this process as gospel. Once this is done, we’re then asking managers to understand a 500-page requirements document in a few days and sign it off to outsourced developer teams. Is it that surprising then that “80% spend at least half their time on rework”?

How about we stop writing requirements as a first step? From my experience business don’t know exactly what they want until they can actually see it and interact with it, so why not visualise it first instead? Why not engage in a dynamic and iterative activity to rapidly simulate and visualise what you're going to build? The basic idea is to treat initial requirements for what they're really are – assumptions. Once we've made this mental leap then let’s do what we always do with assumptions, let’s test whether they're accurate or inaccurate. "What we know" becomes "what we believe", "let's build it" becomes "let's test it first"! Visualise a starting assumption and make changes on-the-fly using modern tools and collaborative user-centric design methodologies until a solution to the specific problem is found and the assumptions are turned into solid requirements. And the developers get these requirements embodied in an interactive prototype (accompanied as necessary with automatically generated functional spec documentation) that does away with any ambiguities.

One has to ensure though that only carefully selected hypotheses around key user journeys – what we call “red route scenarios” – are put in front of the stakeholders and users. This is not design by committee – indeed if the product in question is largely style-led it is questionable the extent to which talking to users is necessary. This is about testing whether the functional design proposed by the subject matter experts actually meets the business objectives and satisfies the user requirements. The visual design decisions are still made by graphic designers and usually applied as a last step to in the process. And standard, run-of-the-mill functionality is left well alone.

The benefits of early visualisation can be huge, whether you’re designing or configuring desktop, web, mobile or packaged applications. An unnamed major US bank that uses application visualisation last year reported up to 90%+ reduction in change requests and late rework, resulting in much faster time to market. Merill Lynch also reported significant revenue benefits resulting directly from adopting application visualisation using a well-known application visualisation platform. SI's like Deloitte and Accenture are also investing heavily in building in-house application design and visualisation capabilities and even large vendors are also adopting, recommending and even selling application visualisation products and services.

So whether it’s called application "prototyping", "simulation" or "virtual testing", application visualisation is fast becoming THE way of defining business applications.


I have read this article completely & got many informative things 
regarding the business app. I guess developers must read this article to
get updated... 
us mobile phone app development

Submitted by John Read on 05 December 2015

Add new comment

Comment editor

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
Blog moderation guidelines and term of use