Works

Task created via Slack

An integrations framework for a task management tool

Building one pattern to absorb 7 integrations that all behave differently

Role

Senior Product Designer

Status

Slack integration shipped

Scope

Establishing patterns and mapping scenarios

Timeline

2 weeks

The problem

Designing for existing environments

Superlist's founding premise was that it wouldn't ask users to change their tools. It would meet them where they already worked. Turning it into a product reality meant designing a system that could absorb the logic of Figma, Slack, GitHub, Gmail, Google Calendar, Linear, and Productboard, and surface all of it consistently inside a single interface. That was the actual design problem.

Integrations list

approach

How do you design multiple integrations that behave fundamentally differently, without ending up with indvidually bespoke screens?

Each integration had its own connection logic, its own trigger type, its own configuration needs. GitHub creates tasks when a pull request is opened or an issue is assigned. Gmail converts emails automatically based on sender rules. Productboard maps feature statuses to task lifecycle states. Slack creates tasks from individual messages. These are not the same problem with different logos on them.

The risk of designing them one at a time was structural drift: each integration solving its own problem in its own way, with no shared pattern holding them together. The settings layer would become inconsistent, the configuration logic would be unpredictable, and the cost of adding each new integration would compound.

The real design question was how to establish a framework that could absorb that variation without exposing the complexity to the user, and without requiring the team to start from scratch each time.

solution

The settings architecture

A consistent two-panel pattern across all integrations: integration list on the left, per-integration detail on the right. Every integration followed the same structural logic: connected accounts, account settings, trigger configuration. The variation lived inside that shell, not in the shell itself.

The settings architecture

Integrations list with card open

Per-integration configuration

Each integration had its own trigger logic designed within the shared pattern. GitHub used toggles for discrete events. Productboard used status-mapping dropdowns to define when tasks should be created and completed. Gmail used auto-convert rules by sender category. The framework had to be flexible enough to hold all of these without the pattern breaking.

Per-integration configuration

Integrations configuration cards

Task card and activity log attribution

When a task originated from an external tool, Superlist had to make that legible without cluttering the interface. Source icons denoted origin at the card level. Activity logs reflected external events, a PR being closed, an issue reassigned, as native Superlist activity. Backlinks connected tasks back to their source objects. The design question here was how much of the external tool's context to carry through, and the answer was consistently: enough to be useful, not enough to replicate the tool.