Discovery Designs

This is where rough designs of the new research discovery system will be published. It will generally be displayed as static HTML files with very light interaction (if any.) Each design will have an associated Google Document which will contain notes and various design decisions represented in that particular design. It is meant to be a light way for us to "design out in the open" and allow anyone interested to follow and contribute to the design process.

Click the diagram below to see the status of the website.

Goals

You can think of the wireframes and mock-ups on this site as visual brainstorming of high level concepts and components that inform and support the ongoing prototyping/development of the system. The goals of these designs are as follows:

1. Provide visual representations of high level concepts and components of the discovery system to improve overall coordination, communication, direction, and standardization within the team and with stakeholders.
2. Provide living and visual documentation of the design process for use during the development process and for future product development internally and externally.
3. Provide a space for innovation, inspiration, and critical thinking about digital library work. This will enable us to remove assumptions about how a catalog should work, focus on the research community that it will serve, and demonstrate what a library can and should build when artificial barriers are removed.
4. Provide a space to work transparently and collaboratively by publishing near-realtime designs and documentation and providing clear channels for dialogue and feedback.

Definitions & Purpose

User journey

• A user journey is a series of steps that represent a scenario in which a patron or staff member might interact with the catalog system informed by research and interviews.
• We wrote a series of user journeys that will help define the components and workflows of the system, and help optimize the overall experience.
• These user journeys will be used to design user interface/experience studies and inform the creation of wireframes (see following section.)

Wireframe

• Wireframes are a series of visual guides for communicating high level functionality, behavior, and content of user journeys within the new research discovery system.
• A wireframe focuses on what a what a page does rather than what it should look like (i.e. function and content, not style).
• Wireframes generally contain little to no color, graphics, or interactivity.

• Purposes of wireframes when showing to team and stakeholders:

  • Identify un/under-represented functionality, data, or use cases
  • Identify better ways of organizing and prioritizing content
  • Identify services (e.g. item holds, user authentication) that are not being accurately represented or need further clarity
• All major screens/pages will have wireframes associated with them. You can see them listed on the right of this page.
• There is a sample questionnaire for research staff or patrons regarding high level interface and experience questions.

Mock-up

Mock-ups have some overlap with wireframes in that they are also visual representations of high level concepts and components of the discovery system to improve overall coordination, communication, direction, and standardization within the team and with stakeholders. However, they are different in the following ways:

• Mock-ups may communicate interactivity and dynamic behavior/states of a particular page. For example: modals, dynamic forms, faceted search states
• Mock-ups allow for variation design to quickly explore different ways of laying out content and realizing functionality without actually implementing that functionality.
• Mock-ups use color, design elements, and relevant imagery to communicate the purpose, content, and functionality of the page.
• Mock-ups create the building blocks that can be used in functional prototypes. For example, a developer should be able to translate components in a mock-up into a functional interface using real data.

• Purposes of mock-ups when showing to team and stakeholders:

  • Identify more intuitive or efficient ways to accomplish a task
  • Identify better ways of organizing, prioritizing, and displaying content
  • Identify design elements and strategies that best suit a page's content and purpose
  • Identify standards and best practices that make interactivity more inclusive

Feedback

Your feedback is critical to the design process. In addition to setting up in-person feedback with groups and individuals in the research community, we will be receiving feedback online using the following process:

1. Each design will have a Google Document associated with it which will contain a list of design components and descriptions
2. Visit a document and make sure you are signed in using your @nypl.org account
3. Add a comment to any part of the document that is relevant to your feedback. This will allow us to discuss the issue with you and possibly resolve it
4. If you can't find a relevant item in the document to add a comment to, please add your issue to the bottom of the document and include your email address or add a comment to it so we can respond to you.

All types of feedback are welcome, but given the goals of the designs, a focus on high-level feedback is preferred. Some examples of high-level feedback:

• Better ways information can be organized and communicated
• Missing functionality or data
• More intuitive or efficient ways to accomplish a task
• A use case that is not sufficiently being addressed
• A service that is not accurately being represented

Email brianfoo@nypl.org or Slack @beefoo in #discovery for any other questions or feedback that does not fit into the above process or if you'd like to set up an in-person feedback session.