Daily journals are a handy technique that you can use if you’re designing remotely. I picked this idea up from Buzz Usborne. I had the pleasure of working with Buzz at HelpScout. He wrote about it in a post that I’ll link to.

The idea is to have a centralized doc that you constantly update throughout your day with questions that you’re working through, screenshots, links, gifs, or videos.

What’s your creating in this doc is the digital trail of your work. It becomes a visual log of your daily activities. This can feel intimidating at first, but it’s extremely handy. It allows anyone to see at a quick glance, everything you’re working on and allows them to provide feedback.

Buzz also used to take five minutes at the end of his day and record a little video recap. This was a great way for him to communicate the progress he had made on a project in any given day. Especially since he lived in Sydney. And I was living on the east coast of the United States and we had very little overlap.

Bi-weekly design snaps is an idea that I attribute to Joen A – a talented designer that I’ve had the pleasure of working with for 10+ years at Automattic.

The idea is to round up visual artifacts—could be screenshots, or gifs, or videos representing the progress your design team has made over the past two weeks. And to share a post highlighting your work to the rest of the company.

So this is something you can share the responsibility for. You can rotate through allowing each designer on your team to do a post.

Snaps have multiple benefits:

In my experience, the max ratio that you should have for engineers to designers is eight to one. In some companies, the ratio will be way higher than that. In my experience, the ratio is almost never lower than that.

When you’ve got a ratio of eight to one, chances are you’ll be designing multiple projects simultaneously. And chances are, you may be a solo designer on each project.

This can become problematic because each project comes with its own set of context.

As a designer, you load all of that context into your brain as you’re exploring various avenues for solving a problem.

This can become problematic when you go to other designers within your team for feedback. As they likely won’t have the same level of context as you do.

One way around this is to create a design buddy system. You basically pair up designers as buddies. Each designer does a little bit of extra work to understand each other’s projects. The net result, being that when you go to solicit feedback, another designer already has the context for your project in their head.

A call for feedback is a post that you share internally once the design you’re working on is ready for feedback.

This could be multiple posts, each at a different stage in the design process, or it could just be a single post.

The goal of the post is to solicit feedback from folks outside of your design org.

It’s helpful to start by giving some context around the project. What is the problem you’re trying to solve? What customers will be affected. What impact will this project have?

Then you can showcase your design through a series of screenshots, gifs, videos, or prototypes. It can also be helpful to link to other posts related to this project and to outline open questions you have and the list of known issues. Finally, before you wrap up, just be sure to be explicit about the type of feedback you’re looking for.

A call for testing is another internal post that you can share. Ideally about a week prior to launching a new feature.

The goal of a call for testing is to outline everything that you’re planning to ship and then to ask others to test it prior to launch.

Generally you do this by placing the feature behind a feature flag.

This can be a great way to catch last minute bugs and edge case issues prior to launch. It can be a great time to refine smaller things like microcopy or transitions between flows.

It can also be a great way to surface the project one more time to the folks working in support within your company. As after lunch, they’ll need to support this new feature.

Sometimes even major issues are surfaced, which is great.

At Pixar they’ll frequently bring a director in his or her in progress film in with a group of other experienced storytellers. And they call this a brain trust.

The purpose of the brain trust is not to tell the director what to do. But to highlight areas that may be weak. Or to spark ideas for moving forward.

Brain trusts are excellent ways to solicit feedback on designs internally.

In the book, “Creativity, Inc”, which I highly recommend by the way, Ed Catmull shares a number of helpful tips around brain trusts and I’ll share a few of them here.

Ed says, quote:

End quote.

There’s a great corollary here to design teams.

In my experience. Everything Ed shared applies equally well to product design.

And if you haven’t given them a try. Assuming you have the culture for it, I’d suggest giving brain trusts a go within your company.

There are multiple ways that you can solicit feedback from other employees within your company. Here are three specific ways.

The first is via internal posts where you solicit feedback. The second is you can DM someone directly and ask for feedback. And the third one is you can ask for volunteers to do a quick 15 minute usability test on the design that you’re working on.

Oftentimes, we don’t even consider other employees within the company for testing and feedback. But if you think about it, depending on the size of the company that you work at, chances are there’s going to be plenty of folks internally who have no idea what you’re working on, but who would be happy to spend a few minutes with you walking through design and sharing their thoughts.

In this way, soliciting, designed feedback from other employees in your company. Can be really handy.

Getting feedback from busy execs or senior management can be tricky at times. Here are a few tips that I’ve learned over the years.

First distill all of your options into a couple of simple bullet points. Next share, which of those options you plan to proceed with. And if possible show a before and after—could be a sketch, a wireframe, a full mock-up, or could be a click through prototype.

Finally note that no action is necessary on their part, but that you are open to feedback.

This way, the exec is brought up to speed. They don’t need to open any separate docs. They have all of the context in front of them. And if they have feedback, they can share it. But if not, no action is needed on their part.

This is a simple process that I’ve refined over the years and it tends to work really well with busy execs.

Another way you can gather insights is from analytics.

This can be slightly different depending on where you work. Some companies will have a robust internal analytics infrastructure. Some companies will leverage outside tools. And some companies will have little to no analytics.

My suggestion to you as a designer is to take a solid day and to see if you can get someone to walk you through what is available. Have them show you how to run your own queries and discover your own insights.

This day spent learning the ins and outs of your company’s analytics will pay dividends down the road. Being able to pull up your own reports and dig into data around various flows and events will become a resource to you as a designer that you can apply to any project that you work on.

Say for instance, you’re working on your apps onboarding flow. Prior to mocking up a single idea, you can use analytics to pull up a funnel of new user signups. Doing so will help highlight the screens that are performing well and those where customers seem to be struggling.

Once you’ve identified a screen that has friction. You can then come up with ideas around polishing up that particular screen. You can then compare the funnel numbers before and after you make changes to see what kind of impact they’ve had.

Your support team can be an extremely valuable resource when it comes to customer insights.

I’m actually a big fan of pairing, at least one person from support with each product team, whenever they’re working on a new feature. Doing so seems to help bridge the gap between support and product.

If this isn’t something that your company has ever tried, you may find that you face resistance to the idea. Support tends to get hit up regularly in my experience, to help with an assortment of things that take them away from their primary job, which is helping customers. So support tends to get really good at saying, “No” to things outside of the scope of their primary job.

If this is the case, just propose a trial experiment.

Start by placing a specific time box around it. Like no more than three hours per week.

Then attempt to measure the experiment, at least qualitatively.

How did they feel about being deeply involved in the product development process? What insights did they bring to the table as a result of being deeply embedded? How did they spend their time? Was the three hours per week a good return on investment?

In my experience, it always is.