Please provide me with some insight:

You have been asked by a charity to prototype a system that keeps
track of all donations they have received.  This system has to
maintain the names and addresses of donors, their particular
interests, the amount donated, and when it was donated.  If the
donation is over a certain amount, the donor may attach conditions to
the donation (e.g. it must be spent on a particular project) and the
system must keep track of these donations and how they were spent. 
Discuss how you would prototype this system bearing in mind that the
charity has a mixture of paid workers and volunteers.  Many of the
volunteers are retirees who have had little or no computer experience.

I would sit down with those likely to input information around a
computer. Do a round table on what systems and websites they like and
what sites they find easy to use. Find out what expectations may be
too great for them. I had a 55+ client who wanted to have a site they
could edit, but they lapsed into having me edit the site when we came
to the day-to-day operation of the site. That client's intended
audience also needed a "large type" edition of the site, so I plugged
in a way to click on a link and change the font sizes throughout the
site for that user.

I would look for either a web based database system. Or, if most of
the staff and volunteers are at one location, a desktop based
database. Make it transaction based. Charity workers will log in with
a password, go to a screen with all of the possible fields (names and
addresses of donors, their particular interests, the amount donated,
and when it was donated, conditions) and input donation information.
Behind the scenes, this data would go to two sources: one would be the
donor information (name, address, interest); the other would be
donation information (amount, date, conditions, whether it was a
pledge to donate or the actual donation) and the table of donations
would cross reference the donor information with an ID# unique to each
donor. This way, you could have one consistent record for repeat
donors.
In the organization, there would be a small number of people (1 to 3)
who can administer the database. They can go through when required and
verify the accuracy of the information.

This may be comparing apples to oranges, but an example of a web based
transaction database exists at http://lets.epico.info/ (test site:
admin section is at: http://lets.epico.info/admin/).

Build training and assistance into your development plan. Make sure
there are plenty of screen captures of the system in use and make them
easy to access. There is no way to build a site as complex as you need
it and so easy that *anyone* could use it. From what you've laid out,
inputters have to only use something like six fields. Hotmail email
composition requires three or more, so this donation logging system
shouldn't be impossible for someone to figure out. Make the system as
complex as you have to have it, then work to train those involved and
use a trainer who is in tune those they are training.

Make sure that the admin can wind back anything input by a volunteer.
If they make a mistake, you have to be able to correct it. In the
above example (LETS), transactions can't be deleted, but they can be
voided and redone. That way you have a trail of breadcrumbs to look at
later if a problem created through an error is more complex than a
keying error.