Blog Engineering Designing for the modern developer
Published on January 24, 2017
3 min read

Designing for the modern developer

Recap and recording from our recent webcast featuring the GitLab user experience (UX) team


We're proud of how each team within the company delivers to make us better for every monthly release. Because GitLab spans the entire software development lifecycle, our UX team routinely tackles a series of unique creative challenges, which they discussed in depth in our recent webcast, "Designing for the Modern Developer."

UX Lead Allison Whilden and UX Researcher Sarah O'Donnell chat about how the team designs the interface, responds to feedback, and helps fit new features into our understanding of the needs of all users.

Watch the recording and get the highlights below.


How we make design decisions

At every stage, we carefully think through why decisions are made, and for whom. We have a number of methods that help us do this: research, testing, surveys, working with internal devs, and carrying on a constant conversation with our community.

Users of our own design

We’re pretty unique in that every day, we use our own product. This gives us an intimate understanding of how the software is used. It empowers us as users with opinions, and also forces us to be extra thoughtful about removing bias from our evaluation of the UX. We take seriously that we need to represent all opinions, not just our own. UX is about calculated decisions, not anyone’s idea about what they like best. We naturally adopt a sort of split brain when using the software and observing user behavior--we empathize both as users and technical experts.

How we work with Engineering and Product

Being a remote startup, we have a rather unique challenge of building a shared vision and perspective for UX while we are scattered across the world, and across features of the product. We’re working on this by documenting everything in our UX Guide, which you’re free to read through. More and more of the industry is becoming remote, so we’re excited to be experimenting with ways to stay connected. We believe that what we learn will be increasingly valuable to other companies. We navigate our relationship with the product team by understanding that they are both users & builders, too.

We're sensitive to different needs and work styles

We’re opinionated - we have a GitLab workflow, which we use at GitLab, the company, but we understand that not everyone works the way we do. Some of our company values, like extreme transparency, need to be made “optional” for users in other companies, for example when we think about how permissions work. We also build things that we ourselves don’t currently need.

How we balance feedback

In order to keep up with releases and deliver minimum viable change, we need to amplify some voices. When we have to prioritize, we address issues from our Enterprise customers first, then from our outside community, and then from developers on our team.

Our UX research interests

We want to build an understanding of who our users are and how they work. While we get a lot of great feedback from the community that is really helpful, we aren't always sure we are capturing the full range of our target users. We're developing personas that will allow us to relate to different types of users and subsequently predict their behavior. This is essential for our key challenge of creating a unified experience for teams big and small, so they can stay focused on their own goals.

You can learn more about this in our recent blog post!

Cover image: "sampa" by Hernani Arruda Monteiro da Silva is licensed under CC BY 2.0.

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert