The value of good requirements

Over on the iRise blog, there’s a great article about measuring the hidden return on investment (ROI) of good requirements definition. David Walker speaks of how companies are focusing on “reduction in rework” and points out that the after-effect of reducing rework is accelerated time to market, which has several significant (monetary) benefits. David also points out:

Rework isn’t the only place to look for time-to-market advantages.  Focusing on requirements definition not only reduces re-work – it also reduces WORK work.  At an agile development conference in 2006, Mary Poppendiek (author of Lean Software Development: An Agile Toolkit for Software Development Managers) shared that  45% of code that’s written is NEVER EXECUTED!  Another 20% is only rarely executed.  It is however coded, documented, tested, trained, supported, maintained, etc.  All of which adsorbs resources – and adds time & cost – to projects.  Getting the requirements right interactively and up-front with end users helps make sure that unnecessary functionality never gets built.  What if your development teams could get 45% additional bandwidth simply by not working on stuff that will never be used?  Less stuff to build & test means, you guessed it, shortened time to market.

Even though I currently work in the government sector where time to market isn’t relevant (or at least not paid much attention), I can sure relate to the frustration of rework. We seem to be reinventing the wheel almost every day, as one group goes out to accomplish some great goal that another group has been working on for months.

How do you develop good requirements?

Rapid prototyping and user testing is key. Understanding your customers and their goals and motivations  is critical. Sound business analysis focusing on the right metrics, direct user interaction, and a focus on usability from the start will give successful results. Using rapid prototyping/requirements developments tools should help as well.

Of course, good vision, communication and organizational structure are going to be critical. Make sure you have all your people marching towards the same goal and everyone knows what the other groups are doing, so you don’t have a whole lot of re-solving the same old problem going on. That’s the kind of rework we don’t much talk about or measure, but whenever you have a fairly large organization, it happens.

More Tools for Building the User Experience

Prompted by a comment from Amit on my Faster Prototypes, Better Specs entry where I discussed Lucid Spec, I went and looked for some other UI-prototyping tools. I looked at GUI Design Studio, as Amit suggested, and also iRise. At first glance, they all look very similar. Initial thoughts:

• I like the “whiteboard” in iRise Studio where you can model page interactions. They also have Masters and Templates that allow you to standardize your page designs and quick-start any new page design.
• GUI Design Studio lets you put in anything you can draw as a control–you’re not limited to standard controls.

I’m wondering if anyone has done a comparison study of these types of UI prototyping/requirements tools? Are there others I’m missing?

… On my quick journey investigating these prototyping tools, I stopped off at the iRise blog, where I found a really interesting article on the adoptability of a product depending on where it is in the continuum from functional to usable to desirable, where:

• 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).

Dave showed this chart in the article:

and explains the chart like so: 

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.

What a great chart! and a great way to explain the human factors of design. Dave also talks about “Desirability testing” and says this isn’t currently done. Shouldn’t that be part of any good usability test? I typically try to guage the user’s emotional response to the interface in all my usability tests, in addition to asking several questions about satisfaction and “would you use this again?”, “would you recommend it to your friends?” kinds of questions. That’s desirability, is it not?

But I really like the name. Perhaps we shouldn’t call it a usability test–perhaps we should call it a desirability test? Would that make more sense to the world? Every time I mention “usability” to someone outside the field, they get this deer-in-the-headlights look like they can’t begin to imagine what I’m talking about.

But then “desirability testing” might be even worse–I can just imagine the snide comments I’d get from guys outside the UI design field … (or even worse, those within!)