The role of the product design team is to make validated decisions that enhance the user experience of Sourcegraph.
Here are a few of the things we strive to make true:
- Advocate for our users by collaborating with them
- Perform our due diligence when making design decisions, by researching and testing solutions within scope
- Proactive, with a bias towards action
- Communicate openly, and solicit feedback frequently
- To be egoless when soliciting responses to our work
- #design channel or @design-team on Slack
Working with design should feel fluid, you should be able to open an issue or bring up a concern in Slack, and receive actionable feedback: either implementable, or a call to explore further.
You should also not feel limited to words, images (sketches, or references made by editing the browser DOM) are also encouraged.
The Design Team uses a GitHub project board for managing current and future work, design debt, and work requests.
Columns:
- Design debt - issues connected to design debt that haven't been scheduled yet
- Backlog - issues that need design work but don't have any development resources allocated and haven't been scheduled yet
- Coming soon - no designer assigned yet, development resources have been allocated. Add design deadline to the issue, if possible
- Up next - designer assigned, design work scheduled
- In progress - design work actively being worked on
- QA - design work done, designer is assisting the implementation
- Measure success - design shipped, designer is working with the BizOps team to analyze the impact
- Done - success measured, all work completed to scope
needs-design: design work requests. Add to Design priorities project and if possible add a deadline.design: design-oriented issues. This label should be mostly used by designersdesign-debt: issues connected to design debt.
If you need some design help:
- Add the
needs-designtag to your GitHub issue - Assign one of the designers if you know who will take care of the issue
- Add your issue to the design priorities project
Please clarify the urgency of the issue (adding a known deadline is encouraged) and if development resources have been allocated. It is important to focus the design team's attention on the work that can be implemented soon.
Use the #design Slack channel for any urgent matters or questions.
Sourcegraph ships. It has achieved product-market fit by hiring customer-focused employees, being truly agile in how it designs and develops features and by putting product in user’s hands and collecting feedback and usage metrics.
Design will support this key factor in Sourcegraph's success by introducing a lean experience design process.
While design does adds time at the beginning of a project, it improves velocity in aggregate by helping ship more usable and delightful features in the first iteration. The assets generated by designers provide sales, engineers and stakeholders with the ability to test and modify a solution long before it is engineered. This trait improves engineering velocity by reducing time-consuming rewrites, refactors and technical debt associated with changes made during development or after releases.
Our design process is documented here: Design process
The process of designing for the Sourcegraph application has some special considerations. To help maintain consistency and reduce subjectivity we are documenting these items in our design and interaction guidelines.
Rules that help us make decisions in crucial moments of the design process.
- Always design with the advanced user in mind
Our users are developers who are accustomed to using complex interfaces. They are more knowledgeable and need less guidance than regular web users. They also have higher expectations and are less forgiving. We should aim to provide complex but comprehensive interfaces created for users with domain knowledge (examples to follow: Autodesk, Netlify, Vercel, Autocad, Blender, Maya, Unity, Photoshop, Indesign).
- Consider familiar patterns first
Whenever possible, use well-known patterns from products our users spend a lot of time in, like IDEs, code hosts, or other developer tools.
- Don't hesitate to innovate but remember to onboard
Sourcegraph offers a unique product so repeating the known patterns will often not be enough. If you came up with a custom solution that can take the experience to the next level, don’t hesitate to implement it. In those cases, remember to onboard the user. Show them how things work and trust them to follow. If necessary, provide additional docs. Onboarding should be treated as an element of the innovation, not as an afterthought.
- Strive for visual excellence
People are visual creatures. That remains true for our technical audience as well. Sourcegraph interface should feel pleasing, not overwhelming, and natural to use.
- Design today with the future in mind
Sourcegraph is growing at an extraordinary pace. Our designs need to be flexible enough to accommodate changes and improvements. Always choose the solutions that work today but can be easily adapted for the future development. Think in systems, not in screens. Our goal is to redesign as little as possible so our users do not have to adjust to frequent changes.
- Manage complexity
We need to handle the unavoidable complexity of our product. Our users should see Sourcegraph as a powerful and intuitive tool. Aim to remove obstacles and unnecessary elements from both flows and interfaces. Use just-in-time knowledge and contextual help to educate and empower. Enable shortcuts and customizations, especially for technical users accustomed to using keyboard navigation. Make it simple, not simplistic - simple things can be complex but easy to understand. Don't overlook the details by treating the problem with false simplicity.
- Click 'C' whilst in Figma, or check the navigation bar in the top left hand corner and look for the comment icon; you can drop comments anywhere in a file, and the owner of the page will be notified via email
Our internal resources are open, and the design team will welcome any feedback. Hesitating to leave feedback can block discussion, and stretch out time between brainstorming and action.
As the procut design team is still small and not able to address every problem efficiently, we have tried to simplify Jakob Nielsen's 10 general principles for interaction design. These principles are often referenced, and by referencing them yourself you can make better user experience decisions.
- Make sure the user is always appropriately informed.
- Use familiar language.
- Follow real-world conventions when ordering things.
- Make sure exits are available.
- Follow platform conventions, search online to check established UX patterns.
If you would like to dig a little deeper here is a link to the article, each section is accompanied by a short video and/or a more in depth article.