Phases of Usability

As a software developer and product manager, I've spent plenty of time writing software applications, and spent plenty of time with customers using new software products. Recently, I attempted to get some feedback on the customer's experience with a software package and did not get a single response. At first,  I thought maybe the product was perfect and that there were no improvements to be made. But then I took a moment and thought back at all of the customer interactions I've had and realized some of the customers had feedback, some didn't, and those that did have feedback, had different types of feedback based on their level of experience with the software. Since then, I've conceived three different phases of usability based on their level of exposure and experience with the software. These phases are: Learning, Feature Opportunity, Settling.

Learning

The learning phase of usability for me seems to come during the first few days of training one user or the repeat trainings of multiple users of a system. Right away you start to notice how a given user persona interacts with an application. Almost instantaneously they uncover new usability opportunities because they  navigate to and from certain activities within the software application in ways that the engineers or designers did not intend. I see this as a great time to seek out opportunities to improve usability because if the user finds your product instantly easy to use than they will be more willing to adopt it as part of their workflow or process.

Feature Opportunity


I consider the second phase of usability not really a phase directly tied to usability, but one that can yield great product feedback for future improvements in either user interface development or functionality.  I've seen that after a user becomes familiar with the product they are learning, if you are lucky enough to be in their presence, they begin to relay great feedback.

"It would really be great if once I've completed this task the software, ...."

"Why is it that once I do this the software....." "It should really....."

Comments like these set flags of opportunity. The user is giving you feedback on how you can improve your product and add value to the customer.  However, keep in mind that one users feedback isn't enough. This user feedback should be collected into a repository and checked against additional user feedback to uncover trends and potential new feature opportunities.   Nonetheless, I see that short window of time after a user becomes comfortable with a software application as an opportunity to get great feedback. It's also a good idea to have a good feedback mechanism in place if you don't happen to be there when the users reveal their feedback.

Settling


Once the user has moved past the initial training experience, and flushed out all of their great ideas either internally as thoughts, to you, or using your feedback mechanism, the user gets to the day to day use of your application. At this point, the user just seeks their own means of efficiency with your software. That  quest for efficiency could typically mean that a user simply gets used to the way your software behaves, or simply does not have the faith to believe that you are responsive in delivering new innovative ways for users to be more productive using your application. At worst case, their feature opportunities overwhelm them too much and they simply seek out another piece of software that will solve their problems based on their new found experiences. At best case, they will find workarounds because they simply need to get a task done and your software while not the best possible solution, provides them with an adequate means of getting things done.

In short, after training or releasing a new version of the software, make sure you get involved with your users experience early because that could be the best and most opportune time to get the feedback you need to take your software to the next level.