[PLUG-TALK] Fighting the fear of computers

John Sechrest sechrest at jas.peak.org
Tue Feb 8 22:36:31 UTC 2005



Keith,

	While it is true that there are computer laggards out there,
	often the problem you describe is not a computer fear. It
	is something else.

	One book that really helped me understand this was
	called "Diffusion of Innovations". I am seeing it 
	re-presented in the book I am reading now called
	Purple Cow.... By the way, I really recommend you reading it.

	In any case, the short answer is:

	There are many different types of approaches to change
	and innovation. You have:

	    innovators - 3-5%
	    Early Adopters - 7-15%
	    Early Normal - 20-25%
	    Late Normal - 20-25%
	    laggards 10-20%


	We are caught up in the fun and joy of the innovation.
	We are oftenthe innovators and early adoptors. We will
	at time do things that may even cost more to do, but we
	do it anyway because it is innovative.

	Most of the doctors are likely late Normal. They are 
	not Laggards (people with lots of fear about the proces)
	but Just normal folks.

	To talk to them, they do not care if it is cool.

	Nor do they care if it runs on computers.

	And they probably have had enough hype talks to be sceptical
	of anything with computers.

	Wiki's are particularly hard, not because of what
	you have to do in the web browser (simple) but
	what you have to do in the mental model (hard).

	And so... What these folks need to hear is 
	what the specific value to them is. Not what it could be
	if they did it right. But what the take home value
	is right now....

	To do this, a bear wiki will not work. There is no
	value in it. It is just a potential. You have to 
	specifically get the early adoptors to engage in
	content creation before you can make any value to the 
	Late normal group.

	More over, because the early and late normal groups
	do not care about the technology, they tend not to follow
	the rules. Which breaks wikis.... 

	And so... If you look at things like Drupal, you can
	get many of the benefits of wikis, and you can get 
	more structure, so the fears can be managed. And you
	can create value much more directly.


	Ask the question. For every hour that the doctor spends on	
	wiki/drupal , how will you save them 2-3 hours of other work?
	For every dollar spent by staff on the processes, how does
	that bring back $10 in value?

	Can you express what the Return on Investment proposition is
	for them directly to me?

	If you can, you will be much closer to making progress on
	your project. 

	If you can't, all the one on one fear reduction
	exercises will not lead you where you want to go.


	 


			

Keith Lofstrom <keithl at kl-ic.com> writes:

 % 
 % There is a meta-problem we need to think about in order to have
 % more success rolling out open source to the people around us. 
 % I'd call it "computer disappointment burnout".  
 % 
 % I set up a wiki for a local medical society my wife belongs to.  
 % Wikis are ridiculously easy to use - probably much easier to
 % figure out than a new-patient form at a doctor's office.  Last
 % night, I had 15 minutes to show a room full of 20 doctors how to
 % add text to a wiki.  Okay, so the venue was awful, we all were 
 % tired, etc., but I failed in my mission.  Because every one of
 % these doctors was CONVINCED that ANYTHING to do with computers
 % was TOO HARD.  Even typing text into the text box of a wiki,
 % hitting "PREVIEW" and then hitting "SAVE".  
 % 
 % With more time, I would have taken a "volunteer from the audience"
 % and ran them through the creation of a simple page.  On the way
 % home afterwards,  I did a lot of shoulda-woulda-coulda ;  I had
 % prepared for the wrong audience.
 % 
 % But the fact remains that highly intelligent doctors are frightened
 % of doing even the simplest new things with computers.  Some of it is
 % fear of failure - doctors do NOT like to make mistakes (they have
 % hundreds of opportunities daily) - but a lot of it is a long history
 % of disappointing software.  These people are thoroughly convinced that
 % they will fail if they try something new.  Hence they don't buy new
 % software or equipment - much less try out Linux.  As a result, there
 % is a lot of familiar but broken crap out there, the market is much
 % smaller than it could be, there are fewer technology jobs, etc.  
 % 
 % There are many ways to design software so that it is less prone to
 % user error, and more recoverable after mistakes.   I'm not talking
 % "user friendly", which is usually just a buzzword for glitz and
 % chattiness - lipstick on a pig.  Well designed software is transparent,
 % intuitive, and task-oriented .  It should always have something like
 % a "test" key and an "undo" key.  Error messages should be guides to
 % action, not petulant (or worse, cryptic) complaints.  Etc.  It may
 % take years of well designed software before people start trusting
 % us again.
 % 
 % Meanwhile, I will just have to work with the folks at that meeting,
 % one by one, until they see for themselves that wikis are a simple
 % to use, non-threatening, and powerful way for them to make their
 % own web pages.  That will be one small step towards empowering users,
 % and fighting the fear of failure.  This mess wasn't made in a day,
 % and it won't be cleaned up by one presentation, either.
 % 
 % Keith
 % 
 % -- 
 % Keith Lofstrom          keithl at keithl.com         Voice (503)-520-1993
 % KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
 % Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs
 % _______________________________________________
 % PLUG-talk mailing list
 % PLUG-talk at lists.pdxlinux.org
 % http://lists.pdxlinux.org/mailman/listinfo/plug-talk

-----
John Sechrest          .         Helping people use
                        .           computers and the Internet
                          .            more effectively
                             .                      
                                 .       Internet: sechrest at peak.org
                                      .   
                                              . http://www.peak.org/~sechrest



More information about the PLUG-talk mailing list