Amplitude helps product teams make better decisions. Microsoft, Twitter, Capital One, and PayPal are just a few of the many huge companies using Amplitude to get insightful, actionable data about the people using their products.
So what’s it like to build a product by studying how your customers build products? We sat down with Amplitude’s Principal UX Designer Tareq Ismail, Senior UX Designer Ran Liu, Senior UX Designer Jenny Chang, and Brand Experience Designer Meredith Fay to hear about that and more.
How is your design team set up?
Jenny: It’s lean—we have 3 product designers and 1 brand designer. Since we’re such a small group, it’s easy to move quickly. We all believe that trust is the foundational element of speed, and it allows us to challenge and push ourselves while still operating from a foundation of respect.
Ran: We use a pod system for product development. It’s like a combination of the squad model and the 2 Pizza Rule.
A typical pod consists of a designer, a PM, and a few engineers. Each pod gets a goal and a metric to work toward and the team has full autonomy to decide on the solutions to achieve the goal.
“Let low-level discomfort drive you to become a better designer.”
For other design tasks like usability studies or building personas, we function like a centralized design team and work on the tasks collaboratively.
Tareq: What’s great about our pod system is that you always get a bird’s-eye view of the problems we’re tackling. Everyone in the company knows the pods and knows who’s doing what. It makes it really motivating to tackle something to completion.
And our small size makes it easier and faster to communicate, but at the same time we often all have a lot of responsibilities. You have to know how to organize your time and focus.
“We see transparency and collaboration as a core part of our culture at Amplitude, and we wouldn’t be able to do it without InVision.”
Meredith: Velocity is one of our operating principles at Amplitude, and as a small team with a heavy workload that means we need to be on top of making decisions and executing on them. With such a quick cadence, there’s always that low-level discomfort driving us.
The upside to this is I’ve become a faster, more efficient designer. One downside is that I wish I had more time to tinker on visual work, but sometimes good is good enough—and it’s important to recognize when it’s time to move onto the next task.
You mentioned trust. How has your team built trust with each other?
Tareq: We have weekly syncs and we try to talk as much as we can, but what’s most important is that we’re constantly talking to customers. We actually keep track of how many customers we’ve personally talked with per week.
When I know my teammates are always talking to customers, I trust that they’re making the best decisions.
What’s the worst piece of feedback you’ve ever gotten, and do you have any advice for how to give great feedback?
Tareq: I’ll say this: The worst way to give feedback is starting a sentence with “It looks nice, but…” or “It looks really pretty, but…” That frames the question in a way that implies the designer set out to only make it look nice rather than make it work great.
I hate when people do that.
In terms of giving feedback, you can only really give good feedback when you have:
- Asked the right and important questions first. I’ve found the best way to give feedback is actually to start off by asking questions. Ensure you really understand the constraints, the goals, and the intention behind decisions. When you’ve honestly done that, then feedback can always map back to those things. For example, “Okay, so this affordance needs to tell users that this is draggable. I’m concerned that it’s not enough for all users. Is there some way we could validate that or something we could try to complement it further?”
- Built real trust with the person. If a random stranger came up to you and gave you advice, you probably wouldn’t consider it. The person and your relationship with that person giving the advice is almost as important as the advice itself. You need to build trust so people know your intention is to actually help and to build a better product as a team. If the person you’re giving advice to doesn’t believe both those things, then the advice just won’t have much of a long-term impact. Then it becomes an instruction.
Related: Designers share the worst feedback they’ve ever gotten
What’s the design culture like at Amplitude?
Tareq: Being such a technical company, we need to be really good at expressing the value of our designs. We do this by holding presentations and setting the goals for each design when we share them. That way, our design culture becomes more about using designs to solve problems, rather than just how it looks.
It’s not always easy, but explaining user feedback and then the goals based off that often can be the glue for a project between product manager, designer, and engineer.
“Know how to express the value of your designs.”
We have a saying that goes, “Your app isn’t what you intend it to be, it’s what your users intend it to be for their lives.” The best example of that is one of our customers, a meditation app named Calm, discovered that people who set a reminder to use the app were retained 3 times more than people who didn’t set a reminder. They intended their app to be something people escape to, but their users wound up wanting it to be something they could schedule. (Read the case study.)
Amplitude obviously sees design as the key to success. Any tips for getting executives at other organizations to prioritize design?
Tareq: Take time to succinctly express what you do and how it makes a difference. Sometimes that’s showing data in a compelling way. An example would be you saying, “We interviewed 25 users, and that helped us understand these problems. We then experimented with these solutions and it resulted in much better qualitative feedback as well as a rise in our actual numbers for features X, Y, and Z.”
I think designers often want their work to stand on its own, but I’ve found that half the designer’s job is explaining their work in the context of why it’s the solution, and then later how it has affected the product.
How do you and your team decide something is worth changing?
Jenny: After we find a hypothesis, we always jump into our data to explore how users are currently using the product. A simple example happened just the other day: We were considering removing an action from an area of our application. Within the minute, we figured out that the action was used most from the area we were thinking of deleting it from.
The discussion immediately changed from us removing it to surfacing the action as a usability improvement. If we didn’t have concrete data to inform us of this decision, it would have been like building a product in the dark.
“We use InVision as a prototyping tool to get our design ideas out quickly.”
Tareq: For higher level problems, we discuss our major focuses as a team with the PMs. This is when we set up our pods. Like I said, the best part of pods is knowing what the team is focusing on.
At this stage we discuss the biggest opportunities, what we think of competitors, and where we want to be. It’s exciting because it’s a really transparent way of discussing our roadmap and building our product strategy together.
Does data come into play here?
Tareq: Absolutely. Startups often use the term “Total Addressable Market,” and we do something similar—it’s around the impact within our app that we called “Total Addressable Userbase.”
For example, if a designer were to suggest that we put a helpful tool tip in an area to educate users about a feature, my first question would be, “Okay, but how many users actually get themselves in that state to begin with? What’s our total addressable userbase with this feature?”
The designer would then look up the numbers and, more importantly than just numbers, they’d see what types of users go there. Are they new users? Power users? How can we best serve people in that situation?
All of this starts with data and then leads us to questions using qualitative means.
For designers and teams who might be completely lost when it comes to designing with data, how do you recommend they start?
Ran: Start with one single question for your next feature. It’s easy to try to do too much and get discouraged and overwhelmed.
Just start with one thing you’re curious about today. It can be as simple as: How many people are using this feature every day/week/month? Then choose which metric will give you the closest answer to your question.
Once you get your first question answered, it’ll likely trigger many more questions you want to ask. Now you have momentum.
It’s also very helpful to read up on product analytics so you get ideas on what types of analysis other people are doing. The Amplitude Retention Playbook is a great place to start!
“Designers should be using data all the time.”
Tareq: Think of data as another source of information. Qualitative information like user studies and interviews is one type, and data is another. They both need to be synthesized to be helpful.
So I recommend someone start by really asking what they think they don’t know. Then talk to users. And then see if what users have said is also reflected in the data.
Start a data trail by asking related questions such as, “Is this true for new users? What about for power users?”
Once designers start doing that, they realize that there’s no one time for using data—rather, it’s something that should be used all the time, just like any sort of feedback, based on what questions the designer needs to ask and answer.
Do you listen to music while you work? What have you been listening to recently?
Meredith: Do you ever put your headphones in and then forget to hit play, then go about your day with your hearing a little muffled? That’s how I feel when I don’t listen to music when I’m designing.
When I hit play, my designs begin to move to the tempo, like the pixels just needed a beat to move to in order to find their right resting place. I make new playlists every month, but some of my recent go-to songs are:
- “Honey” by The Brinks
- “Menswear” by The 1975
- “Lean” by VHS Collection
- “Retreat” by Trella
- “Radio” by Sylvan Esso
- “Sleep On the Floor” by The Lumineers
- “Tiny Cities” by Flume
- “Best to You” by Blood Orange
- “Better” by Maggie Rogers
- “This Must Be the Place” by Sure Sure
Tareq: I pretty much listen to Daft Punk’s TRON: Legacy soundtrack on repeat while I design.
Pssstt… Listen to the Amplitude design team’s playlist on Spotify:
Do you have a creative ritual?
Ran: I’m a morning person—that’s when I’m most creative and productive. How I start my morning has significant influence on my entire day. I’m not consistent enough to do it every morning, but my ideal day starts with a short workout, and then reading or listening to audiobooks on my commute.
At work, I try to keep my desk clean and minimalistic. I’ve had the exact same workstation setup since graduate school: laptop on a stand on my left, a big monitor, external keyboard, Magic mouse, and a mouse pad.
Every day before I start working, I make myself a cup of coffee or tea, put on my headphones, and listen to the same playlist on Spotify.
“We send InVision mockups to our customers to get early validation on our designs.”
Meredith: I love my Ink+Volt planner. Committing to-do’s and goals to paper helps me keep everything important top of mind and provides me the structure to do deep work.
At the beginning of each week and day, I’ll review my work—strategic, long-term projects and ad-hoc asks alike—and plan out my time in blocks.
I’ll schedule quick design asks or non-design related tasks in the morning when I’m my least creative and save my more visual work for the afternoon when I start to pick up speed.
It might seem a bit counterintuitive to plan like this for creative work, but the structure forces me to focus for an amount of time that reflects the task’s importance. Otherwise, I’m multitasking, which really means I’m losing momentum because I’m haphazardly switching contexts.
Related: Multitasking is the best way to do lots of subpar work
How does your team use InVision?
Jenny: As part of our onboarding, we invite every new employee to the Slack channel #design. We post an InVision prototype for every feature we build on the channel. There are some people who have to review every design posted on the channel. We see transparency and collaboration as a core part of our culture at Amplitude, and we wouldn’t be able to do it without InVision.
Ran: InVision is a huge part of our design process. We use InVision as a prototyping tool to get our design ideas out quickly, as well as a place where we hand off design specs.
I love how easy it is to add a comment in InVision, and other people can chime in to start a discussion. We even send our InVision mockups to our customers to get early validation on designs.
“InVision is a huge part of our design process at Amplitude.”
If you could go back in time to when you first started out as a designer, what advice would you give yourself?
Jenny: To relax. One of the most beautiful parts of being a designer is the interdisciplinary aspect of our field. Every experience or moment you go through will help you become a well-rounded, empathetic individual.
I was really concerned about learning the right tools or the right tech at the beginning of my career, and at some point I started just making things and learning about design that way.
Some of the greatest designers I’ve ever met have transitioned into design after trying out a different career path. When they apply their multiple perspectives to the project they’re working on, they’re able to have a unique take on things.
Ran: Don’t let perfect be the enemy of good. As a designer, chances are that you’re a perfectionist. You feel uncomfortable to share things that aren’t very well thought through. But the fact is, if you share your work early on and ask for feedback, you’ll get much better ideas and iterate towards a better end result.
Tareq: Don’t be afraid to ask questions. Let that next question that comes in your mind when talking to users come out. Follow that curiosity—it’ll lead to real insights.
Photos by Peter Prato.
