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!
This summer, I’m working as a product design intern at 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.
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.
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.
Now, it’s only been a month, but I have learned so much. Let’s go over them.
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:
Below is a diagram of a dumb-down process that I observed.
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:
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.
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:
This brings me to my next point.
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?
This is so, so important. Don’t sit there and wait. Take initiative such as
The point is: Don’t wait to get instructions on what to do. Do it first.
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
I mean - you have to do something to get the ball rolling.
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.
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.
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.
At Datadog, the main design system is DRUIDS. This stands for “Datadog Reusable User Interface Design System.”
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.
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?
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:
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.
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!
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:
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.
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.
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.
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.
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.
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.
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!
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!
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!
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!
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!
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!