What are performance requirements (PR)?
Information design project stages. Performance Requirements guide each stages
PR for a public document are all the tasks people should be able to perform with that document.
At the Scoping stage of a project (see project diagram opposite) we ask all stakeholders a crucial question:
“What do you want people to do with this document?”
We transform their answers into performance requirements: a list of all the tasks that document users might be expected to perform with the document.
Once finalised, the list guides the project through every stage from Scoping to Monitoring.
About our PR Library
The 200-plus projects we have undertaken since 1985 have begun with a set of performance requirements developed in collaboration with stakeholders. We are now compiling a library of these for our Members and Fellows to use as the starting points for their own projects.
Every document design project is in some ways unique. We search for those unique aspects at the Scoping stage by thoroughly investigating the context in which the documents are developed and used, in consultation with stakeholders.
But it is always useful to have precedents: to see what others have done before in similar circumstances. That’s the purpose of this library. In it you will find fully developed examples of performance requirements for many types of public documents:
- business letters
- consumer medicine information
- financial reports
- intranet sites
- medicine packaging
- statements of advice
- web sites
and many more…
We will progressively add these to the library over the course of this year. We hope you will find them useful as a starting point for your own work.
We begin with one that is bound to be controversial: a Statement of Advice. This is the document that financial advisers are legally required to give their clients, and as you will see much of the content is prescribed by legislation.
Think of a full set of tasks as matching the journey people have to undertake in order to use a public document appropriately. We have annotated each example with some notes to help you with particular issues that could affect your development of your own specific version.
In this introduction we give you a general set of notes to help you structure and navigate through this important part of a public document project.
Sorry to interrupt your reading of this interesting paper. The publishing of this paper is funded by our Members and Fellows. If you are a Member, please log in to read the rest. If not, and you value what we do, please become a Member.