Product > Component

Product > Component

A description of the component’s function, and as at product level, including any known limits. At component level, you may find references to specific aspects of persona, but components directly address a need. In most cases they have a 1-1 relationship with user-facing modules.

This is the country (or continent) map which describes the major cities and the laws of the land in that country. There may also be trade agreements and as such import/export can be detailed.


If there are important words to understand in this area, make them clear and obvious here.

Architecture & Design Principles

Any key architecture or design decisions (more specific than those at the product level) surrounding this component.

API Reference

One or more links, or inlined details, around the API that this component exposes to other components or directly to the outside world.

Sources & Subsystems

A list of the source repositories and subsystems (if they exist) of this component. This should include references to the file of the subsystem, or the repository path (it should really be enough to git clone from) as well as the nature of the repository or subsystem: host, 3rd party, adopted, custom, etc.


One or more lists of:

  • what components are required for this one to function
  • what external or 3rd party services are used
  • what external or 3rd party software is needed
  • what libraries are used


What test tools, what regression packs, what tests are important to this component. This may be delegated to subsystems.


Which team and/or people have ownership over this component and it’s subsystems. It would be wise to include a skills/competencies map to ensure it’s clear what is required to own a the component.

Decision log

As at the product level, key decisions about the component are recorded chronologically, with enough context to be useful after the fact.