I had always admired Airbnb, not only for its strong design culture but its mission of fostering belonging and cultural understanding. Despite this, working for Airbnb seemed like a pipe dream because unlike most tech companies, Airbnb didn’t offer design internships.
It wasn’t until 2018, the year I had to apply for design internships, did I find out it was the first year Airbnb was recruiting for design interns. With that, the stars aligned: I applied and found myself becoming one of the first-ever Experience Design interns at Airbnb.
Over the span of three short months, I met lots of wonderful people and was blessed with amazing mentors, all of whom helped me grow my perspective as a UX designer. I was also lucky enough to work on a consumer-facing project that would be shipped to a real users, designing for trust to help keep the Airbnb community safe in the long-term. This came with its challenges but also taught me a lot about design.
Be confident in your own judgment
When I started my first project, I would present many different design options to my stakeholders, not knowing who decides on the final version. I soon realized that it is the designer who owns the design process and narrows down on the final design. Although it’s important to take feedback into account, you should also exercise your own judgment. Weigh all stakeholder feedback and evaluate how each design addresses research or core business, engineering and design metrics. For example, I narrowed down on a final design that had a timeline view instead of a grouped activity view since the business goal was to increase the precision of identifying changes and research found that people best processed changes chronologically. Having a sound logic behind why you have you’ve chosen your final design allows you to justify your design decisions not only to yourself but to your stakeholders.
Empathize with your stakeholders
Each stakeholder has a different need: Product Management wants to move business metrics, Engineering wants to ensure technical feasibility and Operations wants to reduce the number of customer support tickets. My role as a designer was to advocate for user needs but also make sure that each stakeholder also has their needs addressed. I found that by empathizing with my stakeholders, I was able to communicate and collaborate more effectively. As a designer, it’s not enough to have good ideas. You need to convince your stakeholders on why your solution addresses their concerns and oftentimes the best way to convince other people is to see things from their point of view.
Be proactive and make order out of chaos
I was faced with some ambiguity when my project first kicked off. I didn’t have information about what features we needed, what data types existed in the back-end or metrics about existing problems with the flow I was re-designing. This was compounded by the fact that the project was technically complex and required specific domain knowledge. As the designer, I had to take charge and talk to everyone from data science to Engineering to PM and Operations to figure out the technical limitations, the business operations and how the product would fit into the bigger product ecosystem. When faced with ambiguity, you take ownership over the situation and bring all the missing pieces together. In doing so, you can move forward with a clear picture of what problem you’re trying to solve and how you can solve it.
One particularly useful piece of advice I got from my manager was to keep track of all open questions that came up when you’re designing. If I wasn’t sure about what data types we store in the back-end, I would write it down in a Google doc and tag the engineer. Having these answers documented becomes super helpful when you need to relay information between multiple stakeholders or recall what happened during the design process. I also documented everything I thought about and tried whilst I was designing, particularly what worked/didn’t work. When people ask you whether you’ve tried so-and-so during design critiques or weekly syncs, chances are that you’ll have had some variation of that idea. Having a document means you can tell them “yes, I have but I found this didn’t work because…”, allowing you to get alignment and move towards a better solution with your team.
Narrow down on your scope
It’s common to experience scope creep when you work in the tech industry. As a result, it’s important to be clear about what the goal of the design is. Is your goal to increase customer retention or to decrease customer support tickets? In the ideal world, your solution is like a Swiss Knife that has ALL the features, but it’s important to have focus when you’re designing. Ask yourself if eliminating a certain functionality would impact metrics or the user experience. From the start, you should be clear about what goal you’re striving towards and what functionalities would best help achieve that goal. This way, you don’t create functions that are ‘nice to have’ but a ‘must have’. A simple design is better than a design that does too much at once.
Think in terms of systems
One aspect of the product I was designing required me to create multiple content ‘blocks’ where each block would have a different layout depending on the content that is placed within it. I initially thought I would need to create many variations of the same design but one of the designers I worked with taught me to think in terms of systems that are dynamic rather than static. Even though I had done web development before, I never thought of applying development principles to design. As a result, I learned a lot about systems thinking and how you can accommodate for a variety of content by creating a mini design system where each element is like a ‘template’ that is fluid and adaptable. This will save you a lot of time and allow engineers and content strategists to re-purpose each template for a variety of use-cases.
Be tool agnostic
Make usability concerns known before testing
My designs went through three separate rounds of usability testing during my internship. I worked closely with user research and made interactive prototypes that were tested on both Hosts and Guests. To get the most out of usability testing, I found that it was best when I had some ideas of what usability concerns might arise beforehand. As the designer, I might already have thoughts about how users might interpret an interaction. By talking through these concerns with the user researcher early on, they can make sure these questions are emphasized during usability testing.