Mid-Point Reflection: Product Design Intern at Datadog

dog emoji on light brown background

In this article, I wanted to take some time to reflect on my internship thus far.

So, let’s get into it. Note: This is a long article!

What I do

This summer, I’m working as a product design intern at Datadog.

What is Datadog?

Datadog is an all-in-one platform for monitoring and analytics. They give you real-time insight into your company’s entire technology stack.

It’s very much a B2B (business to business) company, and there are over 5,000 employees.

datadog white logo on a purple background

What am I working on?

I work in one of Datadog’s product teams - logs management. To keep it simple, think of logs as little notes that computers/programs write down to keep track of what they’re doing. Oftentimes, there are millions or even billions of logs for big companies.

logs search page in datadog
The table goes on forever... 😂

For the past month, I worked on small design projects on logs. And now, I’m working on another product related to logs called sensitive data scanner (SDS).

In short, a good example of sensitive data is your credit card number. You don’t want anyone to know your number. So, when a bank uses Datadog, they’ll also use SDS to find all credit card number and change it so they won’t be hacked.

sensitive data scanner page in datadog

What I learned

Now, it’s only been a month, but I have learned so much. Let’s go over them.

Product development process at Datadog

Note: I only know the cycle on the logs team. This does not apply to all the teams in Datadog.

On the logs team, PM is the main driving force. And what surprised me were the following two points:

  1. PM does most of the user research. They schedule times to talk to their customers.
  2. Customer support tickets are another important way for PM to get signals on customer pain points.

Below is a diagram of a dumb-down process that I observed.

flow chart of product development process at datadog

Benefits of writing a design review doc

At Datadog, if a designer wants to get feedback from the entire design org, they’ll write a design review doc.

Normally, it’ll contain the following sections:

  1. TL;DR
  2. Context
  3. Problem
  4. What type of feedback are we looking for?
  5. Design recommendations
  6. Next steps

Once a doc is complete, a designer can email it to the entire design org to get feedback via comments.

Thus far, I have sent out one design review doc, and I’m still surprised by how much feedback I got. There was so, so much feedback that it was overwhelming (in a good way). To all the people who commented, thank you.

But aside from the design review doc, I have formed the habit of writing design doc for each project. This not only helps me process my messy thoughts but also makes it much easier to turn a project into a case study.

In terms of structure, it’s up to you. You can structure it like a typical case study or something like a work journal.

Nature of a large company

Datadog recently surpassed 5,000 employees worldwide.

Obviously, it’s not as big as Google with 190,711 employees. But, Datadog is still the largest company I have interned at so far.

Here, I want to note down an observation I’ve made about designing at a large company:

Depending on your team, product, and org size, your proposed change could impact a ton of teams. This means more communication, time, and effort to align and get buy-in.

Let’s go over a quick example.

Let’s say you want to change an element in the search bar.

You pump out the designs in less than a day. You’re all excited and have your Figma file ready. But then, you realize that you also need to:

  • Talk to the design ops team to see if this is possible with our current design system
  • Talk to other product teams who also use the search bar and see if your work will affect theirs
  • Get approval from your mentor, manager, PM, and engineering lead (1 call or 4 calls). More often you’ll have many rounds of review (more calls) or people are busy so you have to wait.
  • Do design QA (quality assurance) with your engineer to make sure it’s built correctly
  • Set up success metrics & track how your designs are performing

This brings me to my next point.

Implementation takes longer than design

So, even though you crank out the design in like 1-2 days, actually building it takes time.

And when you start to go over the process, you may realize that the problem is much more complicated than you think.

That’s what happens - scope creep. It’s when a seemingly small project turns into a huge design effort that involves many teams.

So, what can we learn from all this?

Unblock yourself

This is so, so important. Don’t sit there and wait. Take initiative such as

  • Get started on another project
  • Follow up with the stakeholder
  • Inform your mentor & manager about the situation
  • Document your designs for future use

The point is: Don’t wait to get instructions on what to do. Do it first.

Be respectful but do follow-up

Interns want their projects to get built so don’t want to wait - I get it.

It’s also important to respect people’s time - I get it.

But sometimes, you do have to push a bit. Because if not, then nothing will happen.

To give a reference, one of our PM’s calendars on the logs team is…full.

Like - no white space on his Google Calendar.

I have to look hard to find a rare 15 min window.

With that in mind, if you really want to get a response from a stakeholder, here’s how I normally do it

  1. After 1 day: Inform my mentor/manager about this & ask what I can do
  2. After 2 days: Follow up via Slack
  3. After 3 days or more: Try to find a 15-min slot and book directly. Worst case scenario is that the person declines and I wait longer

I mean - you have to do something to get the ball rolling.

Be proactive in seeking context

This is also so important.

As a designer on a new project, there will be a lot that you don’t understand. Especially if you’re working on a technical product.

Thus, be proactive in reaching out to key stakeholders. Don’t be afraid to ask questions. Get all the information you need to feel confident in designing.

Don’t wait for instructions. Get stuff done.

Ex-President Obama puts it much more elegantly than me in this video. Here’s a snippet:

A lot of times, the best way to get attention is: Whatever is assigned to you, you are just nailing it. You’re killing it.

See it all as a learning opportunity

My manager gave me this advice.

Since I worked in a startup before, working at Datadog has been a new experience for me. For example, it took time for me to adjust to a bigger company’s product development process. And with that came some frustrations.

So, when I told my manager about this, we had a thorough conversation about it. She was very understanding of my situation, and in the end, she advised me to try to see what I can learn from this.

Hence - this article.

Research does not only mean user research

For some reason, my mental model of research always led to user research (interviews, surveys, etc).

Maybe it’s because of the classes I’ve taken. Maybe it’s because of the articles I’ve read.

But, as my mentor said, research does not only mean user research. Competitive analysis, desk research, asking PMs - there are so many other types of research.

Now, this doesn’t mean that user research is not important. But, what matters more is the underlying question:

Why do you do research?

The goal of research is to uncover information that we need or want to know to solve a problem.

It’s not a checkbox item.

You only do it if you need to, especially in a large company where it requires resources & time to do user research.

And a lot of times in bigger companies, you already have a lot of existing data available for you. So use them.

So, it’s important for a designer to advocate for the users, but it’s also important for a designer to use what’s around them.

Design system is a tool

At Datadog, the main design system is DRUIDS. This stands for “Datadog Reusable User Interface Design System.”

druids main homepage
The illustration is...very quirky 🤪

And it’s awesome.

I’ve used it so many times now, and I have to say: It’s so easy and quick to use in Figma! I can’t wait to see how the team refines it with Figma’s recent update on variables.

But, the point I want to stress is as follows:

Before Datadog, I’ve always seen design systems as a faster way to design. But… sometimes it can be restrictive.

Well, not until my onboarding session with Datadog’s design-ops team.

In it, the staff designer told us:

Start with DRUIDS. Then use your judgment.

The design ops team created DRUDIS to ensure everything is familiar and well-designed. But, this doesn’t mean they’re hall monitors. They’re not here to say a designer/developer can’t do something or break the rules.

They’re here to be our partners. We can discuss use cases so that the team can advise on the best approach.

As a design intern, I love how open and collaborative the design ops team is. They’re not married to the design system, and they’re all open to chatting about changes and new use cases.

Express your thoughts as an intern

I may have alluded to this earlier, but I’ve started to realize:

I need to speak up for myself as an intern.

And this was something my mentor told me during one of our 1:1s. I’ve done something like this back at Roblox last summer. But, it’s still hard.

Like, who am I to say what I want? I’m just an intern!

But, at Datadog, at least on my team, interns are encouraged to speak up for themselves and push back. This brings me back to my hackathon article:

Beware of nodding heads. Seek disagreement because that’s when new ideas spark.

Note: don’t try to start arguments for the sake of it. Also, think about how you want to express your thoughts.

Is it an onslaught of complaints or disapprovals? Or is it a well-thought-out argument with you being intentional with the final goals?

Best practices to get quality feedback

Lastly, I want to write down a few best practices to get good feedback. This was something I asked my mentor. And she gave me all these wonderful tips:

Always provide context / where we left off

Nobody understands the project more than you do. Most people don’t even know what you’re doing. So always, always provide a quick context in the beginning.

If this is a second round of review, quickly say where you all left off.

Specify what type of feedback I want

It’s good to be intentional with the type of feedback. Or else, you may end up getting irrelevant feedback that’ll distract the work.

So, be specific. For example, a quick one can look something like:

Hi! [Project context]. We currently have 2 options right now (pros and cons listed below). I’ll appreciate any feedback on which option you prefer and why!

Know your audience and tailor your delivery

When getting feedback, you need to know your audience.

Are your audience PMs? Engineers? Designers? Or even VP / C-Suite level?

Based on the types of stakeholders, how you get feedback will be different since they care about different things.

In general, here are a few guidelines for each of these audiences:

PM

  • Format: Hi-fidelity prototypes/screens
  • Cares about: Whether it’s feasible or not, edge cases, how long it’ll take to implement with the timeline in mind, success metrics

Engineer

  • Format: Hi-fidelity prototypes/screens
  • Cares about: Edge cases, whether it’s feasible or not, how much time it’ll take to build, how each screen flows to another

Designer

  • Format: Lo-fi or hi-fi prototypes/screens/design review doc (Datadog specific)
  • Cares about: Flow, familiarity, interactions, design details, customers
  • Note: It also depends if you’re getting feedback from your internal team vs the design org. It’s often much more casual if you’re just getting feedback from your mentor/manager.

VP / C-Suite (based on what I heard)

  • Format: Design review doc / Presentation
  • Cares about: Big picture, the impact of the designs
  • Note: I don’t have much experience with this. The design review doc only works for the VP level since the VP of design at Datadog does comment on design docs. I think it’s super cool that he takes the time to do this.

Make the process of giving feedback easy

People are busy. So what can you do to increase the chances of someone giving you feedback?

Make it as easy as possible.

One example can be a simple “Option 1 or 2” on the Slack design-review channel.

This is a bit ironic considering Datadog has long design review docs. But I guess designers at Datadog know that these docs are meant for feedback. So they’re open to help.

Focus on a use case

As designers, it’s easy to delve into specific design elements. I mean - we poured time and effort into it. Why not?

Well, it turns out. Often people don’t really care.

It turns out: What people really care about is the use case. Like how will people use your designs? What’s that experience like and how does it solve the customer’s problem?

Obviously, it depends on the type of your project. But in general, try to use your designs to walk through a use case. It’s much easier for stakeholders to process.

What I could do better

Phew, that was a lot to process.

If you’re still reading, you’re a superstar.

In this part, I want to talk about what I could do better in the next month at Datadog.

Pace myself and focus on delivering

This brings me back to one of my lessons:

I may have the designs ready to go. But oftentimes delivering takes a lot of time too.

So far, I’m on track. But I also need to focus on delivering not only designing.

Allow for more serendipity in the office

Now, this is really hard for me.

Because I’m the type of person that likes to stay in my corner and grind. It’s a great feeling. Plus, I’m an introvert.

But, I do want to push myself more. I know it’s already almost halfway through the internship, so I’ll do what I can.

Every once in a while, stand up and walk around. Just have a casual chat. Don’t be afraid to start conversations that I don’t know where it’s going.

collage of the datadog office
The office is actually SO nice 🥹

Write a shout-out list for myself

This was my manager’s advice during our 30 days check-in.

To be honest, I don’t think I’ve done this before formally. It feels weird to write a shout-out list for myself.

I like to move things forward and focus on the things I didn’t do well. But, it’s nice to sometimes pause, reflect on the things I did do well, and pat myself on the back.

Plus, it’s a great habit to have career-wise for performance reviews.

Other highlights

You can probably tell that I learned a ton as a designer in the first month. And I can’t wait to learn more in the next few months.

But, let’s go over some of the internship highlights too!

Intern picnics

On the first week of the internship, all the interns were invited to a central park picnic.

It was super fun, and I met a ton of interns during the picnic!

collage of the datadog intern picnic at central park

Team bowling

When my manager’s manager came to New York, she brought the team out for bowling. It’s been a while since I played, so I was quite rusty.

Nonetheless, it was awesome to play with the team!

collage of bowling with the design apm team
Was super rusty at bowling 😅 Was fun tho and shoutout to Kim for organizing!!

Design fun time

I also hosted a virtual design fun time for my team! I was quite nervous about this one, but it turned out better than I expected!

Special shout-out to Henry & Erin for all the discussions & help!

design fun time main slide
Found this great presentation template!

Design picnic

Most recently, we had a design team picnic at central park. It was great to meet a bunch more designers/design managers. And not to mention how delicious the food/snacks were!

datadog design team picnic at central park
Chill times~

Conclusion

So far, I have really enjoyed my time at Datadog as a product design intern. And I can’t wait for the next few weeks!

Read Next