During my tenure at Stack Overflow, one of my team’s major goals was to increase job applications submitted through our product. We knew that search was the primary path through which people found and applied to jobs, yet we hadn’t invested in improvements in years. I was tasked with researching and designing areas that would improve the job search experience by helping users quickly and easily find jobs that they’d want to apply to.

Current state

I started by analyzing the current state of job search, digging into usage analytics, and reviewing existing qualitative feedback. I identified a few key problem areas:

Problem #1: Easy-to-use, desirable filter options were either not available or accessible only through advanced syntax search, which saw very low usage and required users to enter complex queries to run even the most basic searches. …

During my tenure at Stack Overflow, I was tasked with designing an identity and visual design for Japanese Language Stack Exchange, a question and answer site for students and enthusiasts of the Japanese language.

Research and concept development

When developing early concepts, I drew inspiration from user feedback, Japanese art and writing, and Japanese aesthetic philosophy.

First, I scoured existing ideas from the community for the site’s design aesthetic. I was interested in learning about their design ideas as well as the metaphors and experiences that inspired their ideas.

One thing that resonated with me was the nuanced, challenging experience of learning a new language. As a semi-fluent Korean speaker, I’ve often found myself communicating in basic vocabulary, removed of the embellishments and nuances that intuitively came to me in English. While frustrating at times, I experienced depth and beauty in this simplicity. I could say to my relatives, “thank you for your kindness.” I could not easily embellish that with jokes or comments that I might otherwise deploy to fill space or deflect from the weight of that sentiment. …

You’ve asked your manager for feedback. They tell you that you’re doing great and that everyone loves working with you. Then performance evaluation season rolls around, and your review contains some surprising feedback: one of your team members thinks you’re difficult to work with, and another believes the caliber of your work is poor. Needless to say, you won’t be getting that raise you were hoping for.

Some of us have had this experience or heard horror stories about it. Some of us work at companies with underdeveloped feedback systems, where we receive feedback long after the fact or not at all, limiting our opportunities for improvement. …

Users who are knowledgeable and excited about your product offer unique challenges. They deeply understand the ins and outs of your product and are overflowing with ideas about how to make it better. They’re smart, articulate, and persuasive. They want your time and attention, and they expect to guide the direction of the product.

Your team may have differing opinions about what to do with these expert users. Some consider them to be the heart of your user base and believe staff should do more to listen, engage, and include them in decision-making. …

You’re stumped on a coding problem. You’ve tried everything: scoured the internet, pinged your colleagues for help, and troubleshot for hours. Finally, you decide to ask your question on Stack Overflow — surely someone in this community of 50 million programmers can help you, right? So you publish a question and wait hopefully for a response.

Within minutes, however, your question is closed by community members and marked with a large yellow banner, letting you and others know that there’s something wrong with the question. Closing also prevents your question from being answered by others.

If you work on a product that’s ever benefited from research — whether that’s talking directly to users, analyzing experiment data, or any number of other research methods — you know how indispensable these inputs are for making the right decisions.

But how do you decide which methods to use and when? How do you know if you’re spending the right amount of time on research? How do you know when it’s time to change your research methods?

These are questions that the Community team at Stack Overflow has been grappling with, particularly in the last year. …

You’ve been asked to design a new feature. You’re not sure that this feature will work without broader changes to the product. However, no one has asked you to design a new feature and a sweeping overhaul of the product. In fact, when you’ve pitched broader changes alongside a feature design in the past, your stakeholders expressed skepticism and dismissed your proposal as scope creep.

Still, you can’t help but feel that these broader changes are sometimes necessary — even if you’ve been having trouble convincing your stakeholders to see things your way.

At Stack Overflow, I’ve often grappled with the question of when and how designers should advocate for more holistic design changes (and therefore, larger scope). Below are tips to help you decide whether to advocate for holistic designs changes, and if so — how to do so effectively. …

If you’re a product designer, you probably lead design projects every day, even if “lead” isn’t in your job title. Whether that’s by gathering user insights to identify the next thing your team could work on, designing solutions to user pain points, or running design reviews, the opportunities to lead your team and influence the direction of your product are present throughout the design cycle. In her book, The Making of a Manager, Julie Zhuo writes:

“Over time I’ve come to learn that leadership is a quality rather than a job. While the role of a manager can be given to someone (or taken away), leadership is not something that can be bestowed. It must be earned. …