Task Analysis: Why the Light Doesn't Turn Off
Just before the pandemic started, my church needed a new organ. We raised money, adjusted the budget, discussed the options, and decided that the best use of our money was an electric "virtual organ":
An enormous amount of highly technical work clearly went into making this object. I'm certain there were studies done for the placement of each keyboard, footboard, connection, and the screens for digital control, considering both ergonomics and traditions (since acceptance will depend on making the organ easy to play for someone who learned on a traditional organ).
They even, helpfully, installed a stand light which beautifully illuminates the music and which turns on automatically when the organ is powered up, in case (as so many are), your organ is in a dim choir loft. No power cord for the choir to trip over and knock over your light source!
What they did not consider, however, is that, sometimes, you might want to turn *off* the light while the organ is on. Since even though everyone in the choir is vaccinated, it is still a global pandemic, we are both masked and distanced in the choir loft while we sing. This means that sometimes we have a very limited number of places where singers can stand, and some of those do not have the best view of the organist/conductor. The light makes it even more difficult to see the conductor/organist, since it doesn't spotlight them, it is focused on their music. We are lucky enough to enjoy relatively good light in the choir loft (to the benefit of the choir's eyesight), so the light could be turned off without significant difficulty to the organist -- but there is no affordance to turn it off!
This is a failure of task analysis. One of the limitations of a top-down engineer-driven task analysis is the imagination of the engineer - they need to model their end user and the things they might want to do with the system. When that model doesn't include some tasks the user might need or want to perform, the system fails.
So how do we avoid this? Do we just need to be the smartest, most well-rounded engineering teams, so that we think of everything in advance? No. (That's impossible anyway)
User studies and pilot tests! We need diverse groups of users, who have different needs and preferences and use profiles, to try out the products in the setting where they'll actually use them, for long enough to actually encounter the edge cases where there will be situations the brillant engineers didn't consider.
This means building human factors testing / prototype field testing into your product schedule, which is not usually very popular, but it makes a big difference in eventual user satisfaction. I think that if companies looked at the cost/benefit tradeoffs, they would find that user satisfaction is worth a lot of weeks of product field-testing!