---

599^.00 Register for this workshop → Get a single workshop, or bundle with another workshop.

Making good choices when naming props, modelling features and affording composition through slots is essential for a high-quality design system. This challenges those architecting systems to spot patterns, solve puzzles, evolve practices, and set conventions to craft components thoughtfully and elegantly.

Changing how components work can be confusing and costly, breaking the contract of how component users already implemented and requiring rework to continue using it as they expect. Therefore, one must construct component API carefully from the outset and minimize impacts of breaking changes as a component evolves over time.

---

You’ll leave the workshop with a toolbox of practical techniques and design patterns to apply for your projects right away.

Note that this workshop does not explore every facet of spectacular component architecture. In particular, a separate workshop — Spectacular Component Structure and Styling with Design Tokens — digs into defining a component’s identity, name and purpose, decomposing components into elements, styling, and developing a taxonomy of design tokens.

We’ll Cover

Component props

• What props are and why they matter
• What prop types are available and how they vary by platform
• How to discover and scope potential props for common components
• How to define props for simple components, like icons, badge and buttons
• How to model props that control element visibility and content
• How to account for defaults, options, and null values
• How to handle prop interactions that lead to more or missing variants
• How to define props for complicated components like text input and alert
• How to architect props for interactive and within component states

Across-library API alignment

• How to audit libraries across platforms to identify gaps and differences
• How to construct API alternatives, make a recommendation and decide
• How to scope, track and implement API changes

Versioning and breaking changes

• How to version components and libraries using semantic versioning
• How to understand what is and isn’t a breaking change in UI components
• How to evaluate cost, effort, and scale of breaking changes
• How to prepare teams to upgrade due to breaking changes
• Who’s responsible for reintegrating revisions
• How to work with your team to define a breaking change policy

Component layout

• How to encapsulate spacing within components
• How to achieve consistent height and width across components
• How to approach layers of elements nested in components
• How to vary size and density across a component catalog
• How to define, arrange, and space component groups

Component slots

• What slots are and why they matter
• How to define slots
• How to break down modular components like cards and modals
• How to spot, frame and approach composition inside components
• How to understand and mitigate risks of usability and accessibility
• How to distinguish and align slots in design assets and code libraries
• How to leverage a “three part layout” of header, body and footer
• When to to substitute custom arrangements for primitive elements
• How to approach slots for common scenarios like card, modal, and row
• How to approach slots for simple components like button
• When to offer generic containers, configurable elements or both
• How to proliferate and manage extensions of a core component with slots
• How to offer ready-made examples that demo possibility and expected use
• How to decide to offer configurable props, composable slots or both
• How slots challenge designers and developers used to configuring props
• How to help slot users learn, work fast, and feel productive

Subcomponents

• What subcomponents are and why they matter
• How and when to divide a component into subcomponents
• How to spot subcomponent opportunities like a text lockup
• How to avoid subcomponents you don’t need or shouldn’t have
• How to name subcomponents serving different purposes
• How to decide what subcomponents are published, hidden and/or embedded in designed components
• How to decide whether a subcomponent is limited to a one parent or to generalize it for wide reuse

Who is this workshop for?

Architecting UI components and design tokens is a multidisciplinary pursuit. Therefore, the workshop is aimed at designers, front end engineers, product owners, managers, and leaders setting up or optimizing how to operate a design system and build sharable components at scale. The workshop assumes participants are familiar with user interface design fundamentals and digs further into details. Content evokes design and code considerations, usually in concert, to bridge disciplines to share the responsibility for scalable visual style, UI components, and documentation.

What hardware/software do you need?

To get the most out of the workshop, you’ll need access to Figjam (for hands-on activities) and Slack (using a SmashingConf private channel for workshop communications). You will not use design tools (such as in Figma or Sketch) or code in a code editor. Instead, activities will be collaborative in a team or full classroom setting using Figjam.

Location

Microsoft Conference Center is right in the heart of Times Square. Close to transportation and endless food and entertainment options, this technology hub is located at 11 Times Square (with the entrance on 8th Ave).

Time & Location

The workshop will be running from 8:30 AM to 4:45 PM on Tuesday, June 24.

Schedule for Tuesday, June 24

8:30 AM – Doors open, Registration
9:00 AM – Introduction & Kick-off
10:30 AM – Coffee Break
12:00 PM – Lunch
1:00 PM – Afternoon Session
2:45 PM – Coffee Break
4:45 PM – The End

Save 200 USD when signing up for two workshops!