Design

Welcome to design at Sourcegraph!

The design team exists to increase the value Sourcegraph delivers to its users. We achieve this objective through thoughtful discovery, inspired design, careful validation, and close collaboration with all manner of roles throughout the company.

We also seek to make it easier and more efficient to build Sourcegraph itself. Through the artifacts of our open process, we provide a forum where anyone in the company can provide valuable input that improves a project’s outcome before a single line of code is written.

Design Team

Product Design

Creative Ops / Brand

We’re hiring! Check out our open roles.

Design team ethos

We know that we’re successful as a design team when we…

  • Collaborate effectively across disciplines to ship and iterate on a great product experience. This means that we have a shared approach to the design process, that we build trust with each other and with our colleagues, and we consistently ship design solutions that solve product problems.
  • Feel empowered to act with high agency to make our product, processes, and teams better. Design is an inherently explorative and iterative process. We value high agency, and we have to actively create an environment of physiological safety, trust, and transparency.
  • Advocate for and ship design outcomes that align with our product design principles.
  • Improve Sourcegraph’s velocity by helping to ship more usable and delightful features in the first iteration. Design often means more time up-front, but this reduces time-consuming rewrites, refactors, and technical and design debt that occurs when changes are made during development or after releases.
  • Complete goals owned by our teams. We’re successful when each of us is able to complete our goals in a sustainable way, while also contributing to the design team culture and rituals.

How we work

As a design team, we’re constantly reflecting and improving on how we work.

Design principles

Our product design principles are how we express our shared vision and values while designing for our product. We co-created these principles with members of the design, product, and engineering teams.

Designing in the open

At Sourcegraph, we design in the open. This is an important part of how we work as a design team, and is a key part of how we apply our values to our work and thrive in our globally distributed, remote company.

Designing in the open means many things to us.

  • Our work and process is transparent by default. By making our work visible to anyone, it’s easy for us to collaborate with others while building trust within our high agency environment.
  • We share early and often. Our design process encourages collaboration with other teams at all stages of the product design process, and designing in the open reduces friction and encourages feedback and shared understanding.
  • We create shared understanding. We proactively communicate with teammates from all disciplines and backgrounds. We don’t use jargon and don’t expect others to have a deep design-specific understanding, and we look for gaps in understanding where we can help provide clarity.

Designing in the open is hard! As designers, it’s easy to want to hold back on sharing until we’re happy with what we have. It can be very uncomfortable for others to see the things we’re working on before we’re ready to share. But designing in the open also challenges us to improve our design communication and makes us better at collaborating asynchronously.

Design process

Product design at Sourcegraph is low-process and highly adaptive. Every project is a little bit different, but we usually follow the same general approach where cross-disciplinary project teams move together through Discovery and Delivery phases.

  • The Discovery phase provides space for the project team to collaborate on problem definition, research, ideation and experimentation, testing, and ultimately to converge on an outcome that the project team agrees to move forward into Delivery.

  • The Delivery phase is the tactical implementation of the outcome of the Discovery phase, usually by engineering, and results in shipping something that we can then measure and evaluate.

These discovery and delivery phases can be as large or as small as needed for the problem at hand. Often, the phases are implicit rather than clearly defined for smaller projects. The larger the effort, the more valuable it is to explicitly plan the activities that take place in each phase.

We avoid siloed work as much as possible. Instead of design and development phases, each discipline is involved end-to-end, and it’s likely that one discipline will be more involved than the others at different moments along the way. Similarly, we avoid hard handoffs as much as possible. When the Discovery phase is complete, every team member should have a deep understanding and agreement around what will move forward into Delivery and is responsible for shipping the project outcome.

Design project templates are used to help structure our efforts.

Process

Collaboration

Toolkit

Other