
User experience design activities result in the blueprints for design and development. These take the form of various deliverables. In the interest of clarity and the reduction of mumbo–jumbo, they are described and illustrated below:
This document defines user types; organizes site functionality into logical groups and describes these; and then delineates each use case where that functionality comes into play. The use case model addresses actors, prerequisites, actions and expected outcomes, and error conditions. The document may include flow charts to demonstrate the expected steps of a process. It may also note priority levels for different features, which are important reference points for eventual site build-out costing and scheduling.
Following actual usability testing, this narrative report, illustrated with screenshots and/or charts, describes the usability test participants, test design, findings, and recommended actions. It usually includes the test session script as an appendix. The purpose of the report is to highlight positive aspects and areas for improvement, and to provide a reference for prioritizing changes and fixes.
This short narrative document conveys a mutual, detailed understanding of the business goals and objectives for the site, audience profiles and typical user tasks, desired content and features/functionality, and the context of site usage (e.g., personal or kiosk/shared PC, connection speed, browser version, etc.). This serves as a common reference point for both the Client and the site development team.
Personas are archetypal users who represent the major motivations and behavior patterns of the audiences your product, service or web site is intending to serve. As such they "stand in" for actual users and help keep you honest. As a deliverable they usually takes the form of a one-page summary of a fictional person with a name, role, typical day, key goals, attitudes and beliefs, and the context in which the persona uses the site. Persona profiles are created based on evidence gathered from direct and indirect contact with customers, site usage data and metrics, and existing private or public research.
Based on the understanding of audience, content, and planned functionality of the site, this overview diagram shows content organization and labeling, navigational paths, access control (i.e., which pages/sections are restricted to certain users), and an approximation of the number unique page types. After the Requirements specification, the diagram is often revised and fleshed out with additional detail. The site architecture diagram can be used not only as a reference for the site development team but also for the Client to show others the “big picture” of what is to be built.
These low-fidelity diagrams describe each type of page on the site, and what elements that page must include, i.e. navigation, content, means of interaction, expected results of an input or interaction, etc. Wireframes are a later-stage deliverable that should be created after a basic idea of structure and function has been formed. While not indicative of the ultimate graphic interface, these schematics are tools that guide the work of both developers and graphic designers, to ensure a smooth, consistent experience for the user. In some cases they can be used for paper prototype usability testing.
Usually a spreadsheet with commentary, this describes existing and intended content for the site (text, images, other media, and data from databases) – and tracks specific information about format, location, ownership, frequency and manner of update, and content type. Depending on the size and complexity of the site, this may track all content or a good representative sample of content. The purpose of this deliverable is to aid the grouping of content and identification of page types. Ultimately it can be used as a content production checklist during the actual build-out of the site.