Create a centralised UCD wiki for your organisation

A centralised User-Centred Design (UCD) wiki turns scattered usability reports, workshop notes and design decisions into a shared reference for the whole organisation. Instead of guessing which spreadsheet holds the latest findings, teams can search one governed collection and follow evidence from early research through to release.

The value lies in connection. A researcher needs controlled access to study material and a way to locate consent records; a product manager needs requirements and prioritised risks; a developer needs acceptance criteria and known accessibility issues. New colleagues should understand a service, its users and the reasoning behind its design without requesting private folders.

Building this hub requires more than uploading files to a wiki. It needs clear ownership, a structure that reflects how teams work, consistent templates and a method for handling sensitive information. Technology helps, but a collection of unverified notes simply creates another source of uncertainty.

These needs are especially visible in Australia. Product and service teams are often distributed across Sydney, Melbourne, Brisbane and Perth, with hybrid schedules that make attendance at every workshop difficult. Remote participation can improve access, provided every participant receives the same materials and opportunities to contribute.

Set governance before publishing

Give the wiki a named owner, agree where it will be published, and involve product, design, research, engineering, accessibility and privacy representatives in its governance. Publish simple rules for what belongs, who can approve a page and who may archive material. Record each artefact’s status, owner and last review date, so readers can distinguish an active recommendation from a superseded finding. Pilot the structure with one service team before migrating every archive.

Set access according to sensitivity, not convenience. Where the Privacy Act 1988 applies, use the Australian Privacy Principles to manage personal information: collect it for stated purposes, keep it secure, restrict access and retain it only as needed. Store identifiable recordings separately, publish de-identified findings, and agree deletion schedules with legal or records advisers.

Design the information architecture

Design the hierarchy around services and decisions rather than the documents that happen to exist. Useful areas include research plans, personas and journeys, requirements, evaluation reports, design decisions, accessibility work and organisational guidance. Give every artefact a concise summary, links to related evidence and a visible owner, while search handles questions that do not match the folder structure.

Set conventions for naming, headings, tags and status labels. Use consistent terms for user groups, research methods and severity ratings, and explain acronyms in a glossary. For distributed teams, make pages work outside meetings: lead with the decision or finding, include dates and context, and never use colour alone to communicate status.

Build reusable templates

Templates reduce the effort required to contribute and improve comparisons between studies. A usability test template can cover objectives, recruitment, consent, tasks, observations, severity and recommended actions; heuristic evaluations and accessibility checks need equivalent fields. Ask contributors to link existing findings and cite a source artefact for every recommendation affecting requirements. In Australian retail work, include device and connectivity fields, since Coles and Woolworths app journeys can differ sharply from desktop purchasing tasks.

Choose software that fits the evidence and the people maintaining it. UCDmanager supports user roles, personas, use cases, heuristic evaluations, usability testing and web accessibility conformance evaluations. Teams can explore its demonstration project or begin with a free UCDmanager workspace for structured artefacts, while retaining wiki pages for guidance and decision records. Make that division explicit to prevent duplicated versions.

Capture evidence close to the work

Capture findings while the work is fresh, then link them to requirements, journey maps, prototypes and tickets. Each finding should identify the affected user, observed behaviour, supporting evidence, severity and recommended response. Separate direct observations from interpretation, and state the study’s limitations so a strong anecdote is not mistaken for a broad pattern.

Keep bulky or revealing material in approved repositories and place secure references on the wiki. Give artefacts stable identifiers and preserve versions for major decisions. When a recommendation changes, record who accepted it, what changed and where implementation can be verified. This creates a traceable path from user need to delivered service without exposing participant identities.

Connect research to delivery decisions

Make the knowledge hub part of delivery, not a destination visited after a project closes. Connect research intake to prioritisation, design review, release readiness and post-launch monitoring. Add notifications for updated requirements, overdue accessibility issues and rejected recommendations. The DNN e-commerce portal case described in DNN portal lessons illustrates the value of a traceable documentation trail during a large retail build.

Define lightweight review gates. Before a design advances, check that relevant research is cited, unresolved risks have an owner and accessibility requirements are testable. At launch, link the shipped artefact back to its requirements and evaluation results. Feed recurring support themes into the same structure, closing the loop between everyday service use and future design work.

Maintain accessibility, trust and currency

Treat accessibility as an operating requirement for the wiki itself. Use meaningful page titles, keyboard navigation, visible focus, suitable contrast, descriptive link text and accessible attachments. Where public-sector requirements apply, test against WCAG 2.2 AA and the Australian Government Digital Service Standard. Assign an accessibility owner to review templates, plug-ins and publishing patterns, and retain conformance evidence within the relevant evaluations.

Schedule maintenance rather than relying on goodwill. Review high-traffic pages quarterly, test links and search terms, retire obsolete guidance and publish an update log. Keep version history for decisions, but move superseded items to a clearly labelled archive. For research involving Aboriginal and Torres Strait Islander communities, preserve community-approved attribution, agreed restrictions and cultural protocols. Regular owner checks keep the hub searchable, trustworthy and safe to reuse.