Recently, we ran a design summit in Singapore to work on one of our products. To stay in touch with people in the Bay Area, my colleagues did pre-work using Miro. They had sketched out the user journey, and before they got everybody together, they had people make notes in Miro in their timeframe. Then, when everybody was in Singapore together, they printed that out, put it up on the wall, and got a lot of work done.

At the end of every day, someone on the team took detailed notes in Confluence about what decisions had been made, learnings from that day, and what they were going to do the next day. That way, people who weren’t in Singapore were able to follow along and stay abreast of what was going on. A combination of Miro, Confluence, Slack—it’s a lot of communication, but it made a tremendous amount of difference. It’s already become the new standard.

My manager shared the 3-1-1 document with me. On a monthly basis, I have three goals that I list out, or maybe even two or one. If I’ve got multiple, I’ll rank them. Anything outside of that is not that important. If I’ve got extra time, great. However, the goals on that list are the things I need to focus on.

I block out time on my calendar to show when I’m busy, and you can try to schedule a meeting, but you’re not going to. It’s about setting boundaries for myself and empowering my team to do the same. Once when one researcher was spread super thin, I said, “I know you want to help everyone, but say no; tell them to come to me, and I’ll get them a contractor.” Designers want to help everyone, and they will put themselves out until they make themselves sick. Having boundaries and being empowered to define them is critical, or you won’t get anything done.

We also have a culture of ‘Work From Home Wednesdays.’ That means there’s not a lot of meetings that day, so people can have at least one day a week where they can expect to get some heads-down work done. That’s helped a lot.

I’m sure many people have this calendar problem where their life is in 30-minute chunks all day long, with a 30-minute lunch. However, you need to have two or three hours of really focused time to get your brain to unwind and wrap yourself around the problem and get involved. So if we’re all working on the same problem, wherever we are – we’ll turn on the camera, have a quick discussion for 20-30 minutes, then keep the camera on for a few hours while we’re working.

It’s been amazing, because it feels a lot more like when you’re working side by side. It’s so powerful, and so simple. When we realized how awesome it is, we felt kind of dumb that we haven’t done it sooner.

Very often, people feel scared to try new things, especially around UX experience design, getting out and talking to your customers. This year, my team is focusing on hosting brown bag lunch and learns, to teach design thinking and user research internally, so people feel more comfortable and get more involved in the process. I’m not just talking about the design team, but the much larger ecosystem of Salesforce. We try to encourage a comfort level that you can’t just get from talking about a project in a meeting.

We’re more engaged with our customer success team because they’re on the front lines with our customers. We have a ‘Customer Success Pals’ program, where the product team shares our plans and decisions with our customer success teams, so that they’re prepped, ready, and they know what’s coming. It’s not a perfect process, but we are trying to share as much as we can.

When I joined Zendesk, there were a lot of different people doing research. So we created an Insights Guild: all of the directors or managers meet once a month to sync on what’s coming and share questions we’ve gotten. We also have a shared calendar, so our surveys aren’t cannibalizing each other and we’re not trying to hit up the same people for research.

We created a Slack channel called “Ask Insights Guild.” So now, if someone has a question, they don’t have to figure out who to talk to. Then we’re able to respond by suggesting a research method, or showing that this research has already been done, or whatever it is. That’s still ramping, but people love it when they hear about it.

More and more companies are wising up to the fact that they need UX resources, but they don’t 100% know what to do with those resources once they get them. So be kind, be empathetic, be flexible, be patient. Focus that frustration towards helping your internal stakeholders understand why they hired you and showing the business value.

One thing that always helps me is the story of James Dyson, the guy who invented the Dyson vacuum cleaner – he made 5127 prototypes over 15 years. He’s now one of the richest men in England with a net worth of over $5.7 billion, so keep going.

Persistence is essential. If you shop an idea around and people say no, that doesn’t mean no—it means you keep selling it until you get your point across. Sometimes it takes a couple of years for things to get from a research insight into a product feature. If you have a process change, it may just take a while before you get the right people interested and ready to adopt it. Don’t take it personally when someone doesn’t like your design idea. Just figure out how to tweak it and keep trying.

We ask ourselves, “How do we measure success?” Is it through qualitative or quantitative means, or both? We like to use a lot of lean frameworks. We build a hypothesis out initially, and then check our assumptions along the way. You constantly go back to your hypothesis, and you say, “What did we learn?” Then rinse and repeat. You constantly have to iterate on design.

For my research team, goals are subjective. When my research is used, whether it’s to make decisions or to build empathy with users—that’s my measure of success. Or for example, today a product manager started running her own research. She conducted her interviews, wrote a discussion guide with very minimal support from me, and that was through coaching on a previous project that we worked together on. So that’s something I would consider a success as well.