Designer-developer handoff is an anti-pattern.

Almost all of these are tools not skills.

I would also recommend affinity diagramming or similar clustering exercises.

Version control also does not improve my design instinct.

Agreed. It's a bit of a stretch.

You are welcome! Glad it was helpful.

I don't really write that much.

I would recommend reading and listening to Erika Hall and Jared Spool. I've learned more about design from those two than anyone else.

First thing I would do is frame it just as a normal, casual conversation. You might only need 10-15 mins. If you need longer, invite them to out to lunch. That can make it feel more approachable. Pitch the conversation as a "shop talk" session where you just want to learn about what they do day-to-day. No need to seek a "key informer". Just find people who have a vested interest in the problem space you're designing in. They might be worried you are there to judge them or they will somehow get into trouble for speaking truthfully.

If the person you want to talk to simply refuses and you have no one else in an analogous position to can talk to, I would escalate the matter to your manager. They should work with other business units on getting you the access you need.

If that does not work, then the organization is deeply dysfunctional. The path ahead to align the organization in a way that would allow you to learn what you need to is long and hard and maybe not worth your time. If you want to stick it out, continue talking with your manager on how to solve the problem. Approach it as another other design problem. Try to understand the underlying motivations and goals of the folks you'd like to talk to.

At the very least, revisit how your role and position is evaluated. If you are evaluated on the outcomes of your designs but are prohibited from truly understanding the context, environment, and users of those designs, then you are being set up to fail.

I've found that gathering context and understanding from these groups before the UI is designed is much more valuable than getting comments after the fact.

Get a person from each group in a room and interview them. Listen to what they're goals are, what they are trying to do, what worries them, etc.

I think you'd have more compelling results if each product that you released had a control and experiment group. The experiment group had all the nice "designery" things and the control didn't. And then you measure real product engagement with each group.

Here, you can measure engagement (how many people used the site to achieve a goal?) and retention (how many people who used it at least once in a month came back again in the same month?)

Your experiments are measuring traffic to the site, not how well the site actually works.

They are different problem scopes.

A company might have a fine brand and logo but due to new contexts (app icons, environmental, print, VR, other digital formats), the logo might not work well. It's too small, it has too many colors, it doesn't work well in non-uniform backgrounds. So the designer needs to design a logo that works in these new contexts. The problem scope is localized to the logo.

A "brand" problem would be is at a higher organizational level. Uber's recent rebrand tried to solve at least two problems: bad PR from a bunch of scandals and a confusing brand system composed of "bits". A new logo was included in that brand problem along with new design language, fonts, etc.

Something I would try is not to "convert" a logo request into a brand package but to first ask what business problem the client is facing and see how you can help. A logo is a solution to a problem. The client might request a logo thinking it might solve a problem but it might not. As you dig into the client's business, you might see new opportunities for larger projects.

You'll also build credibility with larger clients. When they see you as a business partner instead of just a logo designer, they will think of you when it comes to solving bigger and more complex problems.