User panels for briefing and design development

User panels are specialist groups made up of people who will use the development when it is completed and who can contribute to briefing and design workshops.

Examples might include:

• Customers.
• Staff.
• Representatives of specialist departments such as facilities management, information and communications technology and security.
• Relevant members of the public such as visitors, neighbours and community groups.
• Residents and other occupants.

User panels might be involved in the development of:

• The strategic brief.
• The project brief.
• The concept design.
• The detailed design.
• Key components identified in technical design.

This process of consulting user panels is generally a more detailed level of involvement than consultations with other stakeholders such as wider members of the public, statutory authorities, shareholders, and so on (see consultation process).

On a small project, it may be possible to establish a single user panel representative of all user groups. On larger or more complex projects, multiple user groups may be necessary.

Individual panels might be chaired or co-ordinated by department heads or project champions. It is important that panels are genuinely representative, rather than just the usual suspects as there can be a tendency to fill user panels with high-ranking members of the client organisation who might not reflect the views of ordinary users. It is also important to structure panel meetings and workshops carefully to ensure everyone has a say, even when they are unused to contributing in a formal setting or in front of high-ranking members of their organisation, or where they have no experience of building projects.

There can be a tendency for the loudest voices to dominate proceedings, whether or not their view is the most valuable. Various techniques can be used to help people to contribute to these sessions, such as real-time 3D visualisations, and design quality toolkits.

It is important that user panels should feel motivated and engaged with the process, and should feel that they will be able to make a genuine difference to the project. However they should not be given false or unrealistic expectations as this can lead to disillusionment. Introducing some sort of budgetary reality into proceedings can be beneficial.

Wherever possible, user panels should be directed to explore functional requirements rather than to leap to design solutions. Thinking of design solutions will restrict user panels only to those solutions with which they are already familiar, whereas specifying functional requirements leaves designers free to explore all possible solutions that may satisfy these requirements. This might include non-built solutions, for example, a requirement to encourage collaborative working between client departments might be best achieved through changes to working practices rather than by building new social spaces.

Involvement of user panels should be an ongoing process rather than a one-off event. To properly influence the project, user panels should be involved as early as possible and should continue right through to detailed design and technical design where there may still be aspects of the design they would wish to influence, such as:

• Specific areas of functionality.
• Detailed layouts for standard or critical spaces, including positions of service outlets, fixed furniture and equipment.
• Technical matters such as cleaning and maintenance regimes.
• Room data sheets.
• Key components such as fixtures and fittings (for example, door handles).

OGC guidance shows the relationship between user panels and the rest of the project team as shown below.

(Ref. Achieving Excellence Guide 2 - Project Organisation page 8.)

NB: The Office of Government Commerce (OGC) has now been absorbed into the Efficiency and Reform Group (ERG) within the Cabinet Office and their guidance has been archived although it is still useful.

[edit] Related articles on Designing Buildings Wiki

• Champions.
• Client.
• Consultation process.
• Design quality.
• Design review.
• OGC.
• Integrated project team.
• Receptor.
• Stakeholders.
• Stakeholder management: a quality perspective.
• Stakeholder map.
• Third party dependencies.
• Users.

[edit] External references

• OGC: Achieving Excellence Guide 9 - Design Quality P19.
• OGC: Achieving Excellence Guide 2 - Project Organisation.