Melissa Burpo in her blog "Don't lose your users in abstraction" talks about actually making people to fit your abstract users. But you have to think like your users to actually make full use of this.
Two examples popped up this last week which shows you why you need to think like the concrete users you make for the abstractions.
First happened just yesterday when discussing test cases on users. The test writer was writing a test case that email addresses should be unique throughout the system. This may be true for 'the Administrator', 'The Agent' and 'The Customer - Dr. Ortho', but may not be true for 'The customer - Patricia Patient'. We all know people who are not sophisticated net users who have one Email address for the whole family (probably your parents). Patricia Patient's husband Paul might also be a customer of the company and they share an email address. Once we stepped back and discussed this fact - it became apparent that we had to think like end customers to avoid putting in a constraint that all contact email addresses must be unique.
Another example came up in a discussion of a third company (which I don't have the solid reference for) who put a constraint in their database that two people from the same family can't be born in the same month of the same year. I think the problems with this is obvious. But what happen was some programmer was trying to put a fraud detection into their system - and coded what worked without thinking what the real world was. When the first family with twins joined the system - oh no. The agent had to enter the twins as being born in different months.
So beyond trying to make your abstract users concrete - you also have to interact with the system as those users would. And every design decision needs to take into account everyone one of these users. If you don't think like them, you're likely to make code that locks them out of the system.
