Design at Sentry

Designing Rollback: A Year in the Life

Wed, 26 Mar 2025 00:00:00 GMT

Hackweek 2024

Initially pitched as Sentry Wrapped, Rollback began last August as a Hackweek Project. We figured an app built on data must have something to say with it.

Because Hackweek is just 5 days, with teams made of up of employees from across the company, the product/design split blurs. Due to the short timeline I knew it was important to make key decisions early and lock in our visual direction and shape of the product. A longer timeline gives you time to iterate, experiment, and refine, but if you only have a week you have to make educated choices and not look back.

Some important early choices were:

Rollback would be desktop only
It would be navigated via vertical scroll
It would use a simple but clearly defined design system

The Thursday before Hackweek offically began we came into our first meeting of designers, PMs, and engineers with a simple wireframe and a bunch of questions — What stats are interesting? What do we have access to? Can we create new comparisons and create new context (”You had 29 hours of replays logged. That’s like watching Inception 11.75 times”)? As a group we made additional important decisions:

Stats would be individual level but we’d include some about the org
Rollback is for free & paid users
It should be 50/50 split of fun and useful information

To set us up for success I made two quick and dirty visual direction proposals to discuss with the rest of the design team. I approached it as a fun opportunity for Sentry (and for me!) to do visual design outside of our established system. The colors were pulled from the bright new illustrations the creative team, Studio 404, has been releasing, but was otherwise untethered to brand identity. One proposal involved a 3D illustration motif, the other a black and neon color block style. The rest of the designers were immediately drawn towards the neon blocks, so the choice was easy.

I built out a quick style guide and mood board, and over the weekend our illustrator, Drew, expanded on my ideas, introducing a some creatures built around the triangle of our logo. I loved them immediately and was excited to see how they would work in the UI. I also brought in some additional inspiration (they made me think of medieval illustration of many-eyed angels). Based on this feedback Drew was able to split off and iterate independently on his creatures.

At this point the pre-work was done and Hackweek was in full swing. We met with the PM and engineers and refined our initial wireframes. We started shaping a story — Rollback would move from org level stats to increasingly personalized pages, ending in a sharable summary card.

From there the engineers started bulling data and building out the foundation of the site. The mini-design team started pumping out pages, one designer working on the site’s animated landing page, while I got to work on the site’s content. Because we had so little time we stuck to a clear formula. Each page would…

be about one type of data
be a different color pulled from our palette
use one font family from Grilli Type
have a distinct type of interaction, either on click, hover, or scroll

Our illustrator had created a looping animated background that I was able to incorporate, as well as a repeating triangle motif inspired by our logo, and I used those everywhere. I wanted the pages to feel fun and a little freaky.

The process was extremely collaborative, designers looking at and modifying each other’s screens, engineers updating their queries to match the data we thought would look best on the page, our copywriter naming distinct personality types which would influence both the designs and the data.

And just like the week was almost over. We had to lock the designs so the engineers could have time to finish building the site.

Our final Hackweek Rollback was a big success. Accessible only to Sentry employees, the team loved it, and we won the award for best overall Hackweek project. I got to feel proud of some more out-there visual design and enjoy a week away from my normal UX work.

Rollback 2024

Everyone on the team was happy with how our Hackweek project had gone, and the greater company response was overwhelmingly positive. Still, it wasn't until early Fall that we got the official go-ahead to turn our little project into a real product our hundreds of thousands of users could interact with.

The legal team and our backend engineers determined it was doable at scale, and we made a timeline that broke everything down into about 6 weeks of work. In order to meet an early December deadline we would need to proceed with more or less the same stats and design as before. Luckily I still was given 2 weeks until everything was locked in, and so used that time to do some refinement.

My two main focus areas were responsiveness (and mobile!) and creating a summary page for users to share out their Rollback, which was cut from the Hackweek project. But with the extra time I was able to do a bit more — I audited the pages and consolidated fonts so everything felt more streamlined and intentional. I shifted all the colors to match the official Studio 404 palette instead of my approximation. I added in a new page about viewing habits, as well as an interstitial telling users to turn on their microphones to hear an original song. I made our zero states more fun. We added a personality type (THE BABY) to give new users a bit of inspiration. I swapped out white backgrounds for color where I could. Everything looked pretty similar to before, and nothing about the underlying design system had fundamentally changed, but now Rollback was polished up and ready for the wider public.

Rollback launched in December and is now offline for the rest of the year, but if there's anything you want summarized for next year reach out.

Credits

Design: Ivy Sanders Schneider & Vu Luong

Illustration: Drew Lytle

Copywriting: Maddie Ritchie

Creative Direction: Ben Bellayto

Project Management: Rachel Wang & Dhrumil Parekh

Designing Dammit Sans: A Hack Week Typeface

Wed, 26 Feb 2025 00:00:00 GMT

We all know the drill. Hack Week. Experiment. Try stuff. You get it. I love the promise of a Hack Week: a time-boxed challenge to create something useful without overthinking it. This time, because I sit on the design team, I decided I wanted to try and make a typeface. I knew I wanted at least a full alphabet to write things with, so my initial goal was simple—design a bold, all-caps header font that could pair well with our brand type, Rubik. Boom, Hack Week. Let’s go.

Finding the Right Inspiration

Before this, the closest I had come to creating a full typeface was a pixel font I made a few years back, which had been guided by a very strict limitation: pixels. So in a search for some direction with the possibilities of bezier curves, I spent a while looking through a lot of great sans-serif typefaces. Obviously, there was Rubik, which is slightly square-ish and has rounded corners. But I wanted to mash our reliable brand type up with something else. I looked for something readable but with an underlying personality. I wanted something with a helpful confidence. The voice of someone who could show you the way and not be pretentious about it.

One that really stood out for me here was Lexend. It was extremely readable even at small sizes and had a certain charm. It was sharp but ultimately just wanted to help you understand, and that felt right. I also personally loved the barred capital “I”.

Probably the most important piece of inspiration and guidance came as a short zine, Some Tips on Drawing Type, by James Edmonson at Oh no Type Co. This short book was focused enough for me to remember the tips for each letter and feel confident that I was avoiding big-no-no mistakes while keeping up my momentum. I didn’t stop to doubt myself (too often) because I felt I at least had the core of what I needed right. At least right enough to impress a few coworkers (hopefully).

From Hack Week to a Usable Font

Once I got going, I was surprised how much I was able to get done in these few days. The time crunch really did its magic and forced me to keep zooming out and moving rather than obsess over one letter. By the end of Hack Week, I had a full set of uppercase and lowercase letters, along with some basic punctuation. It was pretty thrilling to be able to start typing full sentences with letters I had drawn. For a while the font was simply known as “Hack Week Sans” but by the end of the week, I had given it a proper name; Dammit Sans.

I will admit, I did spend some time trying to give the letters rounded corners on some of the notches. I was hoping to give Dammit Sans something extra unique yet still subtle, something tied to the rounded corners of Rubik, but ultimately it just felt distracting and like it was trying too hard. Slowly, one by one, I let them go. I even left just the one, final rounded corner on the capital “Q” for a while before finally removing them completely.

After Hack Week, I purchased the full version of the font software I was using (Glyphs), continued to refine letters (big thank you to the Speed Punk plugin), and expanded the character set, making it somewhat more useful. Today (Feb 2025), we use Dammit Sans as a display font on our merch store site.

What’s Next?

Maybe one day we’ll expand it—add weights, italics, and more refinements. Maybe next Hack Week. But for now, Dammit Sans is out in the world, doing exactly what it was designed to do: being the font we convinced leadership to let us ship.

Codecov Year in Review

Sat, 14 Dec 2024 00:00:00 GMT

As a designer in software, I’ve always admired how architects can see their designs realized in physical form—a tangible manifestation of their vision. But I don’t envy their mistakes, which stand out for years or require costly reconstruction. In contrast, in software, shipping something imperfect is a badge of honor—it provides the feedback we need to iterate, pivot, refine, or roll back quickly.

Given the iterative nature of software development—where your designs are constantly evolving with every sprint—it’s easy to look back and ask: “What was I thinking?” and "What did I get done? What went well/poorly?" That’s why I carve out time each quarter and year to reflect: documenting what we’ve accomplished, the decisions we made, the questions raised, what worked well, and where we can improve—all while seeking input from the team.

This review focuses on product and design-related changes—it doesn’t cover the incredible behind-the-scenes engineering work, like maintenance, bug fixes, or marketing efforts that help bring everything together.

Value People

Moving into 2024, as our team expanded, and as our product UX needed maturing, we needed someone to help scale our growing product design function. In December 2023, about a year ago today, Adalene Teh joined our product design team, bringing her expertise from Amazon (AWS).

Adalene hit the ground running, quickly grasping the complexities of our product. What set her apart, though, was her collaborative approach to learning. She organized sessions and workshops with the team, using them not just to gain knowledge but to ask insightful questions that prompted the entire team to reflect and uncover previously overlooked insights. Together, we worked closely to iterate on and establish processes that could scale and better support our counterparts.

A year later, her contributions to new feature development and iterations are too numerous to list. However, what I admire most is her relentless curiosity and pursuit to deeply understand things—and then her drive to take action. Given her impact—I can’t believe it’s only been a year!

Work In Progress

In 2024, we focused on two main themes: 1) core product improvements, and 2) going beyond coverage. These priorities often competed for attention, but through a game of Tetris each sprint and quarter—here’s where we landed:

Pixels Matter: Core Product Improvements

If you’ve ever been part of a migration or redesign, you know the mention of “front-end migration” can send developers running for the hills. While we completed our front-end migration nearly two years ago, the process left us with lingering debt: cut features, polishing needs, copy fixes—all the loose ends. On top of that, we faced a growing backlog of product improvements that had been deprioritized during the migration. Here's some of the larger items and themes:

Experimenting with PR comment formats to simplify reports
Improved debuggability with our uploads/coverage processing history
Navigation updates to accommodate new feature experimentation
Configuration management at repo level
Aligning copy across the UI and documentation
Fixing behavior issues, like handling removed code
Making Codecov more open-source-friendly (uploads without tokens)
Improving onboarding and simplifying the GitHub app installation process to reduce friction for new users (and discovery around providing value without requirement of GitHub app)
Pricing updates, including the introduction of a team plan for smaller teams
Dark mode
OKTA integration to support customer onboarding
Slack integration
VS Code extension (with highlighting)
Last, but not least: browser extension

These efforts not only resolved migration debt but also laid the foundation for a best-in-class product that customers can trust and love. We achieved these foundational improvements while simultaneously delivering entirely new products…

For Every Developer: Going Beyond Coverage

Our core mission remains helping developers write better code with less risk, but in 2024 we expanded our offerings beyond testing coverage to support a broader range of developer needs. Here’s a breakdown of our progress:

Bundle Analysis: our first venture outside the realm of testing, helping front-end developers understand and optimize their bundle size.

Current status: adopted by 252 organizations. Working on enhancing data actionability to guide developers toward performance improvements.
Tradeoff review: while supporting JavaScript-related issues aligned with our strategy, this experimental product feels distinct from testing-related features. We’re asking, “What does success look like, and how does it fit into the pre-release story?” Another notable, is that in our latest iterations, large code changes / bundle gates, there is a performance aspect to this – some exploration needed, but could be a another opportunity for a Sentry integration.

Test Analytics: building on our testing suite, this feature provides insights into frequently failing tests, flaky tests, and framework health.

Current status: adopted by 703 organizations, making it our fastest-growing experimental feature. We’re doubling down in this direction, as it aligns strongly with customer needs for helping them understand test quality.
Tradeoff review: while extending testing relationships makes this path clear, it raises questions about how we prioritize improvements versus other experimental features. One example of this is automated test selection, a concept we shelved for the time being due to its time constraint and technical challenges.

AI Review: helping developers generate tests for uncovered code and reviewing code changes with actionable suggestions before merging.

Current status: Adopted by 157 organizations in a short time, providing feedback directly in the PR comment. While the early adopters are promising, at the moment it’s in BETA and very experimental. Looking to get a sense of its accuracy improvement in the wild.
Tradeoff review: the AI space is very competitive and evolving rapidly, however Codecov’s existing integration into developer workflows gives us a unique advantage. While results aren’t always perfect, the feature saves time by offering a strong starting draft.

Looking back, we started 2024 with a rough idea of “pre-release beyond coverage” and ended with a solid foundation for a suite of tools that integrate seamlessly into existing workflows. These tools leverage our core UX: 1) reporting in pull request comments, and 2) providing insights into code quality via the UI; while it broadens the scope of reporting for our customers

Work In Progress: Next Up in 2025

Reflecting on 2024, our focus was broad—improving the core product while casting a wide net with new features. In 2025, our theme shifts to going deep and expanding on these efforts.

Core Product Improvements

One core challenge has been how we process and display coverage reports. Currently, users may encounter incomplete or processing reports, leading to confusion, support tickets, and feedback that “Codecov is broken.” In 2025, we aim to address this by better contextualizing report statuses and ensuring only confirmed, accurate results are displayed—maintaining trust in our reports.

New Feature Development

For the new features launched in 2024—bundle analysis, test analytics, and AI review—2025 will be about observation, review, and tough questions. Early traction suggests test analytics is a standout, aligning closely with our existing offerings and appealing to a broad audience. Identifying flaky and failing tests resonates across teams, from startups to large enterprises, whereas coverage reporting often has more appeal to mid-to-large organizations.

Ongoing Discovery and Integration with Sentry

Sentry is the go-to debugging tool for developers. With this in mind, we’re exploring ways to support developers earlier in their workflow to help prevent errors before they occur. This includes researching pre-release workflows and identifying points where we can proactively assist developers in avoiding errors altogether.

In parallel, we’ll revisit our existing Sentry integration to revisit/enhance its UX and increase visibility for features like test analytics. By embedding these capabilities into key Sentry touchpoints, we can introduce Codecov’s features (such as test analytics) to a broader audience who may not yet use our platform.

Lastly, In late 2024 Adalene and I officially transitioned to the Sentry Design team, moving from reporting within Codecov engineering. This structural change reflects our growing collaboration with the wider Sentry teams and our commitment to building features directly under its umbrella. I’m excited about the opportunities these integrations present to better serve developers in the pre-release and error prevention spaces.

Feedback is priceless

At Sentry, we know feedback is priceless, therefore here is a rough recap of feedback we received across surveys regarding our product (Pro and Team plan) AND internal feedback from the team.

Paying Customer Survey Results: Codecov Pro Plan

Roles in Organizations

Responses:
- 56.7%: Developer
- 20.9%: Engineering Manager
- Remaining roles included QA Engineers, CTOs, Platform Engineers, and other technical leadership roles.

Ease of Setup

Responses:
- 60.7%: Somewhat easy
- 16.4%: Very easy
- 21.3%: Somewhat difficult
- 1.6%: Very difficult
Challenges Encountered:
- "Really hard to figure out how to add more team members and get comments added to their PRs."
- "The documentation feels disorganized, especially for configuration options like Component vs Flag."
- "Repo syncing is slow, and API changes break integrations."
- "Monorepo support required more effort than single repositories."
- "Login issues from GitHub links leading to 404 pages are frustrating."

Testing Prioritization

Responses:
- 80.0%: Essential – It's a core part of our development process.
- 13.8%: Important – We test when possible, but it's not the top priority.
- 6.2%: Moderate – Testing happens where necessary, but not heavily focused.

Code Coverage Prioritization

Responses:
- 40.9%: Essential – It's a core part of our development process.
- 31.8%: Important – Actively maintained but not top priority.
- 24.2%: Moderate – Used as needed but not heavily focused.
- 3.1%: Limited – Minimal focus on code coverage.

Pain Points in Code Coverage and Testing

Recurring Themes:
- Integration Challenges: "Getting coverage reports for monorepos or specific setups like Cypress was difficult."
- Login Issues: "GitHub links leading to 404 pages when not logged in is a major pain point."
- Unreliable Metrics: "Coverage regressions reported for untouched code or dependency updates are confusing."
- Flaky Reporting: "CI upload delays and intermittent failures disrupt the workflow."
Direct Quotes:
- "Coverage doesn't update sometimes. ATS misses changes."
- "The report shows only files involved in tests. If a large part of the code is not covered, it is not visible in the report."
- "The login strategy is frustrating; I can't log in directly from a 404 page."
- "Identifying flaky tests in Go is a challenge that Codecov is helping us address."

Usefulness of Coverage Insights

Responses:
- 41.5%: Moderately helpful
- 38.5%: Very helpful
- 10.8%: Extremely helpful
- 9.2%: Not helpful
Examples of Impact:
- "Integration with GitHub PRs provides visibility into coverage drops before merging."
- "Coverage insights helped us grow our coverage from 68% to over 80% without a big upfront effort."
- "Dead code identification through indirect changes is a valuable feature."
- "Knowing what's covered gives us confidence when deploying."

Overall Satisfaction with the Pro Plan

Responses:
- 64.1%: Satisfied
- 21.9%: Very satisfied
- 14.0%: Unsatisfied
- 6.3%: Very unsatisfied

Additional Feedback

Positive Notes:
- "Coverage reports help enforce quality without being onerous."
- "The pull request integration is central to our workflow."
- "We've seen cultural change toward prioritizing testing and quality."
Suggestions for Improvement:
- "Fix login issues, especially links leading to 404 errors."
- "Improve monorepo support and documentation for complex setups."
- "Provide clearer insights and a dashboard to track overall coverage trends."
- "Make the UI more stable and intuitive, especially for navigating reports."
- "Lower pricing for smaller teams or offer more tailored plans for SMBs."

Internal Feedback

This includes results from an internal survey from teammates across various functions about the product and design team. The goal was to understand how well our processes, communication, and priorities are supporting the broader team and where we can improve. Here are the results:

Visibility Into Discovery and Design Work

Responses:
- 54.5%: Yes, I feel I have good visibility.
- 45.5%: Somewhat, but I would like more context.
- 0%: No, I feel there is limited visibility.
General:
- "I feel like I have good visibility into active design/product work and have an avenue to provide feedback when I want to."
- "I'm not sure if I need more visibility of design. I have pretty good product visibility."
Areas for Improvement:
- "I'd be interested in learning more about how customer feedback are aggregated and translated to longer-term projects."
- "I'm not sure where to look for the next possible projects that are in discovery/design."
- "Maybe present mockups and solicit feedback in a wider audience?"
- "Some form of dashboard (for example, GitHub projects with the right filters)."

Understanding Design Iterations

Responses:
- 9.1%: Yes, I always understand the reasons behind changes.
- 63.6%: Sometimes, but additional context would help.
- 27.3%: No, I often don’t understand the reasons.
General:
- "The process seems to work mostly well from my (engineer) perspective at this point."
Areas for Improvement:
- "I like it when designs have a little concise description of the problem and solution. I don't want to have to go dig through the discussion on an issue just to get the little bit of basic context I'm looking for. That said, I do understand sometimes there is more than a little bit of context required (the appless designs, for example)."
- "How does an issue tie in with the company long-term strategy? vs 'we're building this because customer BigMoney asked for it and it makes sense in the product.'"

Clarity of Prioritization

Responses:
- 45.5%: Yes, the prioritization process is clear.
- 54.5%: Somewhat, but it could be clearer.
- 0%: No, the process is unclear.
General:
- "Prioritization seems to balance features with customer needs reasonably well."
Areas for Improvement:
- "There have been instances where we prioritized the wording of errors without fixing the underlying bugs causing them first. While I appreciated the cleared messaging, the error should not have existed in the first place and it caused a poorer customer experience for customers trying to onboard, and the customer-facing teams assisting them."
- "The balance between building something new vs polishing what we have is a bit fuzzy and has to be explained more."
- "I would love to WSLR framework similar to product that I could see prioritized on quarterly basis."

Channels for Sharing Suggestions

Responses:
- 63.6%: Yes, I know where and how to share suggestions.
- 36.4%: Somewhat, but I’m unsure of the best channels.
- 0%: No, I don’t know where or how to share suggestions.
General:
- "I feel like I know where and how to provide feedback and see it incorporated when appropriate."
Areas for Improvement:
- "Need one centralized place to raise issues, currently I know of two: Figma comments and Slack design channel threads."

Effectiveness of Addressing Issues

Responses:
- 54.5%: Yes, I feel my issues are heard and addressed.
- 36.4%: Sometimes, but not consistently.
- 0%: No, I don’t feel my issues are heard or addressed.
- 9.1%: I have not raised any issues.
General:
- "IMO the process seems to work mostly well from my (engineer) perspective at this point. I feel like I have good visibility into active design/product work and have an avenue to provide feedback when I want to."
Areas for Improvement:
- "There have been instances from design side where the broader team was asked for feedback, the feedback was consistent, but it was ignored."

Understanding Vision and Direction

Responses:
- 45.5%: Yes, I understand the vision and direction clearly.
- 54.5%: Somewhat, but I would like more clarity.
- 0%: No, I don’t understand the vision or direction.
General:
- "The overall vision is clear, and quarterly priorities are generally well communicated."
Areas for Improvement:
- "There's been this debate about 'is codecov for enterprise or self-served?' and it's not clear for me the features that align more with one or the other, or why we would prioritize one over the other (sometimes you can appeal to both, but not always)."
- "It might be good to know in which stage certain features and ideas are. Is it just an idea? Do we know there is (paying) customer demand for this? How do we know?"

Additional Feedback

General:
- "Looking forward to a successful 2025!"
- "Get deeper and deeper in with Sentry design. Let's get features in the Sentry UI."
- "IMO the process seems to work mostly well from my (engineer) perspective at this point. I feel like I have good visibility into active design/product work and have an avenue to provide feedback when I want to."
Areas for Improvement:
- "We need a better process around 'un-shipping' features. It feels like there have been a couple of experimental features, or features purpose-built for single customers which are not widely adopted. Those features seem to be in 'limbo' and are lacking a clear decision of either 'yes, this is a great feature that provides value, we will double down on it and polish it up,' or 'we can never get this to scale beyond just a prototype, and there are no customers willing to pay for this either, let’s cut our losses.'"
- "Sometimes OKRs get blocked (ie not dev-ready) a few weeks/sprints into the new quarter. I'm hoping that engineering can start their work as soon as the quarter starts. If there are multiple OKRs for the same product then having just one to be ready when the quarter starts is fine. I just want to avoid the situation where a given engineer has no OKRs to work on when the quarter starts."

The Sentry Keyboard

Fri, 13 Dec 2024 00:00:00 GMT

Every year the Creative Team at Sentry produces a holiday gift for everyone at the company in a tradition we call Spectivus. Last year we decided to make a keyboard. It turned out pretty rad:

Why a keyboard?

This time around we wanted to do something with more staying power than past gifts, focusing specifically on creating less waste and providing more long-term utility. We thought, "Wouldn't it be cool if this gift was the start of something instead of the end?"

Being an engineering-heavy company, we felt a mechanical keyboard was sufficiently nerdy and could pull double duty as both an awesome gift and a trophy case. The pitch was that over time we would introduce new, limited edition keycaps to celebrate our teammates' accomplishments at the company.

A few key details

After surveying some of the fastest typers on the team, we decided to go with a 75% layout. This ended up being perfect because it let us have a small/cute form factor, while keeping common characters like the backtick out of tricky function key combos.

We wanted the keyboard to be clearly "Sentry", so we explored custom colorways that utilized our brand colors. In the end we landed on a scheme that mirrored our use of muted purples and pops of yellows/pinks that you see across the website and app.

The keyboard shipped with Cherry MX red linear switches, a custom programmable knob, and 10 Sentry special edition novelty keys:

Some real talk about vendors

Choosing the right vendor is important. We landed on a partner who was able to customize the keyboards, print custom packaging, and get them to us in time for the holidays. However, while the keyboards looked amazing, the firmware they shipped with has had endless issues. Many units also arrived with hardware problems. The vendor was fast to address what they could, but we ended up spending a lot of time in support mode for our teammates and we hadn't anticipated that.

Next time around we'll likely just buy a barebones kit like the GMMK Pro off the shelf, produce a high-end keycap set, and work with our fulfillment partner for assembly. Or better yet, let the recipient build it themselves. That's part of the fun, right?

What's next?

Now that this is a thing, we're following through on building on the keyboard as a platform. We're starting with tenure keys, hack week and other awards, and keys to commemorate important company milestones.

Every new hire gets one - why not come get your own?

Credits

Design: Hannah Katz and Christine Gan

Copywriting: Maddie Ritchie

Project Management: Yana Boldyreva

How Codecov Design Works

Thu, 07 Nov 2024 00:00:00 GMT

Introduction

We’re a small but mighty design team of two, Adalene and Kyle, working as part of the larger Sentry design team. Each team at Sentry has its own approach based on product focus; here’s a look at how we operate at Codecov. If you have any feedback, tweaks, or suggestions, we’d love to hear from you!

Our Workflow

We work in two-week engineering sprints, which help us manage our workload and provide consistent output for engineering and discovery needs aligned with our quarterly goals. We chose GitHub as our project management tool because it’s where our engineers and customers work daily, naturally aligning with our processes.

Most of our work is asynchronous, but we hold regular synchronous sessions for design reviews, issue kickoffs, research debriefs, product audits, and ongoing discovery.

Everything Starts with an Issue

Anyone—internally or externally—can contribute to improving our app by starting with a GitHub issue that defines the problem. We groom these issues for prioritization, valuing documentation, as issues are central to tracking our iterations and decisions. If you have a suggestion or improvement, please let us know here.

Our GitHub project board contains sprint issues, backlog items, discovery work, polish items, bugs, and tech debt. This centralized project view allows us to monitor progress and easily pull dev-ready items when the engineering team has capacity.

Design Review and Feedback Loops

At Sentry, we rely on intuition informed by feedback from multiple sources:

External Feedback: GitHub issues and discussions, social media alerts, PR comments, in-app banners, surveys, the Sentry feedback tool, user testing, and ad hoc user interviews.
Internal Feedback: Async GitHub reviews, #discuss-codecov-product-design Slack channel, weekly audit syncs with PM and support, focused project reviews, and weekly Sentry design team reviews.

Synchronous Meetings

Sprint Kickoff with Engineering

We work closely with engineering, attending biweekly sprint kickoffs that include gratitude moments (shoutouts to our peers), sprint focuses for engineers, and design team priorities. This raises awareness of ongoing efforts, allowing us to ask for help where needed.

Issue Kickoff and Breakdown

For more complex issues, design and engineering meet to define the problem, goals, and decide on next steps from the outset.

Product Audits

Each week, Product, PM, and support teams review a specific workflow, identifying immediate fixes and longer-term discovery areas.

Weekly Design Syncs

These include both Codecov design syncs and wider Sentry check-ins. We share current projects and gather cross-team feedback.

Closing

Our process is ever-evolving, but this is how we work today. If you have any thoughts or feedback, we’d love to hear from you. Feel free to reach out at kyle.mann@sentry.io or adalene.teh@sentry.io.

Building is Blues

Mon, 04 Nov 2024 00:00:00 GMT

If you’ve read any product or UX books—or if you’ve ever hired product or design folks—you’re probably familiar with the typical linear process for building the “right” product. It goes something like this:

good practices, sure, reality it's not

It’s a comforting formula, and on the surface, it makes product development seem like a predictable, step-by-step process. I’ve seen this approach in countless design interviews and product presentations, and it always leaves me scratching my head, since it feels like a cover for the messy realities of building software. Sure, these are helpful practices to use along the way, but the problem is that this method is often sold as the way to success. The issue is that this mindset overlooks the layers of complexity involved in not just building software, but also shipping software that’s actually useful and valuable (not to mention hitting the right timing for the market). In reality, most successful products and innovation aren’t built from a foolproof formula—they come from tinkering, experimentation, and navigating the unknown. Success usually boils down to risk-taking, persistence, randomness, timing, and yes—plain luck. So why treat this linear process like orthodoxy?

That’s why I see building as nonlinear—more like a blues song, constantly evolving, full of improvisation, and never really finished. That is the way. Design, to me, sits at the intersection of technology and the humanities, and one of the greats I’ve learned from in the humanities is the King of Blues, B.B. King. Here’s why:

Lessons from the King of Blues

Ever listen to a blues album? It’s a never-ending cycle of love and heartbreak:

Sound familiar? That’s product development. You start with a vision, fall in love with an idea, and soon find yourself navigating unexpected twists, turns, and letdowns. But that’s part of the uncertain path—you're not alone. We’re all singing the blues in one way or another.

If we agree that building software is a nonlinear endeavor, then let’s take a look at the lessons the blues can teach us:

Lesson 1: Take Risks

Starting a new project feels like being at the bus station with just $5 in your pocket, staring at a board of unknown destinations. The blues teaches us to take that risk, buy the ticket, and see where it leads. You might find your sweet baby, or you might end up in a town full of heartache—but you won’t know unless you jump on the bus.

Lesson 2: Embrace the Love of Problem, not the Solution

Blues is all about falling in love with the problem—whether it’s a “bad case of love” or your baby leaving you. It’s that persistent, gnawing, and sometimes painful understanding of the problem you’re trying to solve. The blues reminds us that this is where the focus belongs. Falling in love with the solution will only bring heartache. There are plenty of notes to play to address the problem, but always just one problem to solve.

Lesson 3: Feel the Pain

You’ve poured your soul into the product, done the research, followed the formula—and still, nothing. The blues doesn’t follow formulas; it’s about feeling your way through, learning from failure, and improvising along the way. Pain is part of the game, and the sooner you embrace it, the sooner you grow.

Lesson 4: Joy is Fleeting

Sometimes, the stars align, and you hit that jackpot. Users love your product; you’ve found your sweet spot. But just like in the blues, that joy can be fleeting. The thrill fades, users leave to another, or they stick around but aren’t happy anymore. The blues teaches us to accept that joy is temporary, but the show must go on.

Lesson 5: The Thrill Is Gone – Who Cares, Keep Playing Iterating

The thrill might be gone, but the building isn’t over. You’ve felt the highs and lows, and no matter how many shiny features you roll out, there’s always another challenge ahead. Iterating a product is like a blues ballad—raw, unpredictable, and never really finished. And that’s where the magic happens, as long as you keep the train moving.

Lesson 6: Trust Your Intuition

In both the blues and product development, intuition is key. The best blues musicians, like B.B. King (who famously couldn’t play chords), he didn’t follow rigid rules—he felt his way through each note, trusting his gut. Similarly, real product innovation isn’t just about following user feedback or relying solely on research and data. It’s about trusting your intuition to guide you when logic and data can’t provide all the answers. At Sentry.io, we embrace this approach—balancing data with instinct when needed to find the best way forward. (more on intuition in another blog.)

In summary, my protest isn’t against the practices of the all-too-familiar linear process; it’s against the false illusion created that a linear set of steps will produce predictable results. At worst, this belief can mislead teams or prevent them from accepting the reality that innovation thrives when you step outside the confines of convention. Blues is the way.

So, next time you’re deep in work, consider asking yourself: “How blue can you get?” Because if you’re not embracing the improvisation, setbacks, and uncertainty, you might just be missing what building is really all about...

Thoughts? Have a blues story of your own, or maybe a different perspective? I’d love to hear it. Drop me a line at kyle.mann@sentry.io.

Sentry goes metal

Fri, 13 Jan 2023 00:00:00 GMT

I have always been a metalhead – black, speed, Norwegian, death, DOOM I love it all. So, this year for our annual hackweek I decided to Metalify (is that even a word?) the Sentry logo.

While researching the origins of metal band logos everything ultimately leads back to one band - Black Sabbath. Mere moments into their debut album, after the church bells had grew to a thunderous cresendo of distorited guitar. A simple question is asked to the listener "What is this that stands before me?". But the album cover asked this question well before the needle even dropped.

The cover is features a haunting photo of a woman stand along in the woods, adorned by a creepy, bubbly, psychedelic wordmark pinned to the top corner inspired by black lettering from centuries past. This imagery perfectly captured what was in store for the next 40 minutes.

Metal has evolved considerably over the past 50 years to include hundreds of different sub-genres and artistic styles. Even at Sentry asking "what is your favorite metal genere?" in our #metal slack channel provided many different results, and a few I have never even heard of.

Before I even drew a single line I queued up my favorite Blood Incantation album turned the volume to twelve and after a sufficent amount of blood had pooled within my ear canals did I feel fully prepared to begin drawing.

My initial rough sketching started in Procreate, but quickly I moved all the work into Illustrator. I knew having the final artwork in a vector format would offer me the greatest degree of flexibility with variations.

Moodboard of Mayhem

Illustrator File

Final Artwork

At the end of hackweek the entire company gets together to demo what what we built. The thought of having the entire company watch a video with intense metal music playing in the background greatly ammused me and well enjoy!

Watch for yourself

Design is Politics

Fri, 09 Dec 2022 00:00:00 GMT

The hardest thing about design work ain’t the design. Sure, learning about typography and color theory and everything else in the beginning sure is overwhelming. There’s so many books to read! So many things to learn! All the tiny details in Figma or Illustrator! Or figuring out the weirdness of CSS! But it took me over a decade in this field to realize that all this stuff that I struggled to learn is really the easy part of design. The border radii and copywriting and UX work is monkey business compared to the hardest thing you’ll do as a product designer.

The hardest part is the work that doesn’t look like work at all: building consensus, getting folks to agree on something, pitching a vision for the future and then walking through the steps to get there. Then you have to ensure you’re doing all that with right person in the right room at the right time. It’s about clear communication across teams and about reaching out to folks to get stuff done.

That’s because design is—ugh—politics.

When I first got into design systems many years ago, I found that picking button sizes, building solid components, and refactoring things was kind of easy, but getting people to agree on all those things? Boy howdy! It’s impossible if you don’t present the work correctly because without selling your design, without good rhetorical skills of any kind, that beautiful work will never see the light of day. I can’t count the times where I’ve pitched something that I thought was punk rock, only to find that I’m blocked because I didn’t communicate my thoughts properly. The work then dies on the vine, never leaving that stuffy meeting room.

That’s not to say that I’m a misunderstood genius designer who is always right—I’m absolutely not. I make mistakes all the time and I constantly produce half-baked work, but those visual and UX failures of mine pail in comparison to the failures in this other part of the job. Because what’s true for design systems is true for product design: good work will only ship if you sell it.

When I first heard that you have to “sell” your designs many moons ago though I was horrified. Shouldn’t great design be obvious? Why do I have to sell it when the design work itself is hard enough? Shouldn’t beautiful work be celebrated and encouraged, not bartered and fought for? For years I would blame the person I was pitching my designs to for their lack of understanding, their lack of vision. How dare they not recognize my genius! The nerve!

Painfully though, after bashing my head into the same wall over and over again, I now see things differently. It’s not really about “selling” design as much as it is communicating it clearly. Some people hear things in different ways and you have to learn how to speak in their tongue. You have to learn what is effective, how to unblock a design conversation, how to point to problems without everyone in the room feeling bad. Once I started being more careful about this, I noticed that my work improved, too. The act of learning how to sell this stuff improved my interfaces, my copywriting, my work. Weird!

I am yelling at myself here, but: you need to campaign for great design! If not for the managers and higher-ups, then for yourself. You have to get on that podium and learn how to make people excited to fix all these problems you see.

Okay, okay. I’m saying all this as if I’m preaching and I have all the answers figured out but the thing is, after all these years, I’m still awful—colossally, unforgivably awful—at politics. Design-wise I think I have some typography skills, my color skills are sometimes okay, but my politics? My talking skills? My rhetoric? Awful! I get angry at myself in the moment when I struggle to explain why this design is a good step forward, why something ought to work a certain way, and then I lose focus, lose patience, and everything crumbles around me. I can feel myself losing people in a meeting, the crowd growing distant, and then eventually caring less and less for what I have to say.

But when I’ve pitched something successfully it’s because I was careful, patient, and disciplined. When my designs ship it’s because I slowly walked through the problem, showed my thinking clearly, and gave our team a couple of options to move forward with. That’s politics, baby!

So I’m making a reminder for myself here that great design only gets built when you care for the politics—but!—I’m not suggesting here that we go out and be manipulative in a Game of Thrones-esque way. Getting good at politics isn’t about trying to dominate or control people just to get what you want. Chaos might be a ladder, but design surely isn’t.

Let me frame it like this instead: great design only ships when you care for the people you’re pitching it to. That’s politics. And that’s something worth repeating until it sticks.

The Art of Passive Aggressive Copywriting

Fri, 04 Nov 2022 00:00:00 GMT

Here’s a punk rock opinion that will shock you to your foundations: writing is hard. Especially so when it comes to product design, since first you have to understand precisely how something works and then you have to succinctly explain to the user why you’re telling them about this complicated thing and then you have to carefully explain what they need to do next. Ugh! That’s hard!

But when it comes to writing, the tone is equally difficult to get right and I’d say that lately it feels as if every app and website sounds the same: they’re all uncomfortably happy to see me...

“BORN TO INSPIRE”

“START A BOLD NEW WORLD TODAY”

“CONGRATULATIONS! YOU DID [VERY BORING THING]!”

Every website, to my ear, sounds as if it’s written by the same maniacally happy person sat at their keyboard typing. But I get why. Companies want to sound alert, inspiring, delighted to meet your acquaintance yet because this writing style is now so common, it has the same effect as using the popular, boring ol’ typefaces over and over again: something special is lost in the repetitiveness of it all. Just open up any app on your phone and it’s guaranteed to be too bland to remember, the writing equivalent of when every website was using Helvetica or Georgia. Everything is a little too pleasant, a little too nice that I personally find kinda creepy.

Does all writing have to be this way though? Are there other ways to write for a product or a website or an app?

Well, at Sentry I think we sometimes nail that fine line between clear copy and tone. Here’s an example: a while ago I was designing a modal and I knew that customers would be bummed out about seeing yet another one of these. But we had to explain to customers that a new feature was available and so I thought, what if we made this modal like a little character with a mood? What if we made this modal in on the joke? It’s simple and also incredibly dumb, but here’s what I came up with:

How many Save and Confirm buttons have you clicked over the years? A hundred thousand? A million? But how many Leave me alone buttons have you clicked? Precisely! It’s just quirky enough to be both silly and memorable.

Oh and that reminds me of this multi-step tutorial we made some time ago:

I want interfaces to treat us like people, not overly-positive automatons that have to hear songs and watch confetti rain from the sky at every step of a checkout flow. Sometimes it’s okay to be a bit rude and weird for fun.

Of course—yes yes yes—this all depends on context. If there’s an urgent task or a problem affecting a user then that’s not the right time to tell them to “Get a life” or “Go away.” A website for a hospital should never give me a wedgie and make fun of my glasses because that’s not fun, that’s just plain mean. But the more I write copy for interfaces the more I realize that these products we’re working on can try a bit harder even during the boring moments in the downtime, the moments when things are painfully bland.

Our words should aspire to be so much more: more fun, more interesting, more jovial. And so we don’t need big new paradigms or fancy CSS libraries to make our interfaces great, all we need sometimes is a text editor, some time, and a good dictionary close by instead.

(But being a jerk helps, too.)

Custom Sentry Synth by Love Hulten

Thu, 06 Oct 2022 00:00:00 GMT

We recently commissioned a custom modular synth for the Sentry SF office from the audiovisual designer Love Hulten.

Here's what he came up with for us:

We wanted to do something to make our corner of the office a little more interesting. Having worked with Love Hulten on a personal project in the past, this seemed like another great opportunity to collaborate.

A fairly common thread across the design department (and Sentry at large) is our love and appreciation for music and hardware, so I reached out to Love with an idea:

What if members of the team could walk up to a wall-mounted synth, plug in their headphones, and be expressive/weird in a different medium for a bit?

Over the course of the next several months we riffed on specs, finishes, and branding to make it feel over-the-top Sentry. On the inside it features the Moog Matriarch, Roland TR-08 Drum Machine, T-Rex Replicator, Blue Sky Reverberator, and a Sentry logo speaker panel.

We're thrilled with the outcome and will be looking for more ways to collaborate with Love in the future!

'We should totally write this stuff down'

Mon, 29 Aug 2022 00:00:00 GMT

In addition to fighting pixels, The Sentry Design Team fights a lot of other things as well. We fight ugly sweaters, lego sets, Senkey diagrams, developer conferences — often things where there's little to no prior art or reference to draw from. This is why today we're launching Sentry.Design, which is our attempt to improve that in some small way.

During this year's hack week, I set some time aside to play with a new and exciting technology: a static blog. But this isn't just any static blog, it's a place for members of the Product Design and Creative teams at Sentry to share bite-size learnings (and full helpings sometimes?) about the work we do here and the unique challenges we face across the design org.

The initial iteration of the blog is built using Astro.build for static site generation and Spline.design for the custom 3D emoticons. Both tools have made bringing this idea to life much easier than expected. I can almost say that it has been fun.

We're excited to share these glimpses into our workday. See you there!