Skip to content

Projects

How to build a reference library for an interface project

Organize URLs around design decisions, note what each source helps resolve, and work through an annotated form example.

Build an interface project's library around decisions you need to make: structure, content, forms, navigation, or accessibility. For each URL, record what you noticed and a possible application. A small, annotated selection is easier to consult than screens collected without context.

1. Define a deliverable and its open questions

Use a concrete task such as a course registration page. List the decisions: what information to request, how to explain required fields, and how to guide someone after an error. These questions give you criteria for selecting sources.

Separate principle references from implementation references. Documentation can clarify behavior and constraints; a visual example can suggest a layout approach. Neither replaces understanding your audience's needs and testing the resulting interface.

2. Select sources for each decision

For the course form, MDN's web forms documentation can support implementation questions. The W3C WAI forms tutorial provides accessibility guidance. Both links appear below: visit the relevant section and record what you want to evaluate instead of saving only a homepage.

These are study references, not proof that your form is correct. Record the date or version when relevant, and check current documentation during implementation. Do not attribute conversion results to an example that has not been tested in your project.

  • Structure: which fields does the task require?
  • Guidance: which instructions help before input?
  • Errors: how can someone understand a problem and try again?
  • Accessibility: what needs checking with a keyboard and assistive technology?

3. Organize URLs with their intended use

In Mneeemo, a “Course — registration” folder can collect project links. Tags such as “form” and “accessibility” identify characteristics that can recur in other work. The note records which decision you want the source to support.

The example below is an illustrative brief, not a report of user testing. Avoid copying a reference's appearance without understanding its criteria. If you keep an excerpt, identify it as a quotation and preserve its author and source address.

4. Turn the selection into a project review

Find the folder or a word from your note, open the source, and write down the decision it helped you make. If a reference answers no project question, it can leave the working selection without disappearing from the whole library.

After delivery, separate reusable principles from course-specific details. Update the note with what still needs checking. The library's value lies in supporting decisions; collecting references alone does not demonstrate better usability.

A design reference becomes useful when you connect it to a decision and a project check.

Questions you might have

How many references should I collect?

Start with enough sources for your current questions. There is no universal number; add another when it clarifies a decision that remains open.

Can a screenshot replace a link?

It can preserve a visual detail, but not access to the source and context. Keeping the URL helps check authorship, behavior, and updates.

How do I keep the library from becoming only inspiration?

For each working reference, write the decision it supports and a next test. If there is no clear application, keep it outside the active selection.

Put the idea to work in your library.

Start my library