Working in software product management, you often here the word “Usability” thrown around, though rarely do we examine the term and principals behind it.
Lets examine usability a little further. Usability means that the software can be used by the targeted users and help them complete their tasks effectively, efficiently, and with satisfaction.
According to Jakob Nielsen, one of those at the forefront of usability, it is defined by five main components:
- Learnability: How easy is it for the user to complete a task with little or no training?
- Efficiency: Once I learn how to complete a task, how long does that take?
- Memorability: How easy is it for me to remember how to use the software?
- Error Tolerant: How often do errors occur, what is their severity, and are they easily resolved (i.e. refresh the screen)?
- Satisfaction: Does the site provide the user a pleasant experience? This component is obviously dependent on the others.
The focus on achieving great usability is often on the broad view of the software, but a more granular look at how requirements and code are written can be useful.
Recently I have been working with a large multinational on a legacy system transformation that had been mothballed several times.
The issue we noticed while working with developers is that no one could understand what the code was saying due to its poorly written logic and lack of comments. The code clearly lacked learnability and efficiency. If it had been written more elegantly then despite having to make changes, we would’ve saved substantially on the two-week development effort it took to resolve.
Usability can be brought into any component of the development process from the writing of requirements to the coding of software. When we as product mangers, business analysts, and developers look at a project we should always remember that the principals of usability can be extrapolated further.
Stay tuned for Part II: Usability it’s not just for looks.