menu

Primer

For discussing Primer, Octicons, our style guide, and design systems at GitHub πŸ€–πŸŽ¨

Channels
Team

Open office hours - 09/14/18

September 14, 2018 at 3:35pm

Open office hours - 09/14/18

September 14, 2018 at 3:35pm

Chat to us about primer.style, primer react components, open roles on our team, and design systems at GitHub! We'll be online 2-3pm PT today!


September 14, 2018 at 9:20pm

Hey Diana & Team. I'm a big fan of Primer. Are there currently open roles on your team? I checked the jobs site a few times in the last few days but didn't find anything. :)

  • reply
  • like

Hey! Iβ€˜ve read some of the conversations from the previous office hours about your usage of figma. Could you elaborate more on your usage/organization of figma in a large org like github?

  • reply
  • like

I'm really into the React library, I'm curious to see how testing is setup and handled. What is the status of that currently?

  • reply
  • like

Hey Diana & Team. I'm a big fan of Primer. Are there currently open roles on your team? I checked the jobs site a few times in the last few days but didn't find anything. :)

Hey Kevin! We've got a Production Designer role up now: https://boards.greenhouse.io/github/jobs/1272610

  • reply
  • like
  • reply
  • like

Hello there design Systems team! I'm curious about 2 things. First, the adoption of a design system at a predominantly engineer and development based company. How did that come about? And what are the particular challenges of working on a design system team that is spread around the world (remote)?

  • reply
  • like

Hey! Iβ€˜ve read some of the conversations from the previous office hours about your usage of figma. Could you elaborate more on your usage/organization of figma in a large org like github?

Thanks for the question @halvves We currentkey use figma for a couple of things. The first is we have a GitHub team that our product designers use to explore and present designs to our teams. They have access to our design system as figma components, colors, and text styles. We also use figma as a vector illustrator and storage for our octicons SVG icons. Using figma’s API we export the icons and distributo them with npm and rubygems.

like-fill
1
  • reply
  • like

I'm really into the React library, I'm curious to see how testing is setup and handled. What is the status of that currently?

Hey Austin! Right now we're using Jest to test our components & we've set up quite a few test matchers and custom test utilities to help us with some of the unique needs we have for testing components using styled-system or Emotion. We use snapshot testing in some areas as well!

like-fill
1
  • reply
  • like

Hi Emily. I should have mentioned that I'm looking for a Product Design role. :) Ah yeah, just saw the internship, thanks. Is there a chance for an open role before summer 2019?

  • reply
  • like

What is it like to be a product designer at Github? How closely do designers work with engineers?

  • reply
  • like

Are there any problems with design systems at GitHub which just seem to be "un-fixable"?

like-fill
2
  • reply
  • like

Are there any mistakes your team has made in building out the team, system, and processes that you'd go back and fix if possible?

like-fill
1
  • reply
  • like

Hello there design Systems team! I'm curious about 2 things. First, the adoption of a design system at a predominantly engineer and development based company. How did that come about? And what are the particular challenges of working on a design system team that is spread around the world (remote)?

Hi Blair! Those are big questions. Hope this answers them!

1. Design systems are for engineers as well as designers so I think ensuring you build a design system that works for both should be a goal for any company. Design systems solve problems for engineers in terms of making it easier for them to implement UI. If a design system solves that problem then there is less likely to be a problem with adoption. While we could be called an eng heavy company, we have a strong and growing design team too. Engineers and designers collaborate closely together to ensure we build a great experience. Designers code at GitHub as well, I think that helps us make a design system that works well for engineers too. Our team also provide support to engineers by reviewing pull requests and making ourselves available to pair when needed. That all goes a long way to increasing adoption. Overall though we try and build systems that people want to use because it solves a problem, aka why wouldn't they use it?!

2. Our team makes remote work by regularly syncing up via video calls and async communication via slack, github issues and pull requests etc. We do a planning meaning every Monday at a time that works for everyone, a mid-week checkin, and a review meeting where we demo work each Friday. Team members often jump on a call and pair. We record important meetings too so that if folks can't make it they can watch it later. Finally we also do meet up in person when we can several times a year. I don't think it presents design systems teams any unique problems to just generally working remote though. We all enjoy the flexibility of the remote lifestyle and make an effort to be flexible and value written async communication to keep everyone in the loop.

  • reply
  • like

What is it like to be a product designer at Github? How closely do designers work with engineers?

Hey

@kelly-dern

product designers at GitHub are generally implanted in product on feature teams across the organization. Working closely with them to make design decisions. What is probably more unique is that, depending on the need, product designers will sometimes build and deploy their own designs to production. Across the product design organization, members will have weekly reviews to demo any new product designs to other designers for feedback.

like-fill
1
  • reply
  • like

Are there any problems with design systems at GitHub which just seem to be "un-fixable"?

Hey Kevin! This one isn't particularly unique to GitHub but I think one design systems problem that's challenging is that there doesn't quite seem to be a great method of keeping code + design tool components in sync. It would be really cool if one day there was a way to always make sure that a React component and the corresponding component in the design tool is up to date! I think what Figma is doing with the web platform and API is really exciting and might get us there one day!

  • reply
  • like

Hey Kevin! This one isn't particularly unique to GitHub but I think one design systems problem that's challenging is that there doesn't quite seem to be a great method of keeping code + design tool components in sync. It would be really cool if one day there was a way to always make sure that a React component and the corresponding component in the design tool is up to date! I think what Figma is doing with the web platform and API is really exciting and might get us there one day!

Yeah that would be perfect. But there's hope with all the changes (Sketch, Figma, Framer X) that are currently happening. But besides communication that's maybe not really needed due to lack of (or outdated) documentation it's good that engineers and designers still have to talk to each other. :)

  • reply
  • like

Hi Blair! Those are big questions. Hope this answers them!

1. Design systems are for engineers as well as designers so I think ensuring you build a design system that works for both should be a goal for any company. Design systems solve problems for engineers in terms of making it easier for them to implement UI. If a design system solves that problem then there is less likely to be a problem with adoption. While we could be called an eng heavy company, we have a strong and growing design team too. Engineers and designers collaborate closely together to ensure we build a great experience. Designers code at GitHub as well, I think that helps us make a design system that works well for engineers too. Our team also provide support to engineers by reviewing pull requests and making ourselves available to pair when needed. That all goes a long way to increasing adoption. Overall though we try and build systems that people want to use because it solves a problem, aka why wouldn't they use it?!

2. Our team makes remote work by regularly syncing up via video calls and async communication via slack, github issues and pull requests etc. We do a planning meaning every Monday at a time that works for everyone, a mid-week checkin, and a review meeting where we demo work each Friday. Team members often jump on a call and pair. We record important meetings too so that if folks can't make it they can watch it later. Finally we also do meet up in person when we can several times a year. I don't think it presents design systems teams any unique problems to just generally working remote though. We all enjoy the flexibility of the remote lifestyle and make an effort to be flexible and value written async communication to keep everyone in the loop.

Well done and thanks for the information. It sounds like communicating out from the team is a priority!

like-fill
1
  • reply
  • like

Remote opportunities seem like the future.

  • reply
  • like

Are there any mistakes your team has made in building out the team, system, and processes that you'd go back and fix if possible?

We've/I've made tons of mistakes! That's part of the course working on design systems (and software development) generally though. Design systems should be built for change, I think that helps us iterate on and fix things that were once a problem. I expect us to make mistakes, make wrong assumptions, or for something that was once right to become the wrong solution. With that in mind we try to break work up into small incremental ships, and test our solutions in GitHub.com (http://github.com/) or other environments that use Primer, and we lean towards choosing declarative solutions, or more verbose code rather than making strong assumptions and abstracting too much too early. In terms of specific mistakes on the system, our first iteration of our spacing scale was wrong, we initially had a 6px scale and it didn't work with the density of GitHub, and was too much of a departure from the previous 5/10px scale. It was challenging but not too terrible to update.

Re the team I think we've done a decent job of hiring the right folks at the right time. I'm glad we started off small and scrappy and didn't grow too quickly. I think the only thing I'd change is preparing the work required to hire people a bit earlier on so that we could have hired some roles quickly. Process wise, we keep iterating on that like we do the system itself. I think we're still figuring that out - at the moment we have regular planning meetings, checkins, and we've just started OKR planning and retrospectives - this all seem to be valuable but I expect us to tweak and improve the format and cadence over time.

like-fill
1
  • reply
  • like

Organically growing the team and processes seems to have been successful.

  • reply
  • like

Thanks everyone for joining us today, lots of great questions! Feel free to drop questions in our other conversations and we'll get back to you when we can :)

  • reply
  • like

September 16, 2018 at 1:45pm

Why did you choose this dark color for css?

  • reply
  • like
  • reply
  • like

If we do a google search for css and get to see this color for css.

  • reply
  • like
  • reply
  • like
private
This conversation has been locked