An interaction can look convincing while removing a way of working that some users need. I learned that lesson through a planning prototype I approved at Dharvilen in 2002. The demonstration made moving work through a schedule look direct and intuitive. It depended on dragging items with a pointer, and the earlier keyboard route had disappeared. In a trial with twenty-six planners, eleven could not complete three defined tasks without using a pointer. The problem was in the product decision I had accepted, not in their failure to appreciate the demonstration.
I do not infer a disability, working environment or personal preference for those eleven people. The observation was narrower and sufficient for the decision: the required tasks could not be completed through the route being tested. Suresh Dharveth challenged the omission, and we restored keyboard operation alongside pointer interaction. The fifty-two-lakh expense in the fictional account was a correction programme. It was not a quantified accessibility benefit, evidence of universal conformance or a claim that every possible user need had been addressed.
Find the task behind the preferred interaction
The first question I would now ask is what the person is trying to accomplish before selecting the interaction that makes the demonstration attractive. A planner may need to identify an item, inspect its current position, move it, understand the result and recover if the move was wrong. A short demonstration can pass quickly through those steps because the presenter knows the example. A user doing unfamiliar work needs a product that communicates each consequential state. The task is larger than the gesture that happens to move the item on screen.
Keyboard operation makes those hidden dependencies easier to notice. The user needs to know which element is active, what action is available and what changed after an instruction. Those questions also matter to many pointer users, but a visual demonstration can sometimes conceal them through the presenter’s narration. I would want the team to observe the task without supplying that missing narration. Otherwise the test can measure the presenter’s ability to guide someone through the product rather than the product’s ability to make the work understandable.
The original mistake was not that dragging should never be offered. It was that I allowed one interaction to displace another without establishing that the necessary tasks remained available. Restoring the keyboard route did not require abandoning pointer use. It required treating more than one route as part of the product definition and checking their behaviour deliberately. That distinction mattered to the team because it turned the correction from an argument about fashionable interface choices into a concrete account of what users had to be able to do.
Correct the choice without inventing a wider claim
The trial gave us a defined problem to correct. It did not provide a licence to describe the entire planning product as accessible, compliant or suitable for every environment. I would keep the task set, participant group and observed limitation attached to any account of the work. A wider assessment would need its own scope and appropriate expertise. Modern guidance on keyboard operation can help explain the general principle, but it should not be retroactively presented as a certification held by a fictional product built in 2002.
The correction also deserved a commercial account. Reworking an interaction consumes capacity that could have gone elsewhere, and the product owner should explain that cost instead of hiding it as an engineering detail. I accepted the expense because the missing route prevented completion of the defined tasks. I would not strengthen that argument by inventing lost revenue or a quantified legal exposure that the case did not establish. A product decision can be justified by a demonstrated inability to perform necessary work without attaching an unsupported financial claim to every observation.
Ownership mattered as much as the budget. I had approved the prototype, so the account should not imply that an implementation team independently removed a requirement after receiving perfect direction. The product review had rewarded a persuasive path and failed to examine an alternative. Naming that error makes the lesson more useful. It shows what I would change in the decision process and allows others to assess whether the correction addressed the actual omission. A biography that presents every difficult episode as someone else’s mistake would miss the source of my learning here.
Make alternative routes part of the product account
For a subsequent product, I would ask the team to describe supported ways of completing important tasks before presenting a preferred visual sequence as the whole experience. That description should include how someone enters the task, identifies their current position, acts, receives confirmation and recovers from an unwanted result. The exact requirements depend on the product and its users. I would involve people with the relevant design and accessibility expertise rather than assume a CPO’s general interest is a substitute for a proper assessment.
Testing should then preserve the distinction between observing a task and coaching a participant. Assistance can be appropriate, but it needs to be recorded because it changes what the observation means. If a person completes the sequence only after the facilitator supplies a missing instruction, the team should know that. Similarly, a successful route for one participant does not erase a repeated obstacle for another group. I would ask what the test demonstrates, which conditions remain outside it and how unresolved issues affect the next product decision.
There is a temptation to make the corrected version the end of the story. The more useful account includes what still needs checking. Keyboard support for three tasks does not establish the quality of every screen, error message or later workflow. Future releases also need assessment of whether that route remains available. The product team needs an ongoing way to recognise when a change affects supported tasks. That responsibility should be proportionate to the product, but it cannot rest solely on the memory of the person who challenged the original prototype.
I would also make the supported experience clear to people selling and implementing the product. A demonstration that returns to showing only the attractive pointer sequence can recreate the original misunderstanding even after the software has improved. Buyers need an accurate account of the tasks and routes available, with limitations made visible where relevant. That does not mean every sales conversation becomes a technical inspection. It means the promise should remain consistent with what the product has actually been designed and assessed to do.
The fictional episode changed the question I bring to an impressive demonstration. I still value a clear and satisfying interaction, but I want to know which complete task it represents and whose way of performing that task has been left outside the picture. In a real profile, that lesson would require authorised evidence of the trial and correction, with participant information protected. The contribution I want the story to show is my willingness to revise an approved design when the actual work exposes a missing route, while keeping the claims about that correction no broader than the evidence supports.