• Do you feel comfortable going directly into a codebase? Or better question: do you want to do that in the first place?

I feel comfortable but there are other developers hired to do the code already so I communicate directly with them.

• What do you find is the most productive way to communicate a design to the rest of your team?

Usually prototypes (marvelapp, invision) or designs with specifications. This includes font sizes, color palettes, margins, paddings, widths and heights.

• As engineers, what can we do better when it comes to functioning in concert with designers?

Not sure I understand the question.

• If you do find yourself in a codebase, what do you find most helpful in understanding how an application works? A styleguide? Comments? A simple walkthrough from an engineer?

Styleguides are super helpful. I just created one for the company I work for and it makes design consistent across multiple applications. Other than that a walk-through or meeting seals my understanding for the most part.

• Who controls product discovery? Do the decisions come from on high, from your peers, or are you yourselves the ones driving that innovation?

It's a collective effort but usually from high. If I was given more control I would love the chance to drive things further

Hope this helps

Do you feel comfortable going directly into a codebase? Or better question: do you want to do that in the first place?

Generally yes, but I've ambled over into UX from the dev side over many years.

And yes, I very much want to be able to do that. Because understanding the medium in detail means I can work with it better, and work more effectively with the rest of the team.

What do you find is the most productive way to communicate a design to the rest of your team?

By having the team involved with the discovery and development of that design. By treating it as collaborative activity, rather than a top-down "do this" approach. Then the whole issue of "communication" basically disappears.

As engineers, what can we do better when it comes to functioning in concert with designers?

Learn more about design and UX. In the same way that some designers learn more about code and development (and, to be honest, I generally find that dev folk are far more open to learning UX than designers are open to learning dev stuff — so it's an easy win).

I take devs along with me on customer interviews. I involve devs with usability testing. Sometimes they run tests themselves. I involve 'em with design with with collaborative activities like design charrettes. I teach them about aspects of visual design. And so on.

The more dev know about UX/design — and vice versa — the fewer opportunities there are for communication failures.

If you do find yourself in a codebase, what do you find most helpful in understanding how an application works? A styleguide? Comments? A simple walkthrough from an engineer?

Most useful: Pairing with somebody who already understands it. People always trump documentation.

Failing that a good automated acceptance test suite can go a long way towards understanding the kind of business activities that the system should do. Because that should be about the "why" rather than the "how" of the code.

Failing that looking at the structure of the code, tracking what's happening during typical tasks to figure out how things fit together.

Documentation and comments are usually my last port of call — since they so often lie ;-)

Who controls product discovery? Do the decisions come from on high, from your peers, or are you yourselves the ones driving that innovation?

My preferred way is to treat it as a whole team collaborative activity.

I have a sufficient experience as an iOS designer and I had found my self in the codebase tons of times. Mostly I go there to change assets,strings, colors and positions. The search in xcode can do miracles :)

Product discovery is a democracy if the product is already launched user feedback is very influential part ot it. But Designers usually are the people with the vision for the product and how it should be.

In my opinion design specifications work best with developers, they love to receive it as technical it could be as posible.

Do you feel comfortable going directly into a codebase?

Yes, as long as it's version controlled (git). I'm only comfortable doing this if I'm going to be working on the front-end (HTML, CSS, jQuery, maybe some PHP) of a product for an extended period of time, because learning about how a system works can take up a substantial amount of time. If this isn't the case, I'm very happy to discuss with developers how things -should- work and find out about technical obsticles from them. Designing features is a two-way process and there is a balance to be struck between development time and feature-goodness (for lack of a better term).

What do you find is the most productive way to communicate a design to the rest of your team?

Talk them through it and back it up with reasoning & research.

As engineers, what can we do better when it comes to functioning in concert with designers?

Communicate the technical obstacles, make suggestions. Often, design and development is seen as a split process but the two are very much intertwined.

If you do find yourself in a codebase, what do you find most helpful in understanding how an application works? A styleguide? Comments? A simple walkthrough from an engineer?

All would be good, but having a walkthrough and a basic readme which tells me which components do what is enough.

Who controls product discovery? Do the decisions come from on high, from your peers, or are you yourselves the ones driving that innovation?

I like to think that it's a collective effort, and, there should be no distance between the creative team and the high-up decision makers (Directors, stakeholders). Designers (UX, UI etc) do the research into what users want and are therefore in the best place to know how a product should move forward. This is how the past 5+ products I've worked on operate.

I hope this helps!

I'm a designer. In my practice I found that there are two types of developers – ones that have an eye for design and ones who don't. The first ones often like to be a part of the process and during the process contribute with great feedback (it is more like a ping-pong, where we both improve something on both sides). The other ones are more into execution and need really pixel perfect mockups and style guides as detailed as possible, often including animated prototypes and videos. So I'm not into codebase, but I'm explaining my design decisions as much as I can. I value the same from an engineer and I like the situations when our brain merges for the project, rather than each of us does just his part.