Some tips for building “adoptable” software

In part one of this article, we began our discussion regarding building adoptable software. I claimed that there are biological mechanisms at play that can’t be ignored if you want to successfully launch your application. To get caught up, check it out here.

Below are just some approaches you can include in your software development practices that will help your users with adoption:

• Build the software with them - include them in the design phase

  • Interview them to understand the way they currently do their work and the breakdowns they regularly encounter to stop their productivity and frustrate them.

  • Be transparent about the new product - don’t surprise them - no one likes that.

  • Give them a narrative that works for them about why adoption is necessary, helpful, useful, etc. - using language they know, not jargon.

  • Provide prototypes for them to react to - keep building their narrative about how these prototypes help them.
    
    

• Include key users as part of your User Acceptance Testing (UAT) program.

  • Show the software to them often as part of UAT - and when they find issues, fix them!

  • Train the trainer - build a group of users that can take this new product / feature to the remaining user base. Colleagues are often the best choice for training others - they have an inherited level of trust because they know how their business/department operates - and how this application will effect them.
    
    

• Design the interface to be simple, effective, aesthetically pleasing and useful - to them.

  • Keep user patterns similar to what they are used to already - keep track of the standard interfaces that everyone is using - Amazon, Apple, etc.
    
    

• Don’t trigger their flight response by overwhelming them with change

  • Release changes gradually - LEAN / Kaisan - small changes don’t typically trigger flight (that is how predators often catch their prey - the prey doesn’t notice the animal stalking them)
    
    

• Support them with training and on-going support

  • Design the training for them - using language they know

  • Don’t leave them on their own - they need to know they have help available to them when they need it - use your UAT team to support/augment the formal training you provide.

  • They also need to know they can provide feedback into the process to influence the future of the software - when you invite ideas, address them promptly. You don’t need to use every idea you receive, but they should know you heard them. No one likes to be ignored.
    
    

Remember, software is supposed to make our lives/jobs easier, not more difficult. If you product isn’t being adopted, it probably isn’t making things easier for your users. If this is the case, now is not the time to trumpet how “right” you are or how “cutting edge” your application is. The only thing that will resolve your issue is to talk to your users - engage them. You may just learn something.

Follow us on Linked In (8PennyLabs) to be the first to learn when a new blog post drops.