Design QA for pull requests

Every component change gets a designer's okay before it merges.

Your pipeline builds a preview of the components a pull request changes. Designers compare them, pin comments and approve or request changes, and the verdict lands right back in Azure DevOps.

How it works

The loop runs inside the pull request you already use. Developers don't need a new tool, and designers don't need to read code.

  1. 1

    A developer opens a pull request

    The pipeline builds a preview of just the components that changed, plus their versions on the base branch.

    Developer · Azure DevOps
  2. 2

    A designer reviews it

    Compare before and after, spot pixel changes in the diff and pin comments where they matter.

    Designer · Looksgood
  3. 3

    The verdict goes back to the PR

    Comments arrive as threads, and a design check passes or fails on the pull request. The developer pushes a fix, and the new build reopens the review.

    Developer · Azure DevOps

Built for the last look

Everything a designer needs to judge a component, and nothing that slows a developer down.

One step in your Azure DevOps pipeline

Add the Looksgood step to your pipeline. It publishes only what the pull request changed, next to the version on your base branch.

An admin connects the project once with a personal access token, and the project settings show when it expires.

azure-pipelines.yml
- task: Bash@3
  displayName: Looksgood
  inputs:
    workingDirectory: looksgood
    targetType: inline
    script: |
      flutter pub get
      dart pub global activate looksgood_cli
      $HOME/.pub-cache/bin/looksgood push \
        --api-key "$(LOOKSGOOD_TOKEN)"

Ship components that look good.

Connect a repository, invite your designers, and the next pull request shows up in their inbox.

Open the app