Jan 13, 2026 | Design system team sync

Name: Jan 13, 2026 | Design system team sync
Uploaded: 2026-01-13T19:48:57.000Z
Duration: 1 h 40 min 40 s

Planning Discussion and Structure

Introduction to Planning Issues

The meeting begins with a focus on improving planning processes, specifically regarding issues, tasks, and epics. Paul is invited to lead the discussion.

Current Challenges in Planning

Paul highlights the need for more accurate and actionable planning as current methods show inefficiencies.

There are issues that cannot be easily completed within a milestone, leading to work that spans multiple years or lacks clear exit criteria.

Breakdown of Work

Emphasis is placed on breaking down work into manageable parts so that tasks can be opened and closed effectively within milestones.

Complexities arise when a single issue encompasses multiple types of work (e.g., design and engineering), making it difficult to assign responsibility or close tickets.

Proposed Solutions for Task Management

A suggestion is made to create child issues or tasks for better organization of work streams. This would allow clearer assignment and tracking of responsibilities.

Questions arise about where discussions should take place—within child tickets or up in parent tickets—to maintain visibility while managing interrelated tasks.

Importance of Clear Scope

Paul notes that while design and engineering are often discussed, other areas may also require similar breakdown strategies for effective task management.

Insights from Dan on Issue Structuring

Effectiveness of Clear Scopes

Dan shares experiences from previous roles indicating that clear scope and designated responsible individuals (DRIs) enhance the effectiveness of using issues and tasks.

Challenges with Interrelated Tasks

He points out difficulties when teams must collaboratively figure out plans or initiatives due to the interconnected nature of their work, which complicates defining clear scopes.

Complexity in Planning Processes

Dan emphasizes that when everything impacts everything else, establishing neat scopes becomes challenging, affecting overall planning efficiency.

Team Structure and Task Management

Philosophy of Work Breakdown

The speaker emphasizes a desire to establish a structured approach to breaking down work into manageable chunks that align thematically, allowing for individual ownership and completion.

Encouraging Team Participation

The intention is to foster an environment where all team members contribute to managing tasks in GitLab rather than relying solely on leadership for structure creation.

Creating Issues and Subtasks

Team members are encouraged to create new issues or subtasks when they identify additional work needed, even if it's just a preliminary stub with a name.

Planning and Time Allocation

A proposed planning structure allocates 60% of time for stable tasks while leaving 40% flexible for reviews and new requests, aiming to reduce chaos from previous milestones.

Cultural Change in Task Management

The discussion suggests adopting a cultural practice where every issue should have an assignee and milestone; if the scope seems too large, it should be broken down collaboratively.

Ownership and Responsibility in Task Creation

Starting from Current State

Team members are urged to assess their current issues, determine if they require sub-tasks, and take initiative in creating those subtasks as part of their ownership.

Example of Ineffective Ticketing

An example is given regarding an issue assigned to Mark about fixing UX issues; it highlights the need for clearer task definitions that specify achievable outcomes within milestones.

Importance of Clarity in Tasks

The necessity for detailed subtasks is stressed since vague tickets can lead to misunderstandings about what needs to be accomplished during a milestone.

Discussion on Issue vs. Task Terminology

Preference for 'Issues' Over 'Tasks'

There’s an ongoing conversation about whether the term "issues" or "tasks" should be used; the speaker leans towards "issues" based on its clarity within the team's context.

Experience with Tasks in Larger Teams

A participant shares their limited experience using tasks during specific projects, indicating that familiarity with terminology may vary among team members.

Discussion on Task Management and Issue Tracking

Overview of Task Closure and Issue Handling

The process of closing tasks is described as straightforward, with no need for extensive discussion once smoke testing is complete.

The UI for task management has evolved, but the speaker notes that it was previously streamlined, indicating potential changes in functionality over time.

Issues vs. Tasks: Features and Usability

There is a debate about whether to use tasks or issues; issues are seen as more feature-rich, allowing for better tracking and management.

Personal experiences with tasks reveal they were often used individually rather than collaboratively, serving primarily as personal checklists.

Managing Subtasks within Issues

Team members are encouraged to assess their assigned work and split tasks if necessary, emphasizing proactive management of workload.

When multiple aspects (design, engineering) are involved in an issue, creating child issues can help manage responsibilities effectively.

Communication and Documentation Practices

Discussions around design decisions should be documented in both the main issue and its child issues to maintain clarity without overwhelming team members with information.

A suggestion is made to summarize discussions from child issues back into the parent issue upon completion to ensure all relevant information is centralized.

Best Practices for Information Sharing

It’s proposed that summarizing outcomes at the closure of related issues could enhance communication across teams.

The idea of maintaining a decision register or central documentation system is highlighted as beneficial for larger projects to track discussions and decisions effectively.

Implementation Challenges and Solutions

The importance of team commitment to documenting discussions is emphasized; if challenges arise in this practice, solutions such as automation or reminders may be explored.

Milestone Planning and Component Development Discussion

Milestone Planning Enhancements

The team aims to refine milestone planning, making it more robust and clear as they adjust dates in their Epics' roadmap due to new challenges.

Emphasis on the importance of having well-defined tickets that are achievable within the current milestone and assigned to individual team members.

Work Flow Clarification

Acknowledgment of uncertainty regarding how work is supposed to flow through the group; discussions are ongoing about improving this process.

The intent is to maintain momentum on component development post-holidays, avoiding long breaks that could stall progress.

CRUD Component Discussion

The main focus is identifying necessary decisions and discussions required to advance the CRUD component into the design system.

Team consensus is sought on what needs agreement before moving forward with development efforts.

Naming and Consensus Issues

Initial naming confusion around "index container" versus "embedded list," with a preference emerging for "index container."

Agreement among key team members (Dan and Thomas) on naming, but concerns remain from others about broader consensus.

Migration Challenges

Discussion highlights a desire to open a merge request against the design system while ensuring practical usability through testing in product environments.

Debate over whether to enhance functionality for easier migration or adapt existing products to fit a minimal version of the new component.

Decision Points for Progression

Key decision revolves around adjusting specifications for easier migrations versus proceeding with an ideal version without immediate migrations.

Recognition that some existing product usages are close enough that minor adjustments could facilitate smoother integration with the new component.

Discussion on Component Design and Flexibility

Challenges with Inline Forms

The design aimed for an inline form that is visually appealing, accessible, and easy to close. However, many components have varying button requirements beyond just an "add" button.

Complexity of Form Usability

There are instances where a large form may not be suitable for inline display. The design approach felt overly strict and complicated, leading to confusion about the desired functionality.

Migration Considerations

The discussion highlighted the difficulty in migrating existing usages to a new inline form structure, which could complicate product functionality.

Avoiding Unused Components

Merging components into the core layer without clear usage can lead to maintaining unnecessary elements. It's essential to ensure that any component added has practical applications.

Slot-Based Flexibility

A potential solution discussed was using slots instead of fixed buttons, allowing for faster rollout while retaining flexibility. However, this could lead to inconsistencies in how components are used across different contexts.

Evaluating Current Product Usage

Identifying Suitable Candidates for Migration

Questions were raised about whether current versions of components could be swapped easily within the product or if adjustments would be necessary based on specific use cases.

Read-only vs Editable Lists

It was noted that some candidates for migration were read-only lists; however, the focus should be on editable lists that include actions like adding or editing items.

Technical Limitations and Future Directions

HAML vs JavaScript Capabilities

The limitations of HAML (HTML Abstraction Markup Language) were discussed regarding its lack of JavaScript interactivity capabilities, making it challenging to implement dynamic features effectively.

Potential Solutions for Static Components

If forms are removed entirely in favor of static cards with lists inside, it might simplify implementation but limit smart functionalities needed in more interactive designs.

Exploring Additional Flexibility Options

Balancing Modal Implementations

There’s a need to assess whether modal implementations are necessary or if alternative methods can facilitate smoother migrations between different component usages while considering user interactions.

Defining Extra Functionalities

Discussions included exploring additional functionalities beyond basic add buttons due to varied user needs; defining these extra capabilities could enhance overall component usability.

Discussion on Component Migration and Iteration

Exploring the Path to Product Integration

The team discusses the need for a clear path to integrate new components into the product, emphasizing the importance of iteration in this process.

There is a consideration of whether to allow the absence of migration candidates to hinder component release or if it can be addressed post-release with early adopters.

The conversation highlights delivering a new baseline for design patterns rather than forcing migrations into inconsistent existing implementations.

Confidence in Solutions and API Changes

A key concern is establishing confidence in solutions before making significant changes to APIs, stressing that there must be valid reasons for not integrating new components.

The discussion reveals that there are approximately 80 usages in JavaScript and 85-90 in HAML, suggesting multiple candidates exist for migration.

Documentation and Implementation Challenges

A mismatch between product needs and available components is noted, particularly due to poor documentation visibility for current components not included in the design system.

Historical context shows that initial streamlined designs have evolved into various implementations, complicating consistency across teams.

Ensuring Consistency Across Implementations

The team debates whether they can enforce a single implementation approach with new components, reflecting on past experiences with variations leading to inconsistencies.

Concerns arise about overuse of modals and drawers as alternatives to inline forms, indicating a broader trend affecting component usage.

Addressing Flexibility vs. Risk

Flexibility within components poses risks; while it allows diverse applications, it complicates future changes due to varied existing uses.

Specific use cases are discussed where multiple icons or actions may lead to confusion or poor user experience when implementing CRUD operations.

Technical Challenges and Misuse Prevention

Technical challenges are highlighted regarding deep integrations within products that complicate potential migrations or adaptations of components.

Despite efforts to guide proper usage through documentation, complete prevention of misuse remains challenging due to inherent flexibility within component designs.

Discussion on Component Usages and Migrations

Understanding Current Usages and Future Directions

The speaker expresses concern about the lack of usages for a component, suggesting that having zero usages is unreasonable. They propose exploring ways to increase this number, possibly by adjusting scope or collaborating with consumers to streamline changes.

There is a call for action to move forward rather than remain stagnant. The speaker questions whether more flexibility in the component design is necessary and reflects on whether they have limited themselves in their approach.

The discussion highlights specific examples of components (e.g., multiple count buttons), indicating that only a few out of many fit the intended usage pattern. A plan has been proposed to address these discrepancies in future iterations.

Emphasis is placed on the importance of user interactions with UI elements that should be consistent across products but often behave differently. This inconsistency can hinder task completion for users.

Clarification is made regarding CRUD component migrations; the new component's purpose differs from existing ones, which are primarily used for grouping forms. The speaker believes there are numerous instances across different views that could benefit from adjustments.

Confidence Levels and Pre-Merge Considerations

The speaker acknowledges being close to a solution but stresses the need for confidence before merging any changes into production. They suggest identifying potential issues pre-merging and engaging with teams involved.

Questions arise about how confident they are in the current API if merged now, especially concerning ongoing migrations. There's an emphasis on maintaining control over significant changes post-merge.

Concerns are raised about merging components without sufficient usage data or confidence, echoing support for thorough evaluation before proceeding with any merges.

Steps Forward: Documentation and Feedback

A systematic approach is suggested involving collaboration with engineering teams to create sub-tickets addressing various migration tasks, ensuring organized progress through identified issues.

Initial steps include agreeing on naming conventions for components to avoid future confusion during development processes, emphasizing consistency within documentation practices.

Documentation-driven development is highlighted as crucial; clear documentation can enhance understanding and implementation success among team members regarding new components.

Engaging directly with teams who will utilize these components can build confidence through feedback loops, allowing them to assess functionality before broader implementation occurs.

This structured overview captures key discussions around component usage, migration strategies, and collaborative efforts needed moving forward while providing timestamps for easy reference back to specific points in the transcript.

Discussion on Project Implementation and Feedback

Direct Outreach for Feedback

The speaker emphasizes the importance of direct outreach to close areas rather than seeking broader feedback, suggesting a more focused approach to gathering insights.

There is an acknowledgment that ongoing work exists, indicating that current implementations should not limit future developments.

Collaboration and Existing Work

The speaker notes that some teams are waiting for specific discussions to proceed with their projects, highlighting the interconnectedness of various groups' efforts.

Mention of the settings working group indicates active collaboration where patterns in project development are emerging, allowing for simultaneous reworking and debt reduction.

Action Points and Summary

A summary of the discussion will be documented along with action points to ensure accountability and tracking within the issue itself.

The speaker expresses gratitude towards Thomas for his contributions in resolving comments related to merge requests (MR), showcasing teamwork in addressing feedback.

Conclusion of Meeting

Participants express appreciation for each other's involvement, emphasizing a positive outcome from the discussion.

The meeting concludes with well wishes for participants, reinforcing a collaborative atmosphere moving forward.