"got used to" - research or studies

11 Feb 2012 - 10:21am
2 years ago
5 replies
678 reads
csulok
2012

Hi

At my work we're gearing up to rebuilding one of our major applications to support new platforms, mobile, etc... The current solution has more than a decade of work in it, and with it, more than a decade of solutions that are suboptimal, out of time, or simply bad.

I have a really big fear that we won't be successful at fixing these and delivering needed changes, because sales/management stops us because "the user got used to that solution, dont do this".

I have a really strong feeling in this matter, but I cannot prove it. I'm looking for any case studies, or user research that tested how users react to change. So far I've been unable to find any.

I believe once users get used to a better solution (however you define "better", be that more intuitive, easier to learn, faster to use, friendlier or more aesthetically pleasing), they will prefer it over the old.

The questions that I hope to get answers to:

  • after how much time, what percentage of the users get used to a new solution
  • what percentage of users can be categorized as "wont get used to a new solution" and what type of personas are they?
  • during the transition, what describes the user's feeling toward the subject
I would really appreciate any pointers or links.

Comments

12 Feb 2012 - 7:22pm
Alan Hogan
2007

What a great question. I’ll be following this thread with interest.

12 Feb 2012 - 7:42pm
bjminihan
2010

I've looked for this information in the past, for the very same reason.  I suspect you won't find much, either, because of the very fluid definition of "change", and the context in which it takes place.

User's fear of (and frustration with) change is very real, but more often than not, the SPONSOR's fear of upsetting customers far surpasses the user's fears.

I've worked with dozens of executives, stakeholders and sponsors who sit behind or above very large applications, who have said exactly what you're hearing.

9 times out of 10, if you dive into their fears, you'll find that it's not actual change they are afraid of, but the lack of *control* over change.  That's because system change and communication is managed very badly in many (MANY) organizations, and is almost an afterthought in all but the most controlled software environments.  People just don't have time or funds to staff software groups with change control experts, so people pitch in when they can, with as much as they can offer.

That often results in poorly or highly technical release manifests that excruciatingly detail every tweak and bug-fix, without giving anyone a sense of "what really happened to my product!" 

Furthermore, 9/10ths of the development process takes place behind the scenes, and is usually packed to the gills with tons of work getting everything right for the next release.  Even in a very customer-driven agile process, only a few customers are even aware that new changes are coming, and that's just because they're heavily involved in the day to day process.  Everyone else is blissfully unaware of the "changes" coming down the pike.

However your SDLC works (with or without direct customer feedback), you won't change your stakeholders' minds with statistical evidence about change, because those figures can't possibly be relevant to your particular system and lifecycle.

Instead, I would probably provide an analysis of how your organization manages change, to your stakeholders.  Identify weaknesses and how you can address them, to make change more acceptable and comfortable both for your users and your stakeholders.

I've been told so many times that anything shorter than a six month release cycle would absolutely terrify "the users" (this, coming from executives in charge of customer service).  However, you can improve the change control process so that it a) uses both proactive and passive communication to keep everyone informed, 24/7, b) provides a clear, predictable, transparent release process that everyone understands (e.g. last day of every month), and c) enforces a zero-tolerance policy on bugs making it into production.  If you can do these things, there is no reason whatsoever that you can't release new features not just every month, but every morning.

You would be amazed at how psychologically uplifting it is to be able to move real business value out to your users every single day.  The weight of all those months of work, building up to one or two monumental releases every year is incredibly demotivating to everyone involved.  I've seen it too many times over the past 15 years, and I'll never go back to the bi-annual or annual release cycle again.

I know the above isn't what you're looking for, but I think you're not likely to sway your stakeholders' opinions with external data.  If you do find any, I would love to see it, because I could always use more information in my own discussions =]

Agree with Alan, it's a really good and important question =]

Bryan

13 Feb 2012 - 3:35am
csulok
2012

 

Bryan,

Thank you so much. Your answer is more than I would ever have hoped for.

You are right, this is not the answer I thought I would get, but to be completely honest, besides a strong gut feeling about how users would react and how sales/management would react, I didn't have much else to base my hypothesis on.

However your SDLC works (with or without direct customer feedback), you won't change your stakeholders' minds with statistical evidence about change, because those figures can't possibly be relevant to your particular system and lifecycle.

I always thought reacting to change is based almost entirely on brain stuff, psychological effects and whatnot, so if the personas are identified in the case studies, their findings can be relevant to us if we have similar personas.

Anyway... I accept your words of wisdom (no, really), because it makes sense that communicating the changes better makes a bigger difference than statistical proofs.

Thank you once again!

 

13 Feb 2012 - 1:19pm
Mekayla
2010

I'm afraid I can't give you links to specific papers, this is a topic that came up quite a lot at the EPIC (ethnographic praxis in industry) conference last year. 

Here's one example of a talk on this topic:

http://epiconference.com/2011/program/papers/the-calculus-of-change-an-ethnography-of-unlearning

However, you should also check out the conference proceedings (http://epiconference.com/2011/), because I know that there were severl others

14 Feb 2012 - 7:27am
Alan James Salmoni
2008

I have no evidence to support this claim but maybe it's worth pointing out a few about-faces that successful companies have made:

  • The recent Facebook re-design got a lot of flack but their user base keeps on growing.
  • Apple - the move from OS 9 to OS X was in some ways the catalyst for Apple's re-birth.
  • Microsoft - the turnaround to make Windows networking friendly after Bill Gates had tried the Internet out (1994/95).
  • Microsoft - DOS to Windows 1,2,3 to Win32.

There must be other examples of interface 'pivots'...

 

Syndicate content Get the feed