GitHub’s Senior Director of Product Design on “How to Iterate Fast”

Lese diesen Artikel auf Deutsch.

The Product Design of the world’s largest developer platform is all about one thing: Getting user feedback as quickly as possible. In this article, you are going to hear from Senior Director of Product Design, Max Schoening, on how GitHub approaches this challenge.

• In this article you will learn
• how GitHub manages to collect user feedback quickly,
• how to achieve maximum knowledge gain in small steps,
• how GitHub’s product and design teams are structured,
• how the agile teams balance freedom and personal responsibility,
• why the remote work culture is so important at GitHub.

A new feature at GitHub sometimes starts pragmatically. A quick, hand-drawn sketch sent out on Twitter to a few followers may be enough for Max Schoening as the first version of a very simple prototype. Because to understand whether an idea is going in the right direction, it doesn’t have to be perfect, says Max during our conversation in GitHub’s headquarters in San Francisco. The important thing is to develop and improve it step by step. Max calls this process „incremental correctness.“ It is at the core of the company’s product design philosophy.

From Berlin to San Francisco

Generating new ideas and implementing them quickly and successfully became the pivotal point of Max’s career. For a first startup, a music platform á la Beatport, he taught himself programming. The product failed, but shortly afterwards Max starts his next project: CloudApp, a simple file sharing tool. There is less and less time for his graphic design studies in Berlin and eventually he quits. But then comes a call from the app developer platform Heroku, that is going to set Max’s life on a whole new path. CloudApp has now grown into one of the biggest apps on Heroku. The management of the platform is impressed, and Max moves to San Francisco to lead product design at Heroku for the next five years. One thing leads to another: At Heroku, Max meets Jason Warner, back then Head of Engineering at the app platform. In the meantime, Max had founded another startup with Canvas and – because, why wouldn’t you? – sold it to Google. It is Warner, now SVP of Engineering at GitHub, who eventually guides Max to the developer platform, where he is now responsible for product design as Senior Director.

Designing GitHub

With 36 million users, GitHub is one of the most popular platforms for developers. 1000 employees work for the company, which was acquired by Microsoft in 2018. Together with Shanku Niyogi, SVP of Product, and Jason Warner, SVP of Engineering, Max is part of the EPD leadership team. This division into engineering, product and design runs through all levels of GitHub’s technology org. Each EPD Squad is responsible for a specific area in which it works largely autonomously, for example Pull Requests, Issues or GitHub Desktop. Max describes his role at GitHub as follows: „My task is to work with my team to find solutions to our customers‘ problems and to design them in such a way that they are as intuitive and approachable as possible.”

GitHub’s look and CI is mainly taken care of by the Marketing Design team. The creative department is responsible for the logged-out experience of GitHub’s website, manages the brand identity, but also is creates all things relating to the Octocat. This includes the merchandise with the portrait of the iconic GitHub mascot. But the large bronze statue of the Octocat standing in the foyer of the company was also designed in-house. They are particularly proud of the animated short films debuted at various GitHub Universe conferences:

„We have illustrators who could work at Disney.“

The marketing designers are always called in for product design when GitHub’s CI has an impact on user experience.

Within product design, there is a third department called Design Infrastructure, that develops GitHub’s design system: „With a product like GitHub, it’s important that everything we do can be managed consistently and scales. You need a design system to do that. Ours is called Primer, it is available as open source on GitHub“, explains Max. Customer Research and platform wide user interfaces like navigation also belong to Design Infrastructure.

GitHub’s product designers are closely involved in product management and development in their EPD squads. Max explains: „All product designers write and publish code for our interfaces, in our case mainly HTML, CSS and so on. But they’re working closely with the product managers in the ideation phase. We strongly believe in the double-shaped diamond of discovery and delivery. Our designers are involved throughout the process, help to identify the problem, find the solution and implement it. Because we have such talented people, we don’t separate disciplines like UX design, UI design or front end development.“

Achieving Incremental Correctness

The most important principle in the development process of GitHub is incremental correctness. “Basically, this is the GitHub way of saying: Iterate fast,“ explains Max. Here are four takeaways from GitHub’s design principle, that make it possible to quickly evolve from one version to the next.

#1 Optimize for time to first user contact

At the beginning of a new feature at GitHub is the user. The task of product management is to identify the user’s problems. GitHub works with “Personas” in order to do that. The product managers talk to the appropriate customers to find out where they have a hard time on the platform or how to add value to their experience. Max gives an example: „Recently we launched a feature called Suggested Changes. Sometimes you’re on a pull request and just want to make a suggestion in the sense of: ‘Hey, how about we do it that way?’ And then you write a line of code for it. Talking to customers revealed: The loop to suggest a change in a pull request was much too big, because you had to open another pull request to do it.“ The obvious idea: Couldn’t you just do it like Google Docs, where users can make such suggestions directly inline?

At this point, the design team steps into action: What should a version of this feature look like that we can show the customer as quickly as possible? Max explains, what this approach means in practice: “Depending on the complexity, the first draft can be a sharpie sketch, that we take to Twitter and show it to a few followers we know. That’s enough to get a first impression of what our users think.“ If more detailed feedback is needed, product designers can invite people to video meetings via Zoom and show designs via screen sharing. One thing in this process works very much to the advantage of Max and his team, of course:

„Our users love giving feedback because they love the product so much. We never have a problem finding users, we just have to ask them.“

But no matter how the feedback is gathered: What’s important is that the process is fast and delivers results that help designers move on to the next iteration.

#2 Learn twice as much in half the time

What Max wants to avoid – the more complex designs become, the more time it takes to get feedback. Thus, it would take longer to get to the next version with every iteration. What you want to do is the exact opposite: The goal should be to learn more about the users even faster with each step. To make this equation work, you can influence two variables. Either, Max explains, you improve the degree of fidelity of the prototype. Or you increase the number of users to test, whether there is additional feedback from other user groups for a prototype. The important thing is to progress with small steps, says Max: „Whenever we feel we need to make a really big decision, our process is not finely tuned enough. It should never feel like jumping off a cliff. This situation can be avoided by dividing the process into smaller and smaller steps.“

#3 Gradual improvements instead of big steps

The decisive factor for fidelity is the balance between effort and results. The team has to gradually increase complexity, so that it can validate new user assumptions without disproportionate effort.

The GitHub designers use tools like Keynote or Figma in this phase to improve the prototypes, but they do have a lot of freedom. „Incremental Correctness“ means that in every phase, the things that are important have to work, says Max: „The tools are not that important. The user story has to be right. Of course, a sketch will never show what the finished interface will later show. It’s important to have just enough material to validate the assumptions you have at this point.“ He compares this process with a film production: „You start with an idea that looks more like a short comic strip. With each step you add more images to the story, thus increasing the framerate. The final product would be an 8k film in 60 frames per second. But you get there gradually.“

Translate this into product design, this means: What starts with a sharpie sketch, evolves into a clickable Figma prototype, and at some point the first lines of code are actually written. But even then, Max does not aim for perfection. „The code in the first version doesn’t even have to be scalable. On GitHub, we can use a feature flagging system to give certain features to a handful of users and let them work with it,“ Max explains and adds with a wink: „If we then take the feature away from these users and they all start to yell about it, then we know it’s a very good feature.“ But to be really sure, it’s not enough to just test with a few dozen users.

#4 If the feedback stays the same, increase the test audience

Even if the number of users who should try a new feature is increased, GitHub proceeds step by step. Usually it starts with a handful of users before it goes on to a few dozen, then a hundred and eventually a couple of thousands of users. The goal is to work with the feedback of a user group until you don’t get any new feedback. In concrete terms, this means that users give critical feedback to certain feature, hen the team will work with the same size of users until:

1. a) either it has become clear to the users why the feature is built the way it is, or
2. b) it is improved until there is no additional feedback.

This is the right moment to enlarge the target group and test whether the type of feedback changes with more users. This process repeats itself until you are at the point of a „GA-Release“, i.e. General Availability. This is the moment when GitHub will have a feature available to all 36 million users.

The Right Balance of Freedom vs. Responsibility

The role of senior management in this process is to strike the right balance between freedom and accountability. „What we don’t want is for every decision to go up and down the entire organisation, otherwise we wouldn’t be very agile,“ says Max. At the same time: „We have to make sure that teams are aligned.“ In practice, this means, for example, that the teams can make decisions freely about their sprint cycles, which usually last one to three weeks.

„We don’t like to talk about sprints, but rather about cycles. Sprints sort of imply that you try to run very fast, and not everyone likes this idea.“

To establish accountability, before each cycle, teams define what they want to achieve and how they want to measure whether the goal has been achieved.

Visualize the user story with videos

At the end of the sprint, the teams present their results to the EPD management. Max says: „We want the teams to tell the user story and show us in a demo what the user can do now. It’s less important to show that you have ticked off every box.” What the presentation looks like, however, is left to the teams, there are few guidelines. This gives the teams the opportunity to become creative and to set additional small incentives for the team members. Max tells us about a team that has been creating a new video for these sprint reviews every week for six months now. More effort, but it pays off: „It’s a team that works well and delivers reliably. This shows, how the mechanism of freedom and accountability works.“

These reviews are important because they provide the teams with the right context for their work. Usually each EPD squad presents their results to the senior product management of GitHub. The task of the leadership team, however, is not to decide which feature will be released and which team will have to return to the whiteboard. „Typically, a lot of questions are asked in these meetings. In the ideal situation, every question begins with: How might we…?”, Max explains, „. ‘How might we increase sign ups or how might we get users to use a feature?’” With these questions in the bag, the team is able to define and prioritize its further tasks.

Keeping the context firm but challenging

The management’s responsibility lies in providing the right context for the teams, says Max: „You can imagine it as a box, in which the teams can move freely. If this box is moved back and forth too much, the teams constantly hit a wall. And that’s bad. What we want is for the teams to have a lot of freedom of movement. But the context for the team should always be a little too big so that the team feels challenged and they feel that they can develop further.“

Max describes his role in this process as follows: „I try to help my team make as many of their own decisions as possible.“ It is crucial to him to steer communication between the teams in the right direction. „I compare my task with the people who sat at those huge switchboards in telephone exchanges in the sixties and connected the conversations with each other. I have to make sure that the teams that should talk to each other, really come together, so that they can make better decisions.“

Working Remote at GitHub

This is all the more true as remote work is part of GitHub’s DNA: About a third of the 1,000 employees do not come into the headquarters on Brannan Street in San Francisco every morning. This is a big challenge for design especially, because many processes start with people coming together in a room and sketching ideas on a whiteboard. „No startup has managed to replicate this perfectly yet,“ Max says with a sigh. Real-time collaboration tools for designers such as Figma, screen sharing via Zoom or iPads, on which you can scribble, help to simulate processes that would otherwise take place on site.

„Software changes the world and no one should be forced to move to San Francisco, if they want to be a part of that.“

Despite the difficulties, Max believes remote work is an essential part of the GitHub philosophy: „GitHub is probably the largest maker community on this planet, enabling people sitting on the other side of the world to work together on projects. That’s why it’s so important and great that people from all over the world work together at GitHub itself“

This conversation with Max Schoening took place in 2019 on March 18th in GitHub’s headquarters in San Francisco. Moritz Meyer and Stefan Vosskötter talked to Max.

Photos: Thomas Riedel