Skip to end of metadata
Go to start of metadata

A pattern library providing best-practice UX guidelines, design component behavior and constraints, and UI framework terminology.

UIM Contents

Recently Updated


Proposed Patterns, Outstanding Issues



Intended Audience

Benefit of using these guidelines

User Experience Designers (UX)

  • Figure out which pattern to use
  • Create pattern
  • Update pattern
  • Delete pattern

Business Analyst (BA) or Subject Matter Expert (SME)

  • Learn about UX basics

Front-end Developers

  • Get code sample for design component
  • Review unimplemented pattern
  • Research new ideas for patterns

Implementation Manager

  • Understand purpose and value of UIM

Quality Assurance Tester (QA)

  • Verify functionality (only in the absence of the prototype)
UIM Development & Contribution Process

Overview of flow of information

  • UIM Log > Sandbox Discussion Docs (google docs) > Wiki 

Capturing Issues 

  • Daily issues, questions, decisions are captured in  UIM Log  during discussions.  (Rationale: during wireframe reviews and meetings, it is often easier to note issues for discussion in one document than finding the appropriate document to capture things, and because sometimes the discussion itself suggests changes to how content in the UIM is organized.)
  • Each week Core UX should look at the google docs folder that contains all UIM sandbox discussion docs to see what's been updated.
  • The UIM Log is processed by moving questions, assumptions, and decisions to appropriate sandbox discussion docs.

Serial Processing 

  • When time allows, Core UX serially processes a UIM component, container, or pattern. 
  • This involves giving additional input, attempting to resolve questions, and validate assumptions by making decisions.

  • Ideally, all assumptions that are moved to decisions will have gotten some vetting with other UX staff beyond Core UX.

Wiki Documentation

  • Core UX processes decisions from sandbox discussion docs by moving them onto the UIM wiki, integrating the new decisions into existing content. This can involve entire rewrites, wordsmithing, or simple addendums.
  • All items moved from the sandbox discussion docs are grayed out to indicate that they are documented in the wiki.
  • (Note: some UIM assumptions were moved to the wiki when bandwidth did not allow vetting by the UX lead. These items are grayed out in google discussion documents to indicate this status.)

Expanding Contributions  (after it is stable)

  • People should continue to add questions, assumptions, and notes. 
    • These can be added to the the sandbox discussion docs, or directly on the wiki pages (under Note an Issue).
    • In the sandbox discussion docs, people can include rich artifacts in sandbox discussion docs--images and links to prototypes/resources–to illustrate issues or better communicate desired behavior.

  • Some people whose experience and expertise is sufficient, can be "trusted" documenters and update the wiki directly. Others will need further experience before they can update directly and they should note questions and assumptions.

Surfacing Relevant Jiras

  • From time to time, Core UX & Core Technical should do a review of outstanding KS Jiras to identify which represent UI limitations.
  • These Jiras should be  tagged by Core UX using the correct User Interaction Model, and summarized in the Limitations area of the wiki for the relevant UIM entry.