Jef Raskin’s definition of a humane interface – “An interface is humane if it is responsive to human needs and considerate of human frailties” – inspired this blog. What is humane information architecture (IA)?
This article is subtitled “An interim definition” because I am pretty sure I can’t come up with a definition as wonderful as Jef Raskin’s the first time around 
By sheer plagiarism, I will start with “An information architecture is humane if it is responsive to human needs and considerate of human frailties.” Nothing wrong with that one at all. But it could stand a little clarification. Which humans? Which needs? What frailties?
Are we talking about just the end users here? Even if this is widened to include all stakeholders (including project delivery and maintenance staff, accounting staff that monitor both delivery and maintenance, and everyone in between) – is it wide enough? Does the humane information architecture need to be responsive to the needs of the IAs working on the project?
So maybe the revised definition should include a clause that says something like “do the best you can within the allowed budget in a humane way”.
Where does the responsibility to be humane end? Does it end? To be successful, the project needs a definable and pre-defined scope, otherwise it will go on for too long and cost too much money (that said, in the absence of scope, how will we know when it has gone over budget?).
Which needs are most important? Hopefully the project is structured enough to have a categorisation system for requirements – be they
- priority 1, 2 and 3,
- mandatory, desirable and optional, or
- needs, wants and wishes as you will.
The categorisation systems for requirements usually define them in some form, such as:
- mandatory requirements must be met for the project to be deemed successful (i.e. meeting the mandatory requirements is the minimum success guarantee of the project)
- desirable requirements should be met wherever possible, and not discarded without stakeholder consultation.
- optional requirements can be met if in so doing there is no danger of the project running over budget.
In this kind of structure, needs are mandatory, and in an ideal world, have been recognised as such. As an aside, I do not believe it is the job of the IA to validate all the requirements (unless it is one of those BA/IA gigs, which do occur) but they should be able to notify the BA/requirements management team of where there may be clashes and omissions.
What constitutes a need from an IA perspective? To me, this will be a two-part answer:
- whatever the requirements documentation says is a need, and
- whatever the IA believes is a need and can be reasonably negotiated into the requirements set that is vital for the successful operation of the system from an IA perspective.
Examples of the latter are legion. It is not as if the IA is the Knight in Shining Armour come to rescue the poor end users from the evil Project Manager – far from it – but there are times when things get missed in the best of requirements sets. So we could take “do the best you can within the allowed budget in a humane way” and add to it “to meet the needs of all users and in so doing, make the system both useful and useable”.
And frailties? There are the normal interface design motherhood statements like:
- “there should be no unexpected behaviour”,
- “clickable regions should be readily identifiable”,
- “use visual hierarchy to ensure that the most important stuff is easily found”,
- “the navigation system must be clear and intuitive”, and
- “use navigation labels that make sense to your audience”.
How do you find out if these are enough? By testing – informal if needs be, but test early and often, with a minimum representative sample of ALL user types.
So now we have this: “do the best you can within the allowed budget in a humane way to meet the needs of all users and in so doing, make the system both useful and useable, and test to ensure that it recognises and compensates for apparent human frailties”. This is a bit of a mouthful – I am sure I can come up with something better in time!
Until next time, Andrew
