Design artifacts

In Sourcegraph’s globally distributed remote environment, design artifacts are crucial for sharing and collaborating on design and a key part of how we design in the open.

We use Figma files, RFCs, Google Docs, GitHub issues, and more as artifacts. Artifacts give us a way to capture our ideas and thoughts, and then give us time to go away and give thoughtful consideration before providing feedback.

Decisions are made in design artifacts. While we can talk about things in synchronous sessions like Slack conversations or video calls, making decisions in artifacts helps others to understand the context around the decision and provide further feedback or ask questions in a self-contained space.

When a design artifact like a Figma file is a source of truth, designers are responsible for communicating this to their teams and for keeping those artifacts up to date.

It’s our role as designers to set expectations around our artifacts: what state they’re at, whether or not we’re ready for feedback, and what kind of feedback we’re seeking. Seeking feedback is a skill we’re always working to improve.

As a design team, we’re low-process. We avoid making artifacts for the sake of making artifacts. Instead, we make artifacts when it makes sense to help us communicate and collaborate, and we optimize for clarity and understanding.

That’s also why we don’t always create high-fidelity design artifacts. Sometimes, a simple sketch in Excalidraw or on paper is all that’s needed to communicate and agree on what should be done. It’s up to the project team to decide what’s right for their problem and context.

Tips for better asynchronous design artifacts

  • Design artifacts should clearly communicate to the viewer what stage the artifact is in. Is it a working draft, that’s not ready for feedback? Is it an experiment, with no connection to a project effort? Is it ready for review and specific feedback from others? Is it a source of truth for development? Some ways this might be expressed include in the title of the artifact, the Figma project cover, or labels within the content.
  • Design artifacts ready for feedback should be tailored for asynchronous review. Figma files, for example, can communicate beyond the design itself: we can use annotations and other techniques to make assumptions tangible and visible in context, to specifically request feedback on a given topic, or to surface points of uncertainty.
  • Everyone learns best in different ways. When sharing design artifacts, consider adding extra ways of consuming the artifacts, such as a Loom video walkthrough of the artifact, or linking back and forth other documentation and artifacts.