Versions Compared

Version Old Version 4 New Version 5
Changes made by

Lukas Reidinger

Lukas Reidinger

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

🌱 Feature specification

Table of Contents

Usage

Variations

Behavior

Style

Title

Give the component a name.

Description

Briefly expl

Anatomy diagram

Key to anatomy diagram

🧐 Specifications

explain what the compoennt does, e.g., “An avatar is an image that reperesnts a user or entity.”

Benefit

List the benefits this feature will provide.

Anatomy diagram

Type / image to uplaod a diagram of the compoennt with numberer callouts. Use the basic verison of the component and make sure the example has good copy.

Key to anatomy diagram

  1. Define each of the callouts in your anatomy diagram.

Mockups

Provide a link to mockups for this feature.

🧐 Specifications

Usage

Give an overview of the component an dhow it’s used, e.g., “Use avatars to identify a user or entity in a product. Typically, users will uplaod their own image, but they may also stick to the deafult image.”

Variations

Provide examples for standard arioations that appear in your product. If possible, these exampels should be cerated with live code for your design system’s repo.

Behavior

Describe how the component behaves in different contexts.

Style

  • describe how the component should be styled, visually. Include informaiton baout alignment, padding, etc., as well as “do” and “don’t” examples.

📐 Additional guidance

Content

  • Provide component-specific guidance on content, such as punctuation rules, standard labels, etc.

Accessibility

  • Provide component-specific best practices for accessibilty.

Mobile

  • Provide guidance on how to apply this component in mobile environments.

Best practices

  • if there are industry standars fo this component, list them in this section. Include “do” and “don’t” examples to illustrate each point.

Related

  • List related components or patterns. Include links whenever possible.

Process:

  1. Create tickets for a new feature in Jira (

    1. Create an Epic with the feature name

    2. Break down tasks into separate tickets linked to the epic, each ticket should not be longer than 1 week of work, to make sure it can be implemented and tested in a two-week sprint.

    3. Estimate effort, add a description, flow, or any other information that is available.

  2. Tickets are added to the sprint.

  3. A ticket is implemented according to specification and functionality as described in spec. confirmed in QA process.

  4. If a ticket cannot be implemented as described in the specification, this could be due to technical reasons, bandwidth issues, priority changes…

    1. Reasons need to be brought up to the product manager (Nick).

    2. In a discussion, a decision will be made to either follow the specification or alter it.

    3. If the specification is altered it needs to be written down and the Jira tickets need to be updated with new information.

    4. This goes back to point 3. ticket to be implemented according to the new specification.

...