Genii Weblog

How to get your product used "in anger"

Mon 24 May 2004, 09:22 AM



by Ben Langhinrichs
In Carl Myhill's article, Get Your Product Used in Anger!, he demonstrates that many design flaws or weaknesses are not exposed until a product is used "in anger", which he defines in the sense of use in the real world under real conditions, not in a demo or lab.  As a quick example, see the footpath below, and the "Desire Line" which people really want:
Inline JPEG image

Mr. Myhill further argues that a product designer should try to get their product "used in anger" before finalizing the design.

But how to do it?  Beta tests are often ineffective.  Radically changing the design after your first release is usually a bad idea.  Your best bet is usually finding a client who needs the product and working with them to develop a product, as they have tremendous incentive to use it "in anger" before your first public release, but then you my design too closely to their requirements and have trouble designing for broad appeal.

At Genii Software, we've tried all of these approaches in one way or another.  COEX! Links was first developed for a large customer (our version 1.0 , which was developed along with two other partners, as opposed to our current version, which is all ours).  The Midas Rich Text LSX was designed and adapted under the "Sell slowly, adapt quickly" model, where you may force the first few users to undergo a certain amount of design shock as you alter things, but since you sell slowly at first, not too many are inconvenienced.  @Midas Formulas is likely to follow this second approach, although we have had a beta test and some early adopters.  With ReportLogic, we did almost everything wrong, as we seemed to continually develop a great product underneath with all the wrong "Desire Lines".

How would you, or how do you, get your products "used in anger" before they are "set in stone"?

Copyright © 2004 Genii Software Ltd.

What has been said:


161.1. Carl (not Myhill) (05/24/2004 05:32 PM)

Great question. We've tried different approachs too. Not so sure one way is better than the other. The working with design partners works great when they understand what they want, but sometimes when you're inventing a new way of working they just don't get it.

Great question! I'll have to think about it some more.


161.2. Colin Pretorius (05/25/2004 11:43 AM)

It helps to have a Notes-based product where you can update and replicate the design daily, so you can postpone the "setting in stone" (almost) indefinitely :)

I'd say it's a combination of two things: trying to delay the setting in stone bit, and anticipating those desire lines. Anticipating is not easy, but that's what sets good software apart from great software, the kind of magic that we all aspire to :) I think a bit of inspiration and a lot of research and application domain knowledge are essential.

As an aside, I think that designing with flexibility in mind is crucial to tracking those desire lines. It's not the same as anticipating, but it makes subsequent updates far more likely to keep users happy.