Janey Lee's Journey from Political Science to Product Designing at Spotify

Janey has a degree in political science, read on to find out how that helped her in her journey to become a Product Designer. Fun fact about Janey: She spent two years in Mumbai, India!

Q: Could you tell us a little about your background?

I am currently working as a product designer at Spotify in Stockholm. I studied political science, but what drew me to design was the design thinking process. The first time I came across the design thinking process was back in college. I took a class called Entrepreneurial Discovery, which was all about using the design process to identify problems and find a solution that could eventually become a start-up.

I tried to infuse this design thinking process into the Public Policy Fellowship I did after college just by asking, “How might we use interviews and the human-centred design process to better understand people who would be influenced by policy decisions or development programs?”

During this Fellowship, I met someone who was starting a graphic design studio in Mumbai and needed help with user interviews. And that’s how I got started in Design.

Q: How was your journey as a self-taught designer?

When I was working at the design studio, I did a little of everything – from UX design to making websites and brochures. I tried to understand the story our clients wanted to tell, their target audience, and their goal for the campaign. We used a user-centred approach to designing communications material during my time at the studio.

Once I moved back to the US, I wasn’t sure if I wanted to do content strategy, copywriting, user research, or product design. I attended a few design meet-ups and talked to many people in product design, and eventually decided that product design was the right balance between my skills and interests.

Another thing that helped me tremendously was asking many people to review my portfolio. When I was starting out, I didn’t know what a portfolio was or what it needed! I cold messaged designers on LinkedIn asking them to review my portfolio and was surprised that people in the design community were open to giving feedback.

When you’re trying to become a designer, you’re usually trying to stand out among other designers, and this is a tough uphill battle. If you’re trying to get into the field, my advice is to avoid following the path other designers are taking. Instead of only aiming for the usual Silicon Valley giants, think about why you got into design. It’s probably because you felt certain problems – maybe it’s education or healthcare – needed design. I would recommend spending some time in the actual fields where you want to use your design skills, ideally in smaller organizations. That’s what makes it more fulfilling; you’re using your design skills in a field that is meaningful to you!

For example, when I was trying to become a designer, I was interested in FinTech and using good design to demystify personal finances. I would go to meet-ups about FinTech and there wouldn’t be many designers there. In fact, I got my first freelance job at a startup after attending a small FinTech meetup.

Q: What are some skills you need to pick up as a Product Designer that can help you flourish?

Beyond UX and Visual design skills, another wonderful skill to build is Workshop Facilitation. I highly recommend this book by Jake Knapp, if you’re looking for a place to start.

Let’s say that it’s really important to our business that as many people as possible finish our onboarding flow. As a designer, you can take the initiative and say, “Okay, the business wants me to improve our onboarding process to increase conversion. What can I do as a designer to start that brainstorming?” You can gather a cross-functional group of people, get them to be creative, and host a Sprint that lasts 3 to 5 days.

If you’re able to take that leadership role, it builds a lot of your influence in the team. It is scary for the first time, but as long as you’re continuing to involve peers such as your Product Manager or a User Researcher, you can’t go wrong.

Another skill that I’ve found helpful to develop is the process of hypothesis-driven design. In other words, hypotheses should back every design iteration. Every time I present designs in a critique, I try to ask myself, “What is the hypothesis behind this?” This practice has helped me articulate my work better to diverse stakeholders.

Q: How does data factor in your design process? How does it connect to your hypothesis-driven approach?

One interesting thing I’ve noticed at Spotify was the close collaboration between tech, product, user researchers, data scientists, and designers. This cross-functional group is driving a lot of strategies, so naturally, we have data in that discussion.

We look to qualitative studies where data can’t answer certain questions. But when we’re running quantitative tests, that metric we’re trying to drive is crucial to the hypothesis and crucial to how you should frame the design.

You don’t need to be a data scientist or know all the ins and outs of statistics, but if you are open-minded to talk to a person who is an expert and has a good understanding of what aim you are trying to achieve, you’re good to go! It’s about being curious and thoughtful about these metrics.

Q: How is design work at Spotify? What’s the design culture like?

It’s a pretty cool design organization! It includes not just product designers, but also UX writers, design program managers, prototypers, editorial designers, and more. We also have a Design Ops team that oversees design processes on a larger scale throughout the whole design organization. Each team is different, but typically designers are pretty evenly distributed between engineering teams.

My design team has weekly critiques, where we use Figma to present designs and add feedback cards directly in the shared document. Having everything written down is super helpful when you’re iterating later on and want to incorporate your teammates’ feedback!

Overall, my experience at Spotify has been a positive one. We foster a healthy culture of feedback. Also, our designers here are wonderful storytellers! When they’re pitching new projects or trying to explain why something should exist, they always have a compelling narrative behind it. Storytelling as a skill has been interesting for me to see and learn more about, and I think all designers should develop that skill.

Q: You mentioned storytelling as a key skill for designers to have, how have you been practising that skill?

In the instances I’ve seen storytelling done well, it’s because someone has articulated the ‘Why’ behind a certain piece of work in a very compelling way. People are bringing in genuine stories behind every problem statement we have throughout the organization, and the use of different media and breaking down things into frameworks is helpful too. You’re taking a lot of scattered information, but you’re boiling it down into one statement that you use to generate more ‘How might we statements.

When the story is being told well, you start by diverging and communicating the breadth of the problem space, and then converge into a hypothesis or vision you strongly believe in. Then you diverge again and let people imagine the solution space by offering ‘what if’ or ‘how might we’ statements. A design sprint is helpful to rally people around a specific problem and not try to prescribe the solution too quickly.

Q: How do you manage version control of the design to hand over to engineering?

Every team does it differently, so I’ll only be able to answer what I do. In my team, we broadly organize our Figma by feature or project. Each project has its own new Figma file, an about page, a brief description of the product, links to previous work or iterations, and links to the product briefs and other tech documents. This makes it very clear what version of the file it is, why it exists, and what previous related work has come before it.

On working with engineers: I have an ongoing conversation with them. I make sure I keep them in the loop about any design changes. When I forget to add any detail, we just have a conversation and I update the spec. Other designers may have more formal processes but for now, it’s okay to just have an ongoing conversation with people on the engineering team.

Q: You mentioned you’re not from a visual design background. What helped you hone your visual skill?

It’s something that didn’t come naturally to me, so I worked towards it pretty intentionally. For instance, one job I applied for required me to design a wine subscription app. I didn’t end up getting that job, but I extended that case study, came up with more visual iterations, and ended up using it as a portfolio piece. I practised with other problem statements that I received during my job search and constantly iterated upon them. In this process, I realized, you don’t have to have the most beautiful portfolio to land a job. If you can put together a comprehensive and thoughtful portfolio that shows your design process, you can’t go wrong.

If you know where the limits of your skills are, you can identify those and not be intimidated by the person who has those skills but rather work together. If you’re not that confident about visual design for instance, maybe you can pair with someone who is better at it. It’s totally ok to not have confidence in all skills!

Q: What kind of user research do you do before making any changes to the product?

We usually start with a design sprint and make prototypes for the distinct hypotheses we generate. Sometimes these are fully functional app-like prototypes, and sometimes they’re more conceptual wireframes. The fidelity of the prototype really depends on what we’re looking to learn. Then, we work with user researchers to test them with people in various markets. For one project, we did a user test where we presented two versions of a concept, and one ended up generating a lot less confusing than the other. This gave us more confidence to proceed in that direction. Where we test things depends on the feature and the region it caters to. We know that different regions of the world prioritize different features, so we try to be conscientious about those differences.  

Q: How easy is it to fall into the traps of dark UX?

I’ve found that designers on our team are pretty quick to call out dark UX. If it ever seems like business needs are conflicting with user needs, we aim to resolve those through thoughtful and honest conversations between design and product.

Q: How do you collaborate effectively with PMs?

You’re two smart people who have the same goal but have different ways of expressing yourself. As a designer, you might express a solution visually from more of a user perspective. As a PM, you might attack the same problem with more focus on business needs. But ultimately, you ideally have the same vision. I’ve seen the relationship falter usually when there are strong personalities involved and differences in vision that are difficult to resolve.

My relationships with PMs have been good because I think of them as thought partners: equals but with different superpowers. The PM I work with now, his superpower is thinking about how our work ladders up to a larger product and business strategy. That’s something I’m less inclined to do because I’m more user-focused, so his input is always extremely valuable to me.

If your PM can articulate a problem that can be solved by design (without being too prescriptive about the solution), that gives you a lot of room as a designer to explore divergent solutions; I think this is a fantastic dynamic to have with a PM because you know each other’s skill set and mutually trust each other.

Q: How do you balance between user needs and business needs? And how do you balance between short-term and long-term conversion metrics?

I think it’s my responsibility to think about both. When I’m taking up a project, I try to first develop a longer-term vision. In an ideal world, how should we be solving this problem, and what will that solution look like in 1 year, or in 5 years? The vision may not be something that my team can implement immediately, but it’s still important to outline a ‘north star’ direction to help the planning process.

It’s also my responsibility to give the team something that helps us chip away at that ‘north star’ vision. If that vision has multiple assumptions, we try to start by choosing the most important assumption or hypothesis to be validated. Product and engineering give great input and help me narrow down the scope of projects to make them more feasible.

In the end, certain aspects of a design proposal may not happen because of feasibility issues or dependencies on other teams. I rely on my teammates to tell me whenever this is the case, and we scope down accordingly. As a rule, I try to push for more, and let my peers do the job of telling me when things aren’t feasible. This way, we’re constantly aiming as high as possible when it comes to implementation.

Q: When you’re designing for different regions, you have different users with different goals. Is that something you take into consideration when you do user research when you’re trying to design a new product or a new flow for a product?

Because of these cultural differences, a lot of the tests that we do are tested in multiple places. I think we’re trying to become better and more consistent at this. It’s been interesting to see how people in different regions react differently to the same prototypes.

My team has thought a lot about cultural differences and the ways people from other regions might perceive things our team might see as normal or okay. As an example, we have a playlist called ‘Songs to Sing in the shower’, which is a title that works well in the USA. But in other regions, it may not make sense culturally. Our editorial team does a good job of being sensitive to cultural nuances. I find those contrasts fascinating!

If you’re a designer, you can join our Product Design Fellowship. The next cohort begins soon!

For regular updates, please follow us on Twitter, Instagram, and LinkedIn.