You made it to the footer š
To get new article update &Ā cool design tingz I find, subscribe by taking 4 seconds to type down your email:
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!
ā