case study Pensions printout

	see Section 5.4 User focus This story is about something very basic, a year-end paper printout of pensioner details. This feels pretty tame compared to the latest technology. However, while the events stretch back 30 years the lessons are equally true today – users often have to see novel technology in order to uderstand what it can do, and most important they have to see it in their own context. Here is the story: Some years ago, while working in Local Government, I was asked to modify the year end listing of the authority's pensioners. After talking to the head of the pensions department for well over an hour, we agreed on the form of listing which he required. I was still left a little unhappy as I had never really got to the bottom of exactly how he used the listing. I produced an example listing and went to see him at his office. He was very pleased with the format and would have been happy to leave it as it was, but I pressed him to show me how the listing was used. Partly it was retained as a record in its own right, however there was also a parallel paper record for each pensioner. For each pensioner various figures from the listing were added up to fill in slots in the paper record. "Wouldn't you like me to calculate the exact figures you use?", I suggested. It had never occurred to him that this could be done. Presumably during our previous hour-long discussion over what was really a pretty basic listing, neither of us had succeeded in effectively communicating its purposes and possibilities. (extract from Human Issues in the use of Pattern Recognition Techniques) At first this sounds like a trivial task, just add a couple of columns to a year end listing. This listing was literally one line per pensioner, summarising the year: total amount paid in the year, maybe tax paid. I don't recall the details now, and indeed as a non-expert in pensions I struggle to think what could have been in the form. Lesson 1 - the user is the expert in their own domain Note that I had asked mutiple times how the printout was to be used, but only got a satisfactory answer when I wnt to the pensions office Lesson 2 - talk to the user in context Finally it was only when the user saw the test printout (effectively a prototype) that he could fully discuss potential uses of the technology. Lesson 3 - prototypes elicit requirements This is effectively a simple example of a technology probe, the use of a high-fidelity prototype (the final product was to be paper!) to help envisage new techology.     text Alan Dix © 1992, 2015 image Erik Pitti via Wikipedia (CC BY 2.0) 2009		Lessons the user is the expert in their own domain talk to the user in context prototypes elicit requirements