You’ve heard of design .

You likely have one. And if you don’t, you probably should.

But along for the ride are other names that may have been reasonably well defined within the of your project, client or organization. They even have solid definitions outside – across the industry. Names like: frameworks, software design guides, pattern libraries, component systems, UI kits, style guides, and design tokens.

There are no universal and agreed upon definitions. And there’s a lot of grey areas, overlaps and gaps between them. However, there is at least a widely-accepted premise that the phrase “design system” is intended to be the highest level all-inclusive descriptor.

Let’s explore how to close the gaps with a more complete structure for the design system and its supporting documents.

 

Minding the Gap

Here’s the general hierarchy of the typical design system that I encounter:

Design System

1. Principles

2. Accessibility

3. UI
     3.1. Global Styles
     3.2. Templates
     3.3. Components
     3.4. Styles

But that’s not always enough. We need to dive much further than just the surface of our product. For example, for certain elements, we should also define:

  • Document structure and nesting
  • Appropriate parent container elements
  • Attributes, roles or microformats
  • Text web standards and accessibility criteria
  • Considerations for translation and localization

UI design alone is not a basis for a design system.

It’s actually more of an output of the system. The system therefore, must have inputs. Those inputs provide context for decisions.

Include them. Some decisions may have been well-informed through research. Other decisions may need no explanation. Still others may be difficult to articulate and defend. But all are important to document.

“[looks at all products] …and then design this one single design system for everything. However, once you start diving into why those decisions were made, they often reveal local knowledge that your design system doesn’t solve.” — Rune Madsen

Pulling Up One Level: Describing Full Context of a Design System

Any design system is also greatly influenced by contextual inputs like:

  • The institutional knowledge, legacy, culture, beliefs and biases of the organization (and those the system when done on behalf of clients)
  • Insight for how patterns are named and what problems they solve
  • Conventions for how class names and selectors are decided (with case, characters, separators, depth, specificity, etc.)
  • Success criteria for a design system
  • User research, usability research, and resulting and themes that supports decisions in the design system

These all represent the decision making criteria in addition to the actual decisions.

A Meta Metaphor for Design Systems

So how do we capture this context?

In HTML, every document begins with a <head>.

The head element represents a collection of metadata for the document. Your design system needs a <head> to describe its context.   

For example, while process, source control and governance typically fall under the role of Design Ops (operations), they should still be documented.

Here’s a structure for metadata and a more complete design system:

<head>
    Research & Insights
    Principles & Ethics
    Privacy &
    Problem Statement(s)
    Methodologies & Process
    Definitions
    Usage Guides
    Other Criteria
    Ecosystem
    Localization
    Performance Budget
    Source Control
    Governance
    Copyright & Licensure

</head>
<body>
    Design System
    1. Principles
    2. Accessibility
    3. Platforms & Channel
    4. Input
    5. UI
         5.1. Voice & Tone
         5.2. Components and Patterns
         5.3. Styles
         5.4. Motion
     6. Content
     7. Localization & Variants
     8. Performance Budget
     9. Markup
          9.1 Source Control
    10. Hosting
    11.  Web
</body>

Conclusion

All design systems have an origin story and iterate and evolve. Any changes made are the result of new learning. Capture that somewhere.

The “<head>” seems to be the perfect metaphor for that much needed layer of abstraction of all of the metadata about the design system.

For more advice, download Creating a Design System: The 100-Point Checklist. The guide is based on real projects and case studies. 

The post Creating Context for Design Systems: A Comprehensive Approach to Documentation appeared first on Studio by UXPin.



Source link

LEAVE A REPLY

Please enter your comment!
Please enter your name here