Ask HN: How should developers talk to designers?

It sounds simple, but telling them you trust them to make a better product than your mockup helps a lot.<p>Give them creative freedom to solve your idea in their own way. You may understand the technical specifics and big picture of what you're trying to do, but acknowledging that they know their craft better than you do (that's why you're talking to them) and that you want them to design it out in the way they think is best - just saying that will go a long way. Giving them a mockup helps - but let them know you're ok with their interpretation veering from that.<p>Obviously if the person you're talking to is an awful designer, nothing will fix it; but if you have a good one - the ideas that will flow will make your product awesome (even if they aren't implemented in the end).

You could try mocking out your idea using something like <a href="http://www.balsamiq.com/" rel="nofollow">http://www.balsamiq.com/</a> or <a href="http://www.axure.com/" rel="nofollow">http://www.axure.com/</a> (I'm not trying to push any specific mocking software).<p>This allows you to describe how you want the system to behave without getting into the nitty gritty on how to make it look good: that is why these mocking systems look as pencil like as possible. Iterate with a designer a few times with these mockups.<p>I would also recommend showing the mockups to your stakeholders and/or customers and ask them what they think. Do they like the flow, etc.<p>Another advantage using mockups is that once you have your mockups finalized, you can start implementing the behavior of each mockup while the designer designs.<p>For this phase, I would recommend using Feature/Behavior Driven Development to drive the development of your code based on the mockups. Use Test Driven Development to fill out the units of your program.<p>Just a suggestion and I hope this helps.

Try to communicate visually within a framework.<p>+1 for the idea by @ericHosick. We use balsamiq to wireframe the details. We take inputs from team to review the details of fields &#38; overall menu placements etc.,<p>And then we let our designer take it up from there with freedom to come up with various options on his own within the framework. It really helps the designer to work with freedom knowing that the overall content is "almost" set and he is free to implement thoughts based on usability and design aspects.

I think the first part of "looking for a designer" is the hardest and most important part. As with any profession, not all designers are created equal. I would look for a designer who emphasizes user experience, not just someone who makes pretty pictures. I would make that the first topic in any discussion with a potential designer. If they have no experience or regards to UX, then keep looking.

Assuming you are referring to graphic design and not product design, this is how I work with a graphic designer friend on all my apps. After many iterations, we've found the method that seems to work best between us is that I code up a functional prototype and then we have frequent intense on-the-spot design sessions with a lot of back and forth. This was initially quite unnatural for my friend, who preferred doing elaborate design explorations on his own, but we now agree this new method works best.<p>The reason I like to work like this is because until I work out how the software use actually flows, it's pointless to make it look shiny. And working out that flow itself is a rapid iterative process, which changes the UI many times over. I hate to make my friend design stuff which I will then throw away the next day, although some of that is inevitable.<p>Over time as the design gets clearer, we work out a visual grammar of sorts, which I can then just draw from as I build more features.<p>See <a href="http://giniji.com" rel="nofollow">http://giniji.com</a> for an example of a work-in-progress.